+mse

I haven't looked at the file yet and am no expert, but some thoughts:

Isn't a fragmented mp4 required to start with a keyframe? So the last two cases are not quite the same as manually cutting the first segment?

Assuming you do have proper keyframes, just skipping the segments without re-timecoding them isn't sufficient. So dropping just the first segment probably requires you to either seek to the right time code or set timestampOffset appropriately.

I agree that the last two cases are different from the first four, I added them for completeness. As for your remarks, here is some additional info:
- The segments were analyzed with a ISOBMFF analyzer which reported that they all start with a key frame.
- The provided code seeks to the start of buffer. This results in an error in the two failing cases (2 and 4) since the video element reports the buffer as empty.

Thanks for the details. I took a look and I'm not sure why it's not playing. There are no errors emitted which is a problem at least. Adjusting timestampOffset does not fix anything.

One thing that I did notice is that ffmpeg doesn't report the individual packets as being flagged as keyframes, even though cat init.dash + 1.dash > out.mp4 into Mp4box shows the first sample as marked as keyframe. I wonder if somehow we're dropping data thinking it's not a keyframe.

I'll take a look now that I'm back from vacation. Thanks for your patience.

MP4 has multiple ways of marking coded frames as keyframes. I'll check the files to see what Chrome thinks about them -- it's likely that no keyframes were ever detected by Chrome, hence nothing buffered. Seek in an unbuffered MSE media element itself shouldn't cause error -- if the error is coming from the seek operation itself in Chrome, that could also be a bug. Regardless, I'll look today.

I don't think there's any error thrown other than an unchecked access to .buffered.start(0) when buffered.length==0. So the hypothesis that it's just not detecting the key frame markings seems plausible.

It looks like the media only has precisely 1 keyframe: the very first frame in the first segment. MSE drops any non-keyframes parsed since the beginning of parsing (or since the last discontinuity detected by the coded frame processing algorithm, or after an explicit abort() operation).

So nothing buffered in cases 2 and 4 is working as intended, assuming Chrome is correctly identifying there is no keyframe in the media segments appended in those cases.

Further, no parse error or other error is expected per specification in such case.

Examining the frame sizes in cases 2 and 4, there are periodic spikes; possibly for frames incorrectly marked non-keyframes.

I've attached some log captures from a local build for each of cases 1, 2, and 4, filtered to show each coded frame parsed from the ISO-BMFF stream, in the sequence they are emitted to be processed by the MSE coded frame processing algorithm. Cases 2 and 4 logs do not differ. The latter part of case 1 matches case 2.

Deleted: case_1.log 22.2 KB

case_1.log 22.2 KB View Download

Deleted: case_2.log 19.0 KB

case_2.log 19.0 KB View Download

Deleted: case_4.log 19.0 KB

case_4.log 19.0 KB View Download

@#9 clarification of my wording: It is working as intended that nothing is buffered in cases 2 and 4 (since no keyframes were parsed).

@#9 more clarification: MSE drops any non-keyframes parsed since the beginning of parsing...until a keyframe is parsed.

It's not clear to me that they aren't keyframes though, since init + 1 plays:

http://xorax.sea.corp.google.com/mstest/segments/out-1.mp4

MP4Box also thinks that file has a keyframe at the beginning, but neither ffmpeg nor Chrome think so... so it's unclear how mp4box is determining that.

+sandersd who might know why; see c#12.

Chrome MSE MP4 parser detected a keyframe, but only in the first segment.
It's logic has lots of comments due to the fairly complicated legacy around various media encodings not marking their ISOBMFF keyframes quite right:

https://chromium.googlesource.com/chromium/src/+/542807b25b6e7befcb71e69597fbc45dc3a52e6a/media/formats/mp4/track_run_iterator.cc#191

MP4Box might have some lenience different from Chrome MSE, and maybe just for the first frame in the media.

sandersd@, please take a closer look. Thanks!

One thing to note is that some other implementations of MSE might incorrectly be parsing and *not ignoring* sidx boxes, which can provide information like "starts_with_sap" that can inform whether or not the first indexed access unit of that sidx is perhaps a keyframe.

