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