Including a few folks who have previously worked on issues related to PIPELINE_ERROR_DECODE errors.

We'll take a look; working on repro now. Does this only happen on Mac? What if you disable accelerated video decode in chrome://flags?

err, just saw your note that disable hardware decode makes this work => sandersd

Only tested on Mac, haven't tried on Windows. Repro should hopefully be simple and self-contained from the zip file attached to the first post.

I am unable to reproduce this issue on Chrome Canary 61.0.3115.0/macOS 10.12.4. The repro.m3u8 case plays through as expected and no errors are reported by VTVDA.

I also tested Chrome Stable 58.0.3029.110, with the same result.

My MacBook has an identical configuration to the original report.

#0: Can you confirm whether this still reproduces for you? Does it reproduce on other Macs? Is there any information logged at the bottom of chrome://gpu after the playback failure?

After trying to narrow down the repro even more (rather than sharing a zip file of contents), I am also not reproing the problem on the public hls.js demo page.

I've been testing on an earlier build of hls.js (roughly v0.6.2), and the public version is on v0.7.9, so it seems likely that the bug is in hls.js itself, and has been fixed at some point between 0.6.2 and now.

Is there any way to get more debug information from Chrome when this happens? chrome://gpu doesn't report any problems, and chrome://media-internals only shows "pipeline decode error". With more details, we might be able to figure out what the problem in hls.js is.

Thanks for your help so far!

For the specific case of hardware decode on Mac, the error messages are currently reported to chrome://gpu. I am working to bring those into chrome://media-internals eventually.

For things that fail with software decode, the error messages are now included in chrome://media-internals (c.f. commit 68e83a343963981524faa8e03fc6cc274ecc8409).

Typically in these cases I would run a debug build of Chrome which reports more messages. There is ongoing effort to move the useful ones into release builds. (The trade-off is increased binary size for all the strings.)

If you have a reliable repro for this issue, I will run it in a debug build and, if possible, expose any additional messages that produces.

Here's a reliable repro from the public version of hls.js:

git clone https://github.com/video-dev/hls.js.git
cd hls.js
git checkout v0.6.2-3
npm install
npm run dev

Once that's running, open this page in the browser: Open http://localhost:8000/demo/?src=https%3A%2F%2Ftabby-hair.glitch.me%2Ftwitter-repro.m3u8&enableStreaming=true&autoRecoverError=false&enableWorker=false&levelCapping=-1&defaultAudioCodec=undefined

Playback will break at the 4-second mark, while latest master from that repo works fine.

Thanks for checking in a debug build!

One of the engineers on my team did some more digging and found that the problem is this hls.js issue, which was fixed in v0.6.2-6: https://github.com/video-dev/hls.js/issues/644

I'm not sure if it would have been possible for Chrome to show more debug information for this particular problem, but I wanted to share the root cause of our problem. 

Thanks again for your help in debugging this. Feel free to resolve this issue.

Root cause is failure to parse the H.264 stream:

[83354:775:0601/104800.284946:VERBOSE3:avc.cc(190)] IsValidAnnexB
[83354:775:0601/104800.285187:VERBOSE4:h264_parser.cc(486)] NALU found: size=38
[83354:775:0601/104800.285384:VERBOSE4:h264_parser.cc(507)] NALU type: 7 at: 0x7f96584ceb14 size: 34 ref: 3
[83354:775:0601/104800.285572:VERBOSE3:avc.cc(214)] nal_unit_type 7
[83354:775:0601/104800.285755:VERBOSE4:h264_parser.cc(486)] NALU found: size=8
[83354:775:0601/104800.285935:VERBOSE4:h264_parser.cc(507)] NALU type: 8 at: 0x7f96584ceb3a size: 4 ref: 3
[83354:775:0601/104800.286118:VERBOSE3:avc.cc(214)] nal_unit_type 8
[83354:775:0601/104800.286303:VERBOSE4:h264_parser.cc(486)] NALU found: size=14
[83354:775:0601/104800.286468:VERBOSE4:h264_parser.cc(507)] NALU type: 6 at: 0x7f96584ceb42 size: 10 ref: 0
[83354:775:0601/104800.286663:VERBOSE3:avc.cc(214)] nal_unit_type 6
[83354:775:0601/104800.286810:VERBOSE4:h264_parser.cc(486)] NALU found: size=79
[83354:775:0601/104800.286948:VERBOSE4:h264_parser.cc(507)] NALU type: 6 at: 0x7f96584ceb50 size: 75 ref: 0
[83354:775:0601/104800.287079:VERBOSE3:avc.cc(214)] nal_unit_type 6
[83354:775:0601/104800.287206:VERBOSE4:h264_parser.cc(486)] NALU found: size=7
[83354:775:0601/104800.287332:VERBOSE4:h264_parser.cc(507)] NALU type: 6 at: 0x7f96584ceb9f size: 3 ref: 0
[83354:775:0601/104800.287463:VERBOSE3:avc.cc(214)] nal_unit_type 6
[83354:775:0601/104800.287606:VERBOSE4:h264_parser.cc(486)] NALU found: size=4
[83354:775:0601/104800.287764:VERBOSE1:h264_parser.cc(502)] Error in stream: invalid value, expected data == 0

I agree with the hls.js issue that https://github.com/video-dev/hls.js/commit/9ccbc9bc7f629a693fa77863e91d4abd59c1a4da was the likely fix; hls.js was producing corrupt H.264 streams in this case.

For this specific failure, we never actually make it to the decoder, but instead fail while converting the stream in preparation for that. This would affect CrOS as well, and probably Windows too. I'll file a separate bug for deciding how to surface these sorts of errors.

Logging errors in this case is filed as issue 728719.