Using such sidx information in an MSE implementation would not be compliant with the MSE ISOBMFF byte stream format (https://www.w3.org/TR/mse-byte-stream-format-isobmff/).
In particular:
"Valid top-level boxes such as pdin, free, and sidx are allowed to appear before the moov box. These boxes must be accepted and ignored by the user agent and are not considered part of the initialization segment in this specification."

and

"Valid top-level boxes defined in ISO/IEC 14496-12 other than ftyp, moov, styp, moof, and mdat are allowed to appear between the end of an initialization segment or media segment and before the beginning of a new media segment. These boxes must be accepted and ignored by the user agent and are not considered part of the media segment in this specification."

One other bit of info I've now recalled is that other MSE implementations may base their determination of "keyframe-ness" for some codecs based on codec-specific information, disregarding or overriding any such indication in the container itself. For example, an IDR in H.264 in MP4 might be determined as a keyframe by such implementations even if the MP4 doesn't mark the frame as such. In Chrome MSE, we rely on correctly muxed streams. We even have a complementary case  bug 584384 .

Dan, perhaps, as a complement to fixing  bug 584384 , we could also MEDIA_LOG when a codec-bitstream keyframe is not marked keyframe in the container. WDYT?

Please also look into the media for this bug to see if that's what's really happening here.

I took a look; Dan please correct if I'm wrong:
In the sample media, there are multiple coded frames with nal_unit_type 5 (IDR slice); each corresponds to one of the longer periodic codec frames. But only the very first of those is determined to be a keyframe by our parsing of the MP4 container metadata.

This explains how other MSE implementations (and perhaps ffmpeg) can be more lenient: they cross layers and use information from the codec bitstream to determine keyframe-ness.

jeroen.tempels@theoplayer.com: To get this stream to work in Chrome MSE, please remux it with correct keyframe indications in the ISO-BMFF container, not just in the encoded video frames.

From chat w/Dan, the route to MEDIA_LOG when kIDRSplice is seen in any NALU for a coded frame, but the container didn't mark the frame as a keyframe, appears to be the best way forward.

Note also that the MSE spec for the ISO-BMFF bytestream defines random access points in terms of the container, not the coded frames it contains.  Some other MSE implementations may be providing more lenience for handling incorrectly muxed media streams w.r.t. the spec; there are workarounds for handling such streams (in worst case, transmuxing in JS app before appending to MSE).

I'll see about adding a LIMITED_MEDIA_LOG soon.

Thanks for the all the information and investigation! I will remux the stream.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8005190febec38ff366befdab72cbd4b15e9a0c4

commit 8005190febec38ff366befdab72cbd4b15e9a0c4
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Fri Jul 20 00:32:07 2018

MSE: Remove old AVC and HEVC IsValidAnnexB vector wrapper

Chromium's allowed use of C++11's std::vector::data for quite a while
now.  In anticipation of some other refactoring coming soon to the
underlying code, this CL removes the workaround previously in place for
IsValidAnnexB(std::vector, ...) for each of MSE's AVC and HEVC bitstream
conversion utilities.

BUG= 860420 , 584384 

Change-Id: I15f1cedebaa37bbac91cb62456b8322dc70e34c4
Reviewed-on: https://chromium-review.googlesource.com/1144218
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Sergey Volk <servolk@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#576720}
[modify] https://crrev.com/8005190febec38ff366befdab72cbd4b15e9a0c4/media/formats/mp4/avc.cc
[modify] https://crrev.com/8005190febec38ff366befdab72cbd4b15e9a0c4/media/formats/mp4/avc.h
[modify] https://crrev.com/8005190febec38ff366befdab72cbd4b15e9a0c4/media/formats/mp4/avc_unittest.cc
[modify] https://crrev.com/8005190febec38ff366befdab72cbd4b15e9a0c4/media/formats/mp4/hevc.cc
[modify] https://crrev.com/8005190febec38ff366befdab72cbd4b15e9a0c4/media/formats/mp4/hevc.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae

commit 568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Tue Jul 24 22:52:59 2018

MSE: refactor mp4 AnnexB validation to also report keyframe-ness

In preparation for logging when there appears to be a mismatch between
MSE MP4 keyframe metadata and the encoded video bitstream's keyframe
metadata, this change incorporates basic analysis of the latter as part
of the existing Annex-B bitstream validation for MSE MP4 video.

Note that mp4::BitstreamConverter::AnalysisResult contains
base::Optional<bool> for each of conformance and keyframe-ness fields.
If a field doesn't have a value, that portion of the result was not
analyzed.

Note that keyframe analysis is implemented only for AVC currently, but
even that is skipped if the frame is detected as non-conformant before
enough indications of whether or not it is a keyframe are detected.
Neither AVC-DV nor HEVC AnnexB analyses do any actual keyframe analysis,
since such was either skipped or not yet implemented previously,
respectively.

A subsequent CL will use the newly reported MSE MP4 video bitstream
converter's keyframe analysis results, if that analysis was done, in
reporting to chrome://media-internals when the bitstream keyframe-ness
mismatches that of the mp4 container for a coded frame.

BUG= 860420 , 584384 

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I169c7774070ad232c86658bcd7803160323993ad
Reviewed-on: https://chromium-review.googlesource.com/1144456
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Sergey Volk <servolk@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577717}
[modify] https://crrev.com/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae/media/filters/ffmpeg_demuxer_unittest.cc
[modify] https://crrev.com/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae/media/formats/mp4/avc.cc
[modify] https://crrev.com/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae/media/formats/mp4/avc.h
[modify] https://crrev.com/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae/media/formats/mp4/avc_unittest.cc
[modify] https://crrev.com/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae/media/formats/mp4/bitstream_converter.cc
[modify] https://crrev.com/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae/media/formats/mp4/bitstream_converter.h
[modify] https://crrev.com/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae/media/formats/mp4/hevc.cc
[modify] https://crrev.com/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae/media/formats/mp4/hevc.h
[modify] https://crrev.com/568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae/media/formats/mp4/mp4_stream_parser.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/61697367404dc4c7033e389556f01a652f2b6516

