[FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check
Philip Langdale
philipl at overt.org
Sun Jun 19 04:31:45 CEST 2016
On 2016-06-08 21:54, Mark Thompson wrote:
> On 08/06/16 13:59, Carl Eugen Hoyos wrote:
>> Mark Thompson <sw <at> jkqxz.net> writes:
>>
>>> Uses the global -hwaccel_lax_profile_check option (may be
>>> misnamed for this purpose, but it has the right spirit).
>>
>> Iirc, all old x264 files have a very high profile set (5.0?).
>> Is there a usecase for the default not being to accept any
>> profile?
>
> (You mean level rather than profile there, right?)
>
> The point here is that the driver has declared its capabilities, and
> the given
> stream is not within those capabilities so the hwaccel should not be
> used
> because it will not work (the software decoder should be used instead,
> which
> will supports a wider set of streams). However, in reality we have
> known cases
> where the driver is broken and incorrectly reports this information,
> and can in
> fact decode some streams which it has stated it is unable to.
>
> Now, obviously fixing the driver to correctly report capabilities would
> be the
> way to actually fix the problem, but we don't control that. This
> option allows
> the user to ignore the declared capabilities of the driver and attempt
> decode
> anyway - it may then fail, but the user did explicitly request it so if
> it
> doesn't work then it is their problem. Setting it by default would
> result in
> some streams which previously worked now unexpectedly failing, which
> would be
> worse than the current situation.
>
> I hope that was clearer.
Is there a specific example you're thinking of? As with Carl, the only
thing I'm
aware of is the handling of h.264 levels. The nvidia driver doesn't
declare support
for anything higher than 4.1, although the hardware will successfully
decode files
that are not 4.1 conformant, and in fact, there is an inherent
contradiction as
the driver does declare support for 4K resolutions, which requires level
4.2/4.3
for practical bitrates and framerates.
In this specific case, I think level enforcement is unhelpful and it's
common to
see media players setting the flag to ignore level enforcement. So I'd
probably
be in favour of reversing the default on level enforcement.
Do you have real world examples that are genuinely out-of-spec for the
hardware,
and would have been correctly excluded by the level check?
--phil
More information about the ffmpeg-devel
mailing list