[FFmpeg-devel] [PATCH] avcodec/vc1dec: Re-order init to avoid initting hwaccel too early

Philip Langdale philipl at overt.org
Sun Aug 9 18:52:21 CEST 2015


On Sun, 09 Aug 2015 10:36:25 +0100
Andy Furniss <adf.lists at gmail.com> wrote:

> Philip Langdale wrote:
> > At least for vdpau, the hwaccel init code tries to check the video
> > profile and ensure that there is a matching vdpau profile available.
> >
> > If it can't find a match, it will fail to initialise.
> 
> I recently noticed this - that it silently falls back to s/w in my
> test case.
> 
> For me the check (which no players seem to do) is also an issue as I
> need H264 5.2 - which doesn't seem to exist in the libvdpau world.
> 
> By luck if I blindly hack mesa to say 52 it works - but that's
> possibly not exactly safe for all - the AMD code works AFAICT because
> of defaults in case statements setting things "to high".
> 
> Maybe ffmpeg which seems alone in checking, should allow h264 52 in
> the case that vdpau offers 51.

The nvidia people tell me that their hardware *technically* doesn't
support level 5.x so they refuse to declare support for it. Now, it
happens to play any 5.1 file I've ever come across, so in practice it
works but they are very fussy about this. I assume that they
technically do not support the maximum bitrates that the spec defines
for these levels, but no real file hits those rates - or something like
that.

So, yes, level checks are an issue but that's why
AV_HWACCEL_FLAG_IGNORE_LEVEL exists and can be passed in when
intialising the vdpau context. This is what 'mpv' does, for example.
mplayer and kodi initialise the vdpau decoder themselves and don't
bother doing level enforcement.

And as a final clarification, nvidia vdpau only claims support up to
4.1. I don't know what the AMD declared and physical limits are but
using this flag is the right thing to do either way.

--phil


More information about the ffmpeg-devel mailing list