[vlc-devel] [PATCH 2/2] Add VideoToolbox based decoder

Rémi Denis-Courmont remi at remlab.net
Tue Feb 3 17:37:07 CET 2015

Le 2015-02-03 19:08, Felix Paul Kühne a écrit :
>>> +            msg_Err(p_dec, "trying to decode MPEG-4 Part 10: 
>>> profile %zu,
>>> level %zu", i_profile, i_level); +
>>> +            if (deviceSupports10BitH264()) {
>>> +                if (i_profile > 110)
>>> +                    return VLC_EGENERIC;
>> Unwarranted assumptions about not yet specified profiles AFAICT.
> Maybe true, but Apple claims support for all profiles up to 110 on
> the A7/A8 CPUs included with the latest and the previous generation 
> of
> iPhone and iPad. This is not supported on OS X or previous iOS
> devices, where 100 is the limit.

I don't know what Apple exactly claims. But profile identifiers are not 
totally ordered! A lot of identifiers are not even defined yet, which 
Apple cannot possibly support. Furthermore I seriously doubt that they 
support non-constrained Baseline Profile (66) and Extended Profile (88).

>>> +            } else {
>>> +                if (i_profile > 100)
>>> +                    return VLC_EGENERIC;
>>> +            }
>> The component depth is specified by the chroma IDC, not the profile.
> The original naming was wrong. This check is about profiles, not
> about chroma.
> For chroma checks, we intend to parse the SPS as suggested by you in
> the other thread. Regarding the further implementation of the module,
> we don’t care about the input chroma at all as everything is handled
> by the DSP without letting us know.
>>> +
>>> +            /* we don't do decoding beyond 4K */
>>> +            if (i_level > 51)
>>> +                return VLC_EGENERIC;
>> This is a sufficient but not necessary condition, AFAIU.
> Regrettably, it is necessary because higher levels will lead to
> decoder errors

Of course you want to check that you are able to decode. You probably 
need to check the level, or you possibly need to check the resolution. 
The comment and the code are incoherent here.

> at a point where we can’t fallback on libavcodec anymore.

I do not know if the VLC convention is to pass(1) or not to pass(2) the 
initial SPS as format extra data if/when the SPS is subject to in-band 
change. Maybe Laurent or Rafaël know better.

In any case, while this patch makes an honest attempt at filtering out 
unsupported codec profiles, it fails to address the very real 
possibility of the H.264 parameters set changing within a track. In case 
(1), hardware decoding will be used and will fail. In case (2), software 
fallback will be forced even if hardware would be available.

So this patch does address some failure cases of the current VDA 
plugin; but it also introduces new ones.

Rémi Denis-Courmont

More information about the vlc-devel mailing list