On Mon, Mar 24, 2014 at 9:16 PM, 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. >
IMHO, it would suck for applications to need yet another mapping table to map surface types to pixel formats, when one pixel format that says "there is a hardware surface in there" is all thats needed. For most HWAccels, avcodec just doesn't need to know, nor should it know. If I take DXVA2 as an example, since thats what I know best, the application negotiates with the GPU driver which format is used, which can in theory be anything. In practice, most GPUs support NV12, some support YV12 additionally. avcodec does not care, nor should it care, which format I negotiated for with the driver. It just passes the opaque surfaces around, from the user app to the hardware decoder, and back again. Adding separate pixel formats just bloats up the list here with no real-word usefulness. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
