On Sun, 09 Aug 2015 10:36:25 +0100 Andy Furniss <adf.li...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
