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. With hwaccel1.2 you have a set of default setup and destroy functions, so the output frame is more or less set (depending if the setup function takes args changing it or not), but for the "traditional" hwaccel the AVFrame is totally opaque and the additional fields got cargo-culted in. With hwaccel2 you get the option of even not having to take care of the rendering if you want it to happen in system memory. With avscale you get the option to have the scaling/conversion happen in hardware (if the hardware supports it). lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
