Le lundi 24 mars 2014, 22:25:35 Luca Barbato a écrit : > On 24/03/14 22:09, Rémi Denis-Courmont wrote: > > Le lundi 24 mars 2014, 21:53:35 Luca Barbato a écrit : > >> First friendly warning: please tone down two notches. > > > > I suggest you check your facts before you flame me then taunt me. > > Nobody is flaming you, just this kind of tone is not welcome. > > >>> If you keep a single pixel format regardless, the only way for the > >>> application to know the correct parameters is look at the last pixel > >>> format (i.e. software) in the list and second-guess libavcodec that this > >>> indicates the correct chroma type and pixel depth. This would be > >>> vomitively ugly, and it would forever lock libavcodec into offering only > >>> a single software output pixel format ever. Is that really what you > >>> want? > >> > >> It is actually what normally happens, as explained by Hendrik, Anton and > >> wm4. > > > > This is patently false. Look at get_pixel_format() from h264.c for > > yourself! > The code in avconv_vdpau and mpv does the surface mapping based on the > global context (set by the very same application). > > VDA does the same. > > > libavcodec does not currently call get_format() for anything other than > > 420 > > content(*)- Therefore, it does not offer AV_PIX_FMT_(VDPAU|VAAPI) for 422. > > Instead, it just hard codes the software decoding pixel format in that > > case. > That can be easily fixed, I guess. > > >> I'm sorry about this misconception, sadly hwaccel hadn't been documented > >> so everybody had an understanding on how it works and all the time a > >> detail or another might fit by pure chance. > > > > You are distorting reality here. This stuff (non-420 hwaccel) is not > > implemented yet. Of the two potential ways to implement it, you defend the > > backward-incompatible and ugliest one. > > I'm not distorting anything, please tone down. > > You assume one way is the correct one, the other people involved assume > the other. > > As I told you, the original hwaccel does not assume anything beside > black boxes and opaque pointers. > > What Hendrik, Anton, wm4 consider correct as approach had been > implemented on their side, you assumed otherwise and implemented that > way in VLC.
There are about zero benefits to using the same pixel formats for different chroma types in VDPAU and VAAPI (maybe for DxVA2, I doubt it, but I don't really care). If you add new > It can be *calmly* discussed w/out considering a war. > > Worst case I'll fix that part in VLC if you do not want to. The VLC VAAPI code has been doing that (so far correct) assumption for three major releases already, and VDPAU for one. Given that even Anton made the same assumption for avconv_vdpau in libav 10 release too, I consider it is part of the interface promise for the VDPAU pixel format. This is not a matter of fixing VLC. This is a compatibility issue. You'd have to create one new pixel format in the enumeration to avoid breaking compatibility anyway (like this series does for VDA). You might just as well map pixel format to chroma types. It is cleaner, much more difficult to implement wrongly, and consistent with the design of libvdpau and libva. -- Rémi Denis-Courmont http://www.remlab.net/ _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
