Hls.js: ChromeOS hls videos do not play

[phillydogg28]

Environment

• [x] The stream has correct Access-Control-Allow-Origin headers (CORS)
• [x] There are no network errors such as 404s in the browser console when trying to play the stream
• [x] The issue observed is not already reported by searching on Github under https://github.com/dailymotion/hls.js/issues
• [x] The issue occurs in the latest reference client on http://dailymotion.github.io/hls.js/demo and not just on my page
• Link to playable M3U8 file:
  m3u8 file
  The m3u8 file generation is time sensitive for security reasons, if you receive a 403 error from this link, go to this page, view source and around line 214 you should see another link inside an addProtocol function.
• Hls.js version:
  v0.6.2-3
• Browser name/version:
  Google Chrome on ChromeOS 52.0.2743.85
• OS name/version:
  ChromeOS firmware Edgar.7287.167.17

Steps to reproduce

1. Load the m3u8 file into http://dailymotion.github.io/hls.js/demo/ on Google Chrome on ChromeOS.
2. The first segment will play with a weird aspect ratio then it stops playing. This behavior cannot be reproduced on an VM.
   

   Expected behavior

The video would play with hls.js.

Actual behavior

Plays first segment then stops.

Console output

This is the part of the log that has the error message.

[log] > startLoad
logger.js:37 [log] > demuxing in webworker
logger.js:37 [log] > configure startPosition @2.670429
logger.js:37 [log] > resuming video
logger.js:37 [log] > engine state transition from STOPPED to IDLE
logger.js:37 [log] > Loading 0 of [0 ,10],level 3, currentTime:2.670429,bufferEnd:2.670
logger.js:37 [warn] > abort previous fragment loader for type:main
logger.js:37 [log] > engine state transition from IDLE to FRAG_LOADING
logger.js:37 [log] > configure startPosition @-1
logger.js:37 [error] > internal error happened while processing hlsMediaAttached:Failed to read the 'buffered' property from 'SourceBuffer': This SourceBuffer has been removed from the parent media source.(anonymous function) @ logger.js:37onEventGeneric @ event-handler.js:67onEvent @ event-handler.js:53EventEmitter.emit @ events.js:92trigger @ hls.js:142onMediaSourceOpen @ buffer-controller.js:106
4?src=https%3A%2F%2F%2F%2Fvideo.medbridgeeducation.com%2Fm3u8%2Fd5qrsvq3z.m3u8%3Fexpiration%3D147035…:783 Uncaught InvalidStateError: Failed to read the 'buffered' property from 'SourceBuffer': This SourceBuffer has been removed from the parent media source.checkBuffer @ ?src=https%3A%2F%2F%2F%2Fvideo.medbridgeeducation.com%2Fm3u8%2Fd5qrsvq3z.m3u8%3Fexpiration%3D147035…:783
logger.js:37 [log] > Loaded  0 of level 3
logger.js:37 [log] > engine state transition from FRAG_LOADING to PARSING
logger.js:37 [log] > Demuxing 0 of [0 ,10],level 3, cc 0
?src=https%3A%2F%2F%2F%2Fvideo.medbridgeeducation.com%2Fm3u8%2Fd5qrsvq3z.m3u8%3Fexpiration%3D147035…:783 Uncaught InvalidStateError: Failed to read the 'buffered' property from 'SourceBuffer': This SourceBuffer has been removed from the parent media source.checkBuffer @ ?src=https%3A%2F%2F%2F%2Fvideo.medbridgeeducation.com%2Fm3u8%2Fd5qrsvq3z.m3u8%3Fexpiration%3D147035…:783
logger.js:37 [log] > creating sourceBuffer with mimeType:audio/mp4;codecs=mp4a.40.2
logger.js:37 [log] > creating sourceBuffer with mimeType:video/mp4;codecs=avc1.42e00a
logger.js:37 [log] > track:audio,container:audio/mp4,codecs[level/parsed]=[mp4a.40.2/mp4a.40.5]
logger.js:37 [log] > track:video,container:video/mp4,codecs[level/parsed]=[avc1.42e00a/avc1.4d4016]
logger.js:37 [log] > parsed audio,PTS:[0.067,6.253],DTS:[0.067/6.253],nb:290,dropped:0
logger.js:37 [log] > parsed video,PTS:[0.067,6.273],DTS:[0.000/6.240],nb:187,dropped:0
logger.js:37 [log] > engine state transition from PARSING to PARSED
logger.js:37 [log] > main buffered : [0.066729,6.239599]

[phillydogg28]

I disabled "Hardware-accelerated video decode" in chrome://flags and videos started to work on ChromeOS. This isn't an ideal solution for clients but hopefully can help debug the problem.

[jlmcdonald]

I'm wondering if Chrome 52 has introduced some changes with either video decoding or even MSE ... we've also noticed a lot of video decode errors on Chromebooks the past few days (they can be recovered with hls.recoverMediaError(), but that also isn't ideal as it unloads the media and flashes the poster image for a fraction of a second) on streams that used to work smoothly; there's also a lot more A/V sync issues when encountering EXT-X-DISCONTINUITY tags. I'll prepare a sample stream and post here in the morning that might add to the debugging process.

[gnitnuj]

Like @phillydogg28, I wasn't able to get video to render until disabling "Hardware-accelerated video decode" either. Going to investigate further.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.