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. > > 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! 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. > 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. (*) with the irrelevant exception of the 8BPS decoder. -- Rémi _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
