Unable to reproduce the issue on reported chrome version #69.0.3497.100  and latest chrome #72.0.3588.0 on windows 10 by following below steps.

Steps:
=====
1.Launched chrome.
2.Navigated to "http://jsfiddle.net/v1j3beaL/3/"
3.Attached the given video file(good_big.mp4 mentioned in comment#0).
4.Opened chrome://media-internals/.
5.Waited for some time but unable to observe any event Selected video track: [].
6.Switched back to tab with video, observed the video is getting played.
Note: Tried multiple time by waiting ~5mins but unable to reproduce the issue.

Attached screencast for reference.
Reporter: Could you please review attached screencast and let us know if anything is being missed here. Request you to retry the issue by creating a new person without any apps and extensions installed, reset all flags to default on latest chrome and let us know if the issue still persists.
Thanks.!

Deleted: 897036.mp4 2.4 MB

	897036.mp4 2.4 MB View Download

I made a record how to reproduce this issue, may be it will help

I can provide any other required details

Deleted: Recording #1.mp4 3.5 MB

	Recording #1.mp4 3.5 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

swarnasree.mukkala@chromium.org Should i create new issue?

Able to reproduce the issue on reported chrome version #69.0.3497.100, latest stable #70.0.3568.102 and latest chrome #72.0.3611.0 using Mac 10.13.6, Windows 10 and Ubuntu 17.10 and issue is not seen on M-63 builds with sample URL and steps as per comment#0.
We will provide bisect information soon. Hence adding Needs-Bisect label and marking it as Untraiged.
Thanks.!

When tried to bisect the issue, observed that the issue has an inconsistent behaviour on Windows 10, Mac OS 10.14 and Ubuntu 17.10. Hence we could not provide bisect information, tentatively removong Needs-Bisect label.
Requesting someone from Blink>Media team to kindly look into the issue.
Thanks.!

Hello, any updates on this?

Hello, any updates on this?

Since the workaround has been removed as of the latest release, any updates on this?

The provided media does not have a 5 second keyframe distance, but the MP4 metadata claims that it does. As a result, the media log includes:

    00:00:00.017	debug	ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
    00:00:00.017	debug	ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
    00:00:00.017	debug	ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
    00:00:00.017	debug	ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
    00:00:00.017	debug	ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
    00:00:00.017	debug	ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
    00:00:00.017	debug	ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
    00:00:00.017	debug	ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
    00:00:00.017	debug	ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
    00:00:00.017	debug	(Log limit reached. Further similar entries may be suppressed): ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.

Using ffprobe, we can extract a complete list of real video keyframes:

    $ ffprobe -select_streams v -show_frames good_big.mp4 | egrep 'key_frame|best_effort_timestamp_time' | grep -A1 key_frame=1 | grep best_effort_timestamp_time 2>/dev/null
    best_effort_timestamp_time=0.000000
    best_effort_timestamp_time=14.666667
    best_effort_timestamp_time=20.533333
    best_effort_timestamp_time=35.533333
    best_effort_timestamp_time=46.800000
    best_effort_timestamp_time=61.800000
    best_effort_timestamp_time=76.800000
    best_effort_timestamp_time=91.800000
    best_effort_timestamp_time=102.066667
    best_effort_timestamp_time=117.066667
    best_effort_timestamp_time=132.066667
    best_effort_timestamp_time=147.066667
    best_effort_timestamp_time=154.800000


Enabling the MseBufferByPts feature also enables a workaround for incorrectly marked keyframes ( issue 879734 ); the result is that background track disable never triggers (keyframe distance too large). I am marking this bug as dependent on MseBufferByPts rollout.

@#12 in addition to  issue 879734 ,  issue 892365  in particular scoped the usage of mp4 video frame contents' keyframeness metadata to only when MseBufferByPts is enabled. (This agrees with your post, just adds another bug link.)