Le lundi 24 mars 2014, 21:29:02 Luca Barbato a écrit : > On 24/03/14 21:16, Rémi Denis-Courmont wrote: > > The point is that currently those surface types are used by 4:2:0 surfaces > > only. If support for 4:2:2 or Hi10p or whatever gets added to libavcodec, > > the newly used surface types should be assigned new pixel formats, > > consistently with the underlying acceleration APIs as well as with > > libavcodec software pixel formats. > > > > It would suck for applications to have to second-guess libavcodec. > > libavcodec was originally supposed NOT to know anything (the global > context wasn't even set by it), thus the assumption to know nothing > about the output frame accordingly.
Go check the VA-API and VDPAU header files and documentation, instead of barraging me with the same nonsensical arguments over and over. Whoever allocates the surfaces MUST KNOW the chroma sampling and pixel depth for OBVIOUS REASONS. 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? -- Rémi Denis-Courmont http://www.remlab.net/ _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