commit 61697367404dc4c7033e389556f01a652f2b6516
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Wed Jul 25 00:42:07 2018

MSE: Log when MP4 keyframe-ness mismatches the compressed media

Logs to chrome://media-internals when the container's keyframe metadata
for a frame mismatches the contents of that frame (if the latter was
determined by the respective bitstream converter's Analyze()
implementation, of whom only AVC currently does any keyframe analysis).

BUG= 860420 , 584384 
TEST=Repro crbug 860420 shows logs, new MP4StreamParserTest.AVC_Key* and media

Change-Id: Ic87eab8726ad76b36b569df08ab2212b267008c2
Reviewed-on: https://chromium-review.googlesource.com/1149153
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577751}
[modify] https://crrev.com/61697367404dc4c7033e389556f01a652f2b6516/media/formats/mp4/mp4_stream_parser.cc
[modify] https://crrev.com/61697367404dc4c7033e389556f01a652f2b6516/media/formats/mp4/mp4_stream_parser.h
[modify] https://crrev.com/61697367404dc4c7033e389556f01a652f2b6516/media/formats/mp4/mp4_stream_parser_unittest.cc
[modify] https://crrev.com/61697367404dc4c7033e389556f01a652f2b6516/media/test/data/README
[add] https://crrev.com/61697367404dc4c7033e389556f01a652f2b6516/media/test/data/bear-640x360-v-2frames-keyframe-is-non-sync-sample_frag.mp4
[add] https://crrev.com/61697367404dc4c7033e389556f01a652f2b6516/media/test/data/bear-640x360-v-2frames-nonkeyframe-is-sync-sample_frag.mp4
[add] https://crrev.com/61697367404dc4c7033e389556f01a652f2b6516/media/test/data/bear-640x360-v-2frames_frag.mp4

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9a4096bed9f7071637393d67a2d2fe9f554bfd45

commit 9a4096bed9f7071637393d67a2d2fe9f554bfd45
Author: Zhenyao Mo <zmo@chromium.org>
Date: Wed Jul 25 17:50:12 2018

