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
Mac OS X
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
Created attachment 8577945 [details] [diff] [review]
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.
Attachment #8577945 - Flags: review?(cpearce)
(Assignee)

Updated

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

Comment 2

4 years ago
Created attachment 8577946 [details] [diff] [review]
Part2. Update webref results

Turned out, we failed all those tests only due to the codecs provided\!
Attachment #8577946 - Flags: review?(karlt)
(Assignee)

Comment 3

4 years ago
Created attachment 8577989 [details] [diff] [review]
Part2. Update webref results

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
Created attachment 8578440 [details] [diff] [review]
Part2. Update webref results

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.