[FFmpeg-devel] [PATCH] Video Accelaration API support for FFmpeg & Mplayer

Stephen Warren swarren
Wed Dec 24 18:09:30 CET 2008

Reimar D?ffinger wrote:
> On Wed, Dec 24, 2008 at 05:00:13PM +0100, Diego Biurrun wrote:
> > That's from a 5 minute look.  Please try to get the author to submit
> > this to us.
> Plus many of the comments made for the NVidia acceleration patches.
> Particularly I think there is no way PIXFMTs split by profile will be
> accepted.

One comment on this: Would exposing pixfmts by profile be OK, but with the addition of libavcodec options that provide an override mapping. i.e. there would be an option variable for each profile which says what profile to actually expose this as. The defaults could be:

stream   -> expose PIXFMT_ as:
baseline   main
main       main
high       high

I think that default mapping would allow things to operate in a fashion appropriate for real-world bitstreams that you say don't really use any baseline-only features, but also allow users to really request baseline features if they need them, and have a VDPAU/... implementation that actually supports them (NVIDIA's doesn't.)

> A method exporting the level/profile to user apps probably would be
> welcome though.

This would be fine too; MPlayer's vo_vdpau could then do the mapping it needs, presumably with a similar user-overridable scheme.

If somebody does work on this, we'd love it if:
* H.264's sequence-level parameter "num_ref_frames" could be exposed the same way.
* These values were available to MPlayer's vo modules' config() function

> A non-overrideable decision whether to use acceleration based on the
> _claimed_ profile
> which is wrong all too often is not acceptable either IMO
> (not to mention that a non-supported
> profile might still render better than it would in software for some
> people, at least as soon as the corresponding code has improved to not
> crash
> on invalid streams and maybe even do error concealement).
> Greetings,
> Reimar D?ffinger

This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

More information about the ffmpeg-devel mailing list