Revert "MSE: Log when MP4 keyframe-ness mismatches the compressed media"

This reverts commit 61697367404dc4c7033e389556f01a652f2b6516.

Reason for revert:  crbug.com/867520 

Original change's description:
> MSE: Log when MP4 keyframe-ness mismatches the compressed media
> 
> Logs to chrome://media-internals when the container's keyframe metadata
> for a frame mismatches the contents of that frame (if the latter was
> determined by the respective bitstream converter's Analyze()
> implementation, of whom only AVC currently does any keyframe analysis).
> 
> BUG= 860420 , 584384 
> TEST=Repro crbug 860420 shows logs, new MP4StreamParserTest.AVC_Key* and media
> 
> Change-Id: Ic87eab8726ad76b36b569df08ab2212b267008c2
> Reviewed-on: https://chromium-review.googlesource.com/1149153
> Reviewed-by: Dan Sanders <sandersd@chromium.org>
> Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#577751}

TBR=wolenetz@chromium.org,sandersd@chromium.org

Change-Id: I8437af99f24bf04910ad56931a9e91f960a59469
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  860420 ,  584384 
Reviewed-on: https://chromium-review.googlesource.com/1150243
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577968}
[modify] https://crrev.com/9a4096bed9f7071637393d67a2d2fe9f554bfd45/media/formats/mp4/mp4_stream_parser.cc
[modify] https://crrev.com/9a4096bed9f7071637393d67a2d2fe9f554bfd45/media/formats/mp4/mp4_stream_parser.h
[modify] https://crrev.com/9a4096bed9f7071637393d67a2d2fe9f554bfd45/media/formats/mp4/mp4_stream_parser_unittest.cc
[modify] https://crrev.com/9a4096bed9f7071637393d67a2d2fe9f554bfd45/media/test/data/README
[delete] https://crrev.com/352492fdd7794a1c7672bee0e081764a667ebd9b/media/test/data/bear-640x360-v-2frames-keyframe-is-non-sync-sample_frag.mp4
[delete] https://crrev.com/352492fdd7794a1c7672bee0e081764a667ebd9b/media/test/data/bear-640x360-v-2frames-nonkeyframe-is-sync-sample_frag.mp4
[delete] https://crrev.com/352492fdd7794a1c7672bee0e081764a667ebd9b/media/test/data/bear-640x360-v-2frames_frag.mp4

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8fba4f3d294510d3e8317f950c01138d956fd554

commit 8fba4f3d294510d3e8317f950c01138d956fd554
Author: Zhenyao Mo <zmo@chromium.org>
Date: Wed Jul 25 17:50:57 2018

Revert "MSE: refactor mp4 AnnexB validation to also report keyframe-ness"

This reverts commit 568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae.

Reason for revert: <INSERT REASONING HERE>

Original change's description:
> MSE: refactor mp4 AnnexB validation to also report keyframe-ness
> 
> In preparation for logging when there appears to be a mismatch between
> MSE MP4 keyframe metadata and the encoded video bitstream's keyframe
> metadata, this change incorporates basic analysis of the latter as part
> of the existing Annex-B bitstream validation for MSE MP4 video.
> 
> Note that mp4::BitstreamConverter::AnalysisResult contains
> base::Optional<bool> for each of conformance and keyframe-ness fields.
> If a field doesn't have a value, that portion of the result was not
> analyzed.
> 
> Note that keyframe analysis is implemented only for AVC currently, but
> even that is skipped if the frame is detected as non-conformant before
> enough indications of whether or not it is a keyframe are detected.
> Neither AVC-DV nor HEVC AnnexB analyses do any actual keyframe analysis,
> since such was either skipped or not yet implemented previously,
> respectively.
> 
> A subsequent CL will use the newly reported MSE MP4 video bitstream
> converter's keyframe analysis results, if that analysis was done, in
> reporting to chrome://media-internals when the bitstream keyframe-ness
> mismatches that of the mp4 container for a coded frame.
> 
> BUG= 860420 , 584384 
> 
> Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
> Change-Id: I169c7774070ad232c86658bcd7803160323993ad
> Reviewed-on: https://chromium-review.googlesource.com/1144456
> Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
> Reviewed-by: Sergey Volk <servolk@chromium.org>
> Reviewed-by: Dan Sanders <sandersd@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#577717}

