CanPlay returns false if codecs is avc1.4d4001

RESOLVED FIXED in Firefox 38

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: jya, Assigned: jya)

Tracking

(Blocks: 1 bug)

Trunk
mozilla39
x86
macOS
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox38 fixed, firefox39 fixed)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Assignee)

Description

4 years ago
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)
(Assignee)

Comment 1

4 years ago
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.
Attachment #8577945 - Flags: review?(cpearce)
(Assignee)

Updated

4 years ago
Assignee: nobody → jyavenard
Status: NEW → ASSIGNED
(Assignee)

Comment 2

4 years ago
Posted patch Part2. Update webref results (obsolete) — Splinter Review
Turned out, we failed all those tests only due to the codecs provided\!
Attachment #8577946 - Flags: review?(karlt)
(Assignee)

Comment 3

4 years ago
Posted patch Part2. Update webref results (obsolete) — Splinter Review
Test will fail on XP and Linux as MP4 isn't supported
Attachment #8577989 - Flags: review?(karlt)
(Assignee)

Updated

4 years ago
Attachment #8577946 - Attachment is obsolete: true
Attachment #8577946 - Flags: review?(karlt)
Attachment #8577945 - Flags: review?(cpearce) → review+
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.
Attachment #8577989 - Flags: review?(karlt) → review+
(Assignee)

Comment 7

4 years ago
Carrying r+
(Assignee)

Updated

4 years ago
Attachment #8577989 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/f8bd37c3f847
https://hg.mozilla.org/mozilla-central/rev/2be7cfd01d8b
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
(Assignee)

Comment 10

4 years ago
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
Attachment #8577945 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

4 years ago
Flags: needinfo?(giles)
status-firefox38: --- → affected
Attachment #8577945 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Had to re-annotate mediasource-addsourcebuffer.html as failing on Windows.
https://hg.mozilla.org/releases/mozilla-aurora/rev/55d8ab6f1700
(Assignee)

Comment 13

4 years ago
now that is totally un-expected..

it certainly shouldn't fail unless the not everything got backported at once or out of order.
Flags: needinfo?(giles)
You need to log in before you can comment on or make changes to this bug.