Able to reproduce this issue on latest stable 67.0.3396.62 and on latest canary 69.0.3450.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04.

Good Build: 67.0.3375.0
Bad Build: 67.0.3377.0

You are probably looking for a change made after 544580 (known good), but no later than 544581 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/17b7ff2ff8e107b0e9cebcd9d6894072acc98639..53f2cab46eacdcc6a17ed01e62acd813cca5ff44

Reviewed-on: https://chromium-review.googlesource.com/971767

Suspecting same from changelog.

@wolenetz: Please confirm the bug and help in re-assigning if this is not related to your change. Adding RB-Stable as this is a recent regression. Please change if not the case.

Thanks!

 Issue 849379  has been merged into this issue.

Hubbe, please take a look. I cannot change assignment from mobile and I'm out sick today. Liberato or xhwang can assist; from blame it looks like ffmpeg.

can repro locally.  file might just be badly encoded -- ffmpeg is now more strict than it was.

will check with an h264 expert and update.

+sandersd

ffprobe version N-91183-g58c96127b6 Copyright (c) 2007-2018 the FFmpeg developers
  built with gcc 7 (Debian 7.3.0-5)
  configuration: 
  libavutil      56. 18.102 / 56. 18.102
  libavcodec     58. 19.104 / 58. 19.104
  libavformat    58. 17.100 / 58. 17.100
  libavdevice    58.  4.100 / 58.  4.100
  libavfilter     7. 24.100 /  7. 24.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x56243b929b00] STSC entry 984 is invalid (first=1 count=1 id=1)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x56243b929b00] STSC entry 983 is invalid (first=1 count=1 id=1)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x56243b929b00] STSC entry 982 is invalid (first=1 count=1 id=1)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x56243b929b00] STSC entry 981 is invalid (first=1 count=1 id=1)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x56243b929b00] STSC entry 980 is invalid (first=1 count=1 id=1)

[...all the way to entry 1...]

For ease of reference, the suspected CL was reviewed in https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/971356, and has been merged by upstream FFmpeg (https://patchwork.ffmpeg.org/patch/8051/). It will not be reverted because it was a fix for a TSAN issue, but I will investigate whether there is a different workaround that should be considered.

This demuxer failure case was reported as https://trac.ffmpeg.org/ticket/7165 and a workaround has been applied upstream (FFmpeg commit fe84f70819d6f5aab3c4823290e0d32b99d6de78).

The fix has already been pulled into Chrome and will be included in a future release. I will leave it to someone else to decide whether to cherry-pick the fix sooner.

Note that the media is invalid, and the best fix is to correct the invalid STSC atom.

Chiming in from the consumer ops side as an FYI, we aren't currently seeing any spikes in our feedback channels for videos not working. Thanks!

Thank you  craigtumblison@. 
We are not considering this as blocker for M67 stable respin tomorrow, reasons below:
* M67 has been out since 05/29 at small percentage of users for Win/Mac and 100% Linux. So far we only received 1 bug report with just 2 stars. 
* Dupe  Issue 849379  listed at comment #3 is reported on M66
* Per comment #10, no spike in user report for this.
* This issue is still under investigation and fix is not yet ready.
* Tomorrow's M67 stable release includes critical bug fixes.

Note: Pls continue to investigate this, we will take this fix/merge in for future M67 stable respin (if any) if more users are affected by this. 

Pls let us know ASAP if there is any concern here. Thank you.

Thank you  liberato@ and  sandersd@ for taking a look and investigation.

if we're not seeing any issues (we're at 10% right now?) then i'd suggest that we roll it into 69 and maybe back to 68 once it's had some soak time.

Correct, we're at 10% for Win & Mac, 100% for Linux (M67 Stable version 67.0.3396.62) since 05/29.

SGTM to roll it into 69 and maybe back to 68 once it's had some soak time. Thank you.

liberato@ / hubbe@, is there a crbug tracking the potential merge to M68 of the fix (ffmpeg's fe84f70819d6f5aab3c4823290e0d32b99d6de78)?

The most recent FFmpeg roll was well before the M68 branch cut, this fix is already in M68.

Ah good point. Thanks Dan! (And Frank!)