I can repro this bug on Mac. It not repro on Windows though. no reported error on console. dale@, can you take a look?

Not sure why it would work in MSE but not src=.

That stream doesn't work in MSE on ToT. Per chrome://media-internals:

00:00:00 82	error	Failure parsing MP4: Detected unfragmented MP4. Media Source Extensions require ISO BMFF moov to contain mvex to indicate that Movie Fragments are to be expected.

janus.zone@: Are you certain that the video you attached played for Canary Chrome using MSE? If so, please specify more details (Chrome version, chrome://media-internals output for the MSE player). This stream doesn't appear to be compliant with MSE's ISO-BMFF bytestream format (for reasons indicated in the error message, above). See also https://w3c.github.io/media-source/isobmff-byte-stream-format.html

This video is corrupted beyond reasonable ability to work around.

Playing with ffplay prints these messages (in bold red):

  [h264 @ 0x7ff5f00049e0] SPS changed in the middle of the frame0/0   
  [h264 @ 0x7ff5f00049e0] decode_slice_header error
  [h264 @ 0x7ff5f00049e0] concealing 360 DC, 360 AC, 360 MV errors in I frame
  [h264 @ 0x7ff5f00079c0] SPS changed in the middle of the frame
  [h264 @ 0x7ff5f00079c0] decode_slice_header error
  [h264 @ 0x7ff5f00079c0] concealing 360 DC, 360 AC, 360 MV errors in I frame

The error reported by the Mac OS X platform decoder (to stderr) is less specific:

  GVA error: scheduleDecodeFrame kVTVideoDecoderBadDataErr, error in field pic flags

@wolenetz: The file was not loaded in MSE directly, but first converted to chunked MP4. I can send the binary files if needed.

The bug isn't in the fact that the video won't play necessarily. It would also be acceptable if an error is thrown. This is however not the case. The player goes in a playing state but does not start playback.

Re-opening. The decode error event is being emitted correctly, but Blink isn't acting like it found out. Updating title for clarity.

w.r.t. MSE: Without a set of repro steps of the exact sequence of MSE API operations, it's hard to say why stable Chrome doesn't work and Canary does, though I very strongly suspect that the fix (in M50) for  bug 229412  is the reason.

This doesn't change the apparent fact that sandersd@ reports a (decode?) error event is not triggering pipeline/blink/htmlmediaelement transition to error state for regular src= playback for the file attached in OP.

+philipj@

This is looking like it may be a Blink bug. Media channel looks like this:

  setNetworkState(6)
  mediaEngineError(3)
  setShouldDelayLoadEvent(false)

video.error returns 3, but the controls stay enabled.

Looking further, I'm not sure the controls are supposed to become disabled, this may be WAI.

If that's the case (Philip can shed light there), then the situation is actually that there is an error event being emitted. The only thing that's not happening is some visual indication to the user. This is similar to what happens when an unsupported media format is provided, c.f. https://bugs.chromium.org/p/chromium/issues/detail?id=587678#c8

That's right, the media controls aren't doing anything very smart in the case of errors. dalecurtis@ just changed them so at least the media element is paused, but it's still a far way from obvious that there was an error.

Okay, then given that I cannot reproduce the error event not being emitted, there does not appear to be a bug here.

There is already ongoing work to improve communication when errors occur (eg.  issue 472253 , but there are also plans to visually change the element), I'll close this in preference to those threads.