On Mon, 24 Mar 2014 22:16:01 +0200, Rémi Denis-Courmont <[email protected]> wrote: > Le lundi 24 mars 2014, 20:23:05 Anton Khirnov a écrit : > > > Last I checked, libavcodec did not support hardware acceleration for > > > anything other than 4:2:0 - just looking at the pixel format lists... > > > Anyway, is there even *real* hardware slice-level decoder that supports > > > 4:2:2? As far as I know, hardware video acceleration frameworks support > > > 4:2:2 for post-processing and rendering, not (really yet) for decoding. > > > > Just because we do not currently support them does not strike me as a good > > reason to limit our API so we _cannot_ support them in the future. > > 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. >
What would be the advantage in having separate pixel formats. A normal pixel format tells you how is the data laid out in memory and how you are supposed to inrepret it. A hwaccel pixel format just tells you that the data is outside the scope of libav and you have to deal with it using a special external API. You would still use the same API whether it's 8bit 420 or 10bit 444. So from the point of view of libav it's still the same format. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
