Le lundi 24 mars 2014, 21:27:34 Anton Khirnov a écrit : > 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.
You don't need to know how the surface is packed on the GPU, but you obviously do need to know the chroma sampling and the bit depth to allocate the surface, in addition to the pixel width and height. You also do need to know that in the 4 cases outlined in a previous email. > 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. Same API, different parameter. That's exactly what pixel formats are for. -- Rémi Denis-Courmont http://www.remlab.net/ _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
