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)
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: nobody → jyavenard
Status: NEW → ASSIGNED
Turned out, we failed all those tests only due to the codecs provided\!
Test will fail on XP and Linux as MP4 isn't supported
Attachment #8577989 - 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+
Attachment #8577989 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
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?
Attachment #8577945 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox38: affected → fixed
Had to re-annotate mediasource-addsourcebuffer.html as failing on Windows. https://hg.mozilla.org/releases/mozilla-aurora/rev/55d8ab6f1700
now that is totally un-expected.. it certainly shouldn't fail unless the not everything got backported at once or out of order.
You need to log in before you can comment on or make changes to this bug.