TBR=wolenetz@chromium.org,sandersd@chromium.org,servolk@chromium.org

Change-Id: If4d14f0cb6fb0779255b9d7eb3d5b2b8c20e5be1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  860420 ,  584384 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Reviewed-on: https://chromium-review.googlesource.com/1150244
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577969}
[modify] https://crrev.com/8fba4f3d294510d3e8317f950c01138d956fd554/media/filters/ffmpeg_demuxer_unittest.cc
[modify] https://crrev.com/8fba4f3d294510d3e8317f950c01138d956fd554/media/formats/mp4/avc.cc
[modify] https://crrev.com/8fba4f3d294510d3e8317f950c01138d956fd554/media/formats/mp4/avc.h
[modify] https://crrev.com/8fba4f3d294510d3e8317f950c01138d956fd554/media/formats/mp4/avc_unittest.cc
[modify] https://crrev.com/8fba4f3d294510d3e8317f950c01138d956fd554/media/formats/mp4/bitstream_converter.cc
[modify] https://crrev.com/8fba4f3d294510d3e8317f950c01138d956fd554/media/formats/mp4/bitstream_converter.h
[modify] https://crrev.com/8fba4f3d294510d3e8317f950c01138d956fd554/media/formats/mp4/hevc.cc
[modify] https://crrev.com/8fba4f3d294510d3e8317f950c01138d956fd554/media/formats/mp4/hevc.h
[modify] https://crrev.com/8fba4f3d294510d3e8317f950c01138d956fd554/media/formats/mp4/mp4_stream_parser.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a9b7a993e82e84c44dd16f332e55da569ab016c9

commit a9b7a993e82e84c44dd16f332e55da569ab016c9
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Wed Jul 25 23:12:39 2018

Reland "MSE: refactor mp4 AnnexB validation to also report keyframe-ness"

This is a reland of 568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae, which had
been reverted in 8fba4f3d294510d3e8317f950c01138d956fd554 ( bug 867520 )
due to failing link on windows builders with proprietary_codecs in their
build configuration ( bug 867536 ).

Versus the original change, this one includes an additional MEDIA_EXPORT
on the inner type "media::mp4::BitstreamConverter::AnalysisResult".

Original change's description:
> MSE: refactor mp4 AnnexB validation to also report keyframe-ness
>
> In preparation for logging when there appears to be a mismatch between
> MSE MP4 keyframe metadata and the encoded video bitstream's keyframe
> metadata, this change incorporates basic analysis of the latter as part
> of the existing Annex-B bitstream validation for MSE MP4 video.
>
> Note that mp4::BitstreamConverter::AnalysisResult contains
> base::Optional<bool> for each of conformance and keyframe-ness fields.
> If a field doesn't have a value, that portion of the result was not
> analyzed.
>
> Note that keyframe analysis is implemented only for AVC currently, but
> even that is skipped if the frame is detected as non-conformant before
> enough indications of whether or not it is a keyframe are detected.
> Neither AVC-DV nor HEVC AnnexB analyses do any actual keyframe analysis,
> since such was either skipped or not yet implemented previously,
> respectively.
>
> A subsequent CL will use the newly reported MSE MP4 video bitstream
> converter's keyframe analysis results, if that analysis was done, in
> reporting to chrome://media-internals when the bitstream keyframe-ness
> mismatches that of the mp4 container for a coded frame.
>
> BUG= 860420 , 584384 
>
> Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
> Change-Id: I169c7774070ad232c86658bcd7803160323993ad
> Reviewed-on: https://chromium-review.googlesource.com/1144456
> Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
> Reviewed-by: Sergey Volk <servolk@chromium.org>
> Reviewed-by: Dan Sanders <sandersd@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#577717}

Bug:  860420 ,  584384 
Change-Id: I8bbb3abc2079b53a14db8babbf04d5bad9e94767
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Reviewed-on: https://chromium-review.googlesource.com/1150247
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578116}
[modify] https://crrev.com/a9b7a993e82e84c44dd16f332e55da569ab016c9/media/filters/ffmpeg_demuxer_unittest.cc
[modify] https://crrev.com/a9b7a993e82e84c44dd16f332e55da569ab016c9/media/formats/mp4/avc.cc
[modify] https://crrev.com/a9b7a993e82e84c44dd16f332e55da569ab016c9/media/formats/mp4/avc.h
[modify] https://crrev.com/a9b7a993e82e84c44dd16f332e55da569ab016c9/media/formats/mp4/avc_unittest.cc
[modify] https://crrev.com/a9b7a993e82e84c44dd16f332e55da569ab016c9/media/formats/mp4/bitstream_converter.cc
[modify] https://crrev.com/a9b7a993e82e84c44dd16f332e55da569ab016c9/media/formats/mp4/bitstream_converter.h
[modify] https://crrev.com/a9b7a993e82e84c44dd16f332e55da569ab016c9/media/formats/mp4/hevc.cc
[modify] https://crrev.com/a9b7a993e82e84c44dd16f332e55da569ab016c9/media/formats/mp4/hevc.h
[modify] https://crrev.com/a9b7a993e82e84c44dd16f332e55da569ab016c9/media/formats/mp4/mp4_stream_parser.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ae47fd35e9ca08850dc9a3585644616358d49364

commit ae47fd35e9ca08850dc9a3585644616358d49364
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Thu Jul 26 02:16:45 2018

Reland "MSE: Log when MP4 keyframe-ness mismatches the compressed media"

This is a reland of 61697367404dc4c7033e389556f01a652f2b6516, which had
been reverted in 9a4096bed9f7071637393d67a2d2fe9f554bfd45 as part of
reverting 568cc6a9efbcc2cbfbc33d5442dbaa7eaf5ae6ae which had broken some
builders. That CL has now been fixed and relanded
(a9b7a993e82e84c44dd16f332e55da569ab016c9).

This reland is the same as the original.

Original change's description:
> MSE: Log when MP4 keyframe-ness mismatches the compressed media
>
> Logs to chrome://media-internals when the container's keyframe metadata
> for a frame mismatches the contents of that frame (if the latter was
> determined by the respective bitstream converter's Analyze()
> implementation, of whom only AVC currently does any keyframe analysis).
>
> BUG= 860420 , 584384 
> TEST=Repro crbug 860420 shows logs, new MP4StreamParserTest.AVC_Key* and media
>
> Change-Id: Ic87eab8726ad76b36b569df08ab2212b267008c2
> Reviewed-on: https://chromium-review.googlesource.com/1149153
> Reviewed-by: Dan Sanders <sandersd@chromium.org>
> Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#577751}

TBR=sandersd@chromium.org

Bug:  860420 ,  584384 
Change-Id: I5a00819883e71ca9fd8c1a211956bdca66047b54
Reviewed-on: https://chromium-review.googlesource.com/1150541
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578171}
[modify] https://crrev.com/ae47fd35e9ca08850dc9a3585644616358d49364/media/formats/mp4/mp4_stream_parser.cc
[modify] https://crrev.com/ae47fd35e9ca08850dc9a3585644616358d49364/media/formats/mp4/mp4_stream_parser.h
[modify] https://crrev.com/ae47fd35e9ca08850dc9a3585644616358d49364/media/formats/mp4/mp4_stream_parser_unittest.cc
[modify] https://crrev.com/ae47fd35e9ca08850dc9a3585644616358d49364/media/test/data/README
[add] https://crrev.com/ae47fd35e9ca08850dc9a3585644616358d49364/media/test/data/bear-640x360-v-2frames-keyframe-is-non-sync-sample_frag.mp4
[add] https://crrev.com/ae47fd35e9ca08850dc9a3585644616358d49364/media/test/data/bear-640x360-v-2frames-nonkeyframe-is-sync-sample_frag.mp4
[add] https://crrev.com/ae47fd35e9ca08850dc9a3585644616358d49364/media/test/data/bear-640x360-v-2frames_frag.mp4