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

[Reimar Döffinger]

On Wed, Dec 24, 2008 at 09:09:30AM -0800, Stephen Warren wrote:
> One comment on this: Would exposing pixfmts by profile be OK, but with the addition of libavcodec options that provide an override mapping.

IMO no, the reason being that the profile level is not really a property
of the image for several reasons:
1) it is a claimed property that does not have to have any relation with
reality, and the decoder does not verify it.
2) it depends on things that do not apply to a single picture, e.g.
bitrate or framerate. Framerate can easily be changed, bitrate can also
change easily e.g. by skipping non-ref B-frames or by just playing all
keyframes (if/for whatever reason that makes sense).

> > 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.

Is there some information on difference it actually makes whether
MAIN/HIGH profile is passed?
Obviously that information is necessary to find out if the video can be
played by the hardware, and I agree that FFmpeg help applications
get that kind of information.
But given the way MPlayer currently works (and also how it is done for xvmc)
this is not information we care about, the user tells us to play it
using the hardware, and our job is to do our very best to play it -
if necessary with artifacts, at slower speed and with lots of warnings,
but not the "we know better than the users" way of refusing (I
understand that the API understandably was not designed for that
operating mode, which might mean to settle with a something less
than I'd like).

> 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

That would mean and API change to libvo. It's not impossible, but
generally the preferred way is to add functionality via a VOCTRL.
There is another reason why passing this via config() is a bit ugly:
config() would have to be called whenever profile changes. This then would
mean a special case, since normal vos should not be reinitialized in
that case (I admit that the per-profile PIXFMT solution has some advantages
here - in the worst case you can still map PIXFMT + level to a
per-profile IMGFMT in MPlayer).
Overall the "best/right" solution depends a lot if/when it is necessary
to reinitialize vdpau when the profile changes (and there are use cases
when it is very nice to e.g. be able to play several videos without any
visible delay due to reinitialization).

Greetings,
Reimar D?ffinger