1143586 - CanPlay returns false if codecs is avc1.4d4001

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Jean-Yves Avenard [:jya]]

We always assume that the level_idc present in the codec parameters to be 10* the actual level number.

http://blog.pearce.org.nz/2013/11/what-does-h264avc1-codecs-parameters.html

This causes us to fail the webref test that uses:
avc1.4d4001 codec type.

Both Chrome and IE reports supporting this format.

Now in the ITU H.264 spec we find:
"For coded video sequences conforming to the Multiview Depth High profile, the level_idc value is specified as follows:
– If level_idc is not equal to 0, level_idc indicates the level that applies to the coded video sequence operating with all the views being target output views.
NOTE 3 – A level_idc value that is not equal to zero may indicate a higher level than necessary to decode the coded video sequence operating with all the views being target output views. This may occur when a subset of views or temporal subsets are removed from a coded video sequence according to the sub-bitstream extraction process specified in clause I.8.5.3, and the level_idc value is not updated accordingly.
– Otherwise (level_idc is equal to 0), the level that applies to the coded video sequence operating with all the views being target output views is unspecified.
NOTE 4 – When profile_idc is equal to 118 or 128 and level_idc is equal to 0, there may exist a level indicated by level_idc[ i ] that is applicable to the coded video sequence operating with all the views being target output views. This may occur when a subset of views or temporal subsets are removed from a coded video sequence according to the sub-bitstream extraction process specified in clause I.8.5.3, and a particular value of level_idc[ i ] corresponds to the resulting coded video sequence.

In bitstreams conforming to the Multiview Depth High profile, the conformance of the bitstream to a specified level is indicated by the syntax element level_idc or level_idc[ i ] as follows:
– If level_idc or level_idc[ i ] is equal to 9, the indicated level is level 1b.
– Otherwise (level_idc or level_idc[ i ] is not equal to 9), level_idc or level_idc[ i ] is equal to a value of ten times the level number (of the indicated level) specified in Table A-1."

I'm not sure how relevant how it's encoded in the SPS means to how the mimetype should be encoded.

Level 9 is 1B in those spec, so we could return H264_LEVEL_1_b

I suggest that if the value is < 9; we return value * 10 so we pass the test (As it appears that's what IE and chrome are doing)

Comment 1

[Jean-Yves Avenard [:jya]]

Attachment: Part1. Be more relaxed when parsing h264 codecs' levels

Be more relaxed on the codecs type. Actually it appears that Chrome and IE never cause an error, so long as the codecs is avcN.PPCCLL syntax. I guess they rely on the actual decoder to return an error later.

Comment 2

[Jean-Yves Avenard [:jya]]

Attachment: Part2. Update webref results

Turned out, we failed all those tests only due to the codecs provided\!

Comment 3

[Jean-Yves Avenard [:jya]]

Attachment: Part2. Update webref results

Test will fail on XP and Linux as MP4 isn't supported

Comment 4

[Jean-Yves Avenard [:jya]]

https://hg.mozilla.org/try/pushloghtml?changeset=9a94e632d1ea

Comment 5

[Jean-Yves Avenard [:jya]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=9a94e632d1ea

Comment 6

[Karl Tomlinson (:karlt)]

Comment on attachment 8577989 [details] [diff] [review]
Part2. Update webref results

> [mediasource-config-change-mp4-v-framerate.html]
>   type: testharness
>   [Tests mp4 video-only frame rate changes.]
>-    expected: FAIL
>+    expected:
>+      if os == "linux": FAIL
>+      if (os == "win") and (version == "5.1.2600"): FAIL
> 
>+

Please remove the extra blank line here, or there will be noise next time the tests are pulled from upstream.

Comment 7

[Jean-Yves Avenard [:jya]]

Attachment: Part2. Update webref results

Carrying r+

Comment 8

[Jean-Yves Avenard [:jya]]

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/f8bd37c3f847
remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/2be7cfd01d8b

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f8bd37c3f847
https://hg.mozilla.org/mozilla-central/rev/2be7cfd01d8b

Comment 10

[Jean-Yves Avenard [:jya]]

Comment on attachment 8577945 [details] [diff] [review]
Part1. Be more relaxed when parsing h264 codecs' levels

Blanket approval for both patches

Approval Request Comment
[Feature/regressing bug #]:1143586
[User impact if declined]:webref tests recently re-enabled will fail.
[Describe test coverage new/current, TreeHerder]:In m-c for over a week.
[Risks and why]: Low, this only allow playing data we would have previously refused.
[String/UUID change made/needed]: None

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/13857368ae36
https://hg.mozilla.org/releases/mozilla-aurora/rev/ea7b4e8ae629

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Had to re-annotate mediasource-addsourcebuffer.html as failing on Windows.
https://hg.mozilla.org/releases/mozilla-aurora/rev/55d8ab6f1700

Comment 13

[Jean-Yves Avenard [:jya]]

now that is totally un-expected..

it certainly shouldn't fail unless the not everything got backported at once or out of order.