MSE Debugging -- pipeline: decode error

[dananichev]

MSE Debugging -- pipeline: decode error

[dananichev]

@mangui i've published public restream
Using your demo:
http://dailymotion.github.io/hls.js/demo/?src=http%3A%2F%2Ftolookat.me%2Fstream%2Ftest.m3u8

Direct link
http://tolookat.me/stream/test.m3u8

Stream created using ffmpeg:

ffmpeg -loglevel info -rtsp_transport tcp -i 'source' -vcodec copy -an -y -hls_time 1 -hls_list_size 10 -hls_flags delete_segments

[gmcnaughton]

@dananichev Do you see more information in chrome://media-internals if you scroll down to the bottom of the page where it says "Log"?

My player showed identical symptoms to yours. The media-internals Log showed several "error" events prior to the final pipeline: decode error. One of those errors pointed to the problem with my stream:

00:00:10 677  error Media segment did not begin with key frame. Support for such segments will be available in a future version. Please see https://crbug.com/229412.
00:00:10 677  error Append: stream parsing failed. Data size=131072 append_window_start=0 append_window_end=inf
00:00:10 677  pipeline_error  pipeline: decode error

That message pointed to this bug (https://crbug.com/229412) which is that currently Chrome requires each tls segment to start with a keyframe (even though that's not required by the MSE spec, or other browsers).

Our HLS streams had not been encoded to start with a keyframe at the beginning of every segment, which seems to be what's causing this issue for me.

from hls.js.

[dananichev]

@gmcnaughton error Media segment did not begin with key frame. -- different problem. I mean, currently public test stream can restart ffmpeg proccess under different circumstances. Which can produce this type of errors (plus sometimes rtsp source stream going nuts and this is also can possibly cause this kind of errors).

But ultimately i was trying to describe different issue.

As i said previously In my case there is only pipeline: decode error and nothing more. Thats why i need help with debugging.

There were 3 types of errors so far in my experience:

• decode error due to audio codec issues (thats why i used -an in my test setup with this stream)
• decode error due to keyframes issue
• and decode error with no additional information at all

Also, i should probably narrow this down. I just checked again and in Chrome 46 on Windows 10 (i suppose on any Windows) this stream works fine. But in Chrome 46 on OS X behavior is kind of tricky:

• on first visit chrome://media-internals says nothing wrong, but there is no video - only white screen
• on second visit (just refresh the page) pipeline: decode error and nothing more

Log output in second case:

render_id: 10
player_id: 4
pipeline_state: kStopped
event: WEBMEDIAPLAYER_CREATED
url: blob:http%3A//dailymotion.github.io/ec4797f9-f9b4-460c-b676-e12b77ab1e8b
info: Video codec: avc1.4201f
found_video_stream: true
video_codec_name: h264
duration: 462.952
video_dds: false
video_decoder: GpuVideoDecoder
error: video decode error
pipeline_error: pipeline: decode error

from hls.js.

[gmcnaughton]

@dananichev ah okay, definitely a different issue than ours. Good luck! 👍

[mangui]

@dananichev indeed getting more insights on the root cause of video decoding error with chrome is a mess.
best option would be to check on https://code.google.com/p/chromium/issues and eventually open a ticket there ...

[dananichev]

@mangui ok, i will try to open a ticket on Chromium issues tracker then. Will cross-post anything worth posting here.

[dananichev]

Posted an issue
https://code.google.com/p/chromium/issues/detail?id=550854

[dananichev]

@mangui the problem is gaps_in_frame_num_value_allowed_flag set to 1 (i mean, problem with such streams). Chromium developers will fix this behavior (but it will land only in March approx).

Meanwhile can you suggest some way to change this metadata without re-encoding? In any case, i suppose we can close this issue.

[mangui]

@dananichev gaps_in_frame_num_value_allowed_flag is part of SPS NAL unit.
SPS is parsed to retrieve video metadata, but this specific flag is not read (see here https://github.com/dailymotion/hls.js/blob/master/src/demux/exp-golomb.js#L216)
in order to change this flag, you would have to add a new function in exp-golomb.js

instead of calling
this.skipBits(1); // gaps_in_frame_num_value_allowed_flag
you would have to call
this.writeBit(false); // reset gaps_in_frame_num_value_allowed_flag

but not sure it will even work ...

[dananichev]

@mangui i suppose i need to change it in each chunk separately. Before it reaches browser. I was trying to find solution using ffmpeg (no luck) or any other application.
I think the only possible way is to change this flag manually. Problem is my experience in SPS and NAL's is very limited.

Anyways you can close this issue. If you have any advice on working with SPS manually i will glad to hear it. Thanks!

[mangui]

yes you would have to change each chunk ... either by patching server side or client side with hls.js.
but i am even not sure your stream will be playable if you start to tweak the SPS ...

[exolution]

@mangui how to add the writeBit

[mangui]

something like (not tested)

  writeBit(bitValue) {
    const bitsAvailable = this.bitsAvailable;
    const data = this.data;
    let byteOffset = data.byteLength - this.bytesAvailable - Math.floor(bitsAvailable/8);
    let bitOffset  = 8 - bitsAvailable;
    const bitValueNormalized = bitValue ? 1 : 0;
    const clearMask = ~(1 << bitOffset);
    data[byteOffset] = (data[byteOffset] & clearMask) | (bitValueNormalized << bitPosition);
    this.skipBits(1);
  }

from hls.js.