cc+=abdulsyed@ -> this will help reduce stability risk for M70 when it goes to stable, until MseBufferByPts variation proportion is 100% on stable. Once I get a change to fix this in ToT landed and baked, I'll request ASAP merge to M70.

trunk CL: https://chromium-review.googlesource.com/c/chromium/src/+/1263426

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

commit 5e0f6329a8f3715639f77459fd3ca7ce4f86cce3
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Fri Oct 05 01:19:04 2018

MSE: Prefer video keyframeness analysis over MP4 only if MseBufferByPts

To prevent potentially regressing legacy buffering-by-DTS MSE apps that
may deliberately provide incorrect video keyframeness metadata in their MP4,
this change preserves trust in that metadata when MseBufferByPts is not
enabled. If MseBufferByPts is enabled, this change preserves the recently
added behavior where video frame analysis results' keyframeness (if
implemented and determined) is used instead of the MP4's metadata.

BUG= 892365 
R=sandersd@chromium.org
TEST=MP4StreamParserTest.*AVC*Mismatches*, also manually confirmed
SPS/PPS injection/lack of injection matches the expected sequence of
Parsed{Non}Keyframe in those tests.

Change-Id: If756e0ee882ec17c0d13d7b400aa43626cedaca9
Reviewed-on: https://chromium-review.googlesource.com/c/1263426
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596954}
[modify] https://crrev.com/5e0f6329a8f3715639f77459fd3ca7ce4f86cce3/media/formats/mp4/avc.cc
[modify] https://crrev.com/5e0f6329a8f3715639f77459fd3ca7ce4f86cce3/media/formats/mp4/mp4_stream_parser.cc
[modify] https://crrev.com/5e0f6329a8f3715639f77459fd3ca7ce4f86cce3/media/formats/mp4/mp4_stream_parser_unittest.cc

How safe is this merge overall? Chances of introducing new regressions?

Let's verify this in canary first.

Will bake in Canary over the weekend and request merge to M70 Monday morning PDT.

It shouldn't introduce new regressions. It's intended to protect Stable M70 population from regression for some sites that intentionally rely on older, noncompliant behavior. This change lets them rely on the old keyframeness behavior when the new buffering behavior isn't enabled, while they fix their site content. We planned to begin variations in Stable in M70 of the new buffering behavior, so this also gives them the ability to communicate to their users to disable the new buffering behavior (until the new buffering behavior becomes the *only* behavior later).

tl;dr: Should be safe, and should help prevent M70 stable regression for that sub-population.

servolk@, FYI. See b/112047888 c#70-71

No regressions found for #3's bake in Canary. Requesting merge-to-M70 of #3 (see also #4-#6).

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

commit ac9c86c7503265b2b22c51a90841f324271e535e
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Mon Oct 08 19:39:38 2018

To M70: MSE: Prefer video keyframeness analysis over MP4 only if MseBufferByPts

To prevent potentially regressing legacy buffering-by-DTS MSE apps that
may deliberately provide incorrect video keyframeness metadata in their MP4,
this change preserves trust in that metadata when MseBufferByPts is not
enabled. If MseBufferByPts is enabled, this change preserves the recently
added behavior where video frame analysis results' keyframeness (if
implemented and determined) is used instead of the MP4's metadata.

BUG= 892365 
TBR=​sandersd@chromium.org
TEST=MP4StreamParserTest.*AVC*Mismatches*, also manually confirmed
SPS/PPS injection/lack of injection matches the expected sequence of
Parsed{Non}Keyframe in those tests.

Change-Id: If756e0ee882ec17c0d13d7b400aa43626cedaca9
Reviewed-on: https://chromium-review.googlesource.com/c/1263426
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#596954}(cherry picked from commit 5e0f6329a8f3715639f77459fd3ca7ce4f86cce3)
Reviewed-on: https://chromium-review.googlesource.com/c/1269295
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#901}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/ac9c86c7503265b2b22c51a90841f324271e535e/media/formats/mp4/avc.cc
[modify] https://crrev.com/ac9c86c7503265b2b22c51a90841f324271e535e/media/formats/mp4/mp4_stream_parser.cc
[modify] https://crrev.com/ac9c86c7503265b2b22c51a90841f324271e535e/media/formats/mp4/mp4_stream_parser_unittest.cc

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

Commit: ac9c86c7503265b2b22c51a90841f324271e535e
Author: wolenetz@chromium.org
Commiter: wolenetz@chromium.org
Date: 2018-10-08 19:39:38 +0000 UTC

To M70: MSE: Prefer video keyframeness analysis over MP4 only if MseBufferByPts

To prevent potentially regressing legacy buffering-by-DTS MSE apps that
may deliberately provide incorrect video keyframeness metadata in their MP4,
this change preserves trust in that metadata when MseBufferByPts is not
enabled. If MseBufferByPts is enabled, this change preserves the recently
added behavior where video frame analysis results' keyframeness (if
implemented and determined) is used instead of the MP4's metadata.

BUG= 892365 
TBR=​sandersd@chromium.org
TEST=MP4StreamParserTest.*AVC*Mismatches*, also manually confirmed
SPS/PPS injection/lack of injection matches the expected sequence of
Parsed{Non}Keyframe in those tests.

Change-Id: If756e0ee882ec17c0d13d7b400aa43626cedaca9
Reviewed-on: https://chromium-review.googlesource.com/c/1263426
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#596954}(cherry picked from commit 5e0f6329a8f3715639f77459fd3ca7ce4f86cce3)
Reviewed-on: https://chromium-review.googlesource.com/c/1269295
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#901}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}