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. > > > to YUV420Planar to ... > > > > There are several cases whereby the application needs to know the > > underlying type of a surface: > > 1) A function is the acceleration framework requests it as a parameter. > > 2) The application wants to copy the surface content back to main memory. > > 3) The application wants to show the chroma sampling as meta-data. > > 4) The application exports the surface via interoperability (e.g. to > > OpenGL). > > In all the current cases other than new VDA with magic wrappers, the > application explicitly chooses the underlying format it will use. > In all the current cases the application can call some function to get the > underlying format. > > So I really don't see what would be the advantage in restricting the API. This does not restrict the API in any way, quite the contrary. -- Rémi Denis-Courmont http://www.remlab.net/ _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
