On 24/03/14 21:47, Rémi Denis-Courmont wrote: > 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.
First friendly warning: please tone down two notches. > 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. 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. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
