HLS stream freezes at the same position each time

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Play this HLS stream: 
http://csm-e.cds1.yospace.com/csm/98473142/000070859848.m3u8
2. Wait or seek 53 seconds in
3. Playback stops and never recovers

What version of the product are you using? On what operating system?
Custom receiver
Receiver API version 2.0.0
Media Player Library version 1.0

Original issue reported on code.google.com by lin...@nekomata.se on 6 Nov 2014 at 4:45

[GoogleCodeExporter]

So far we have found that the failure only occurs on the Chromecast, it is fine 
on all other platforms we have tried including Androids known to have issues 
with HLS.

Original comment by lin...@nekomata.se on 10 Nov 2014 at 11:21

[GoogleCodeExporter]

If you turn on DEBUG MPL logging, you can observe that there is a gap in the 
source buffer:

[ 49.657s] [cast.player.core.SourceBufferManager] 0: 0 - 53.84266662597656
[ 49.658s] [cast.player.core.SourceBufferManager] 0: 53.90666580200195 - 
76.76000213623047
[ 49.659s] [cast.player.core.SourceBufferManager] 0: updateend 

We're investigating the cause and also why Chrome can't seem to bridge it.

Original comment by vadi...@chromium.org on 10 Nov 2014 at 5:55

[GoogleCodeExporter]

Original comment by christia...@google.com on 10 Nov 2014 at 6:14

• Changed state: Accepted

[GoogleCodeExporter]

Issue 393 has been merged into this issue.

Original comment by and...@google.com on 10 Nov 2014 at 7:31

[GoogleCodeExporter]

Can Google provide any insight as to why this is causing a problem within 
Chromecast?  If we understood the problem, we could investigate what we can do 
on the encoding/packaging side to workaround the issue.

Original comment by ohwotagi...@gmail.com on 24 Nov 2014 at 12:11

[GoogleCodeExporter]

The latest published version of MPL has logic to detect when playback stalls 
and skip over the gap, so playback should no longer freeze.

The issue us due to Chromium media pipeline not being able to jump over 
timeline gaps in accordance with the MSE specification.

Original comment by vadi...@google.com on 2 Dec 2014 at 7:06

[GoogleCodeExporter]

Any news about what causes the gaps from MPL's point of view? (The streams I 
have do not have a gap in the manifest and playback without problems/gaps using 
Android's VideoView)

Original comment by willlunn...@gmail.com on 2 Dec 2014 at 7:11

[GoogleCodeExporter]

Chromecast's player implementation is based on HTML5 Media Source Extensions 
implementation in Chrome, so the gaps are from the Chrome media pipeline point 
of view, not MPL.  These are not based on the manifest, but on the timing of 
the actual audio/video data.

Original comment by vadi...@google.com on 2 Dec 2014 at 7:18

[GoogleCodeExporter]

OK, so what can we do to debug Chrome's media pipeline?

Original comment by willlunn...@gmail.com on 2 Dec 2014 at 7:26

[GoogleCodeExporter]

Before debugging into Chrome, you would likely want to first inspect your media 
- for example if it's a transport stream, you could use dvbsnoop to look at 
timestamps.

However, the relevant code in Chrome is in

https://code.google.com/p/chromium/codesearch#chromium/src/media/filters/source_
buffer_range.cc

search for GetFudgeRoom.

Original comment by vadi...@google.com on 2 Dec 2014 at 9:34

[GoogleCodeExporter]

Original comment by anad...@google.com on 5 Dec 2014 at 5:44

• Changed state: NotSDK

[GoogleCodeExporter]

Hi,

So I wasn't sure what to look for in the dvbsnoop output, so was planning on 
looking at it properly this weekend. In the mean time, are you suggesting I 
re-file the bug on the Chome issue tracker? e.g. 
https://code.google.com/p/chromium/issues/detail?id=420227&q=chromecast%20HLS&co
lspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20
OS%20Modified

If so, what should I do to make sure the correct people see it? 

While maniging your issue tracker is completely up to you, considering the 
number of duplicate issues that have been filed because of this from different 
developers with different streams, it seems sensible to leave this issue open 
with a status of needing a fix from Chrome and a link to the Chrome issue. 
While the cause of the issue may be Chrome, it definately affects developers 
working with Chromecast.

Original comment by willlunn...@gmail.com on 5 Dec 2014 at 7:44

[GoogleCodeExporter]

On a video that used to stall under MPL 0.6-1.0, with the new MPL 1.0.5 its now 
getting to the gap in the buffer, then very slowly seeking over it by 0.1 
seconds at a time, eventually claring it.

e.g. with the following gap

2014-12-06 09:05:32.447 [270.182s] [cast.player.api.Player] 1: time=4.1294 
media_player.js:24
2014-12-06 09:05:32.702 [270.437s] [cast.player.core.SourceBufferManager] 0: 0 
- 36.74541091918945 media_player.js:24
2014-12-06 09:05:32.706 [270.442s] [cast.player.core.SourceBufferManager] 0: 
54.054412841796875 - 63.39741134643555 media_player.js:24
2014-12-06 09:05:32.710 [270.446s] [cast.player.core.SourceBufferManager] 0: 
updateend 

I see these entries 

2014-12-06 09:06:56.437 [354.172s] [cast.player.api.Player] seeking due to 
stall media_player.js:24
2014-12-06 09:06:56.452onSeeking media_event_listener.js:118
2014-12-06 09:06:56.457 [354.192s] [cast.player.api.Player] seeking 
media_player.js:24
2014-12-06 09:06:56.864 [354.600s] [cast.player.api.Player] 1: time=39.1204 
media_player.js:24
2014-12-06 09:06:58.503 [356.238s] [cast.player.api.Player] seeking due to 
stall media_player.js:24
2014-12-06 09:06:58.514onSeeking media_event_listener.js:118
2014-12-06 09:06:58.521 [356.256s] [cast.player.api.Player] seeking 
media_player.js:24
2014-12-06 09:06:58.876 [356.760s] [cast.receiver.MediaManager] Buffering state 
changed, isPlayerBuffering: false old time: 39.1204 current time: 39.2204 
cast_receiver.js:18
2014-12-06 09:06:58.881 [356.766s] [cast.receiver.MediaManager] Sending 
broadcast status message 

... continue by 0.1 seconds

From #6, I expected MPL to jump straight over the gap in one seek action.

Original comment by willlunn...@gmail.com on 6 Dec 2014 at 9:16

[GoogleCodeExporter]

Interestingly, if I play the same video multiple times, the gap doesn't always 
appear at 36, somtimes it happens at 54, or 63.

Also if I go back to MPL 0.5 it does not report a gap in the source buffer and 
is able to play through the portion of the video that MPL 1.0 doesn't like.

Original comment by willlunn...@gmail.com on 6 Dec 2014 at 9:40

[GoogleCodeExporter]

Could you please provide a link to a test stream that we could use to 
investigate this?

Original comment by vadi...@google.com on 8 Dec 2014 at 6:08

[GoogleCodeExporter]

Hi,
I have been debugging these issues on Chromecast, but what I've seen in the 
logs during playback doesn't make sense and makes me suspect that the problem 
is with the data stream itself. Looks like there is actually a small gap 
between the end of the media segment that ends around 53.8 sec and the start of 
the new segment that starts at 53.9067.
I have also tried playing the URL from the first comment with VLC 2.1.4 on 
Linux and I can see some minor audio and video glitches during playback, and 
VLC shows the following warnings:
[h264 @ 0x7fe428c981e0] illegal short term buffer state detected
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 4) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 6) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 6) for PID 4096
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 3) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 13) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 13) for PID 4096
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 14) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 4) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 4) for PID 4096
[0x7fe4300009b8] main input error: ES_OUT_SET_(GROUP_)PCR  is called too late 
(pts_delay increased to 300 ms)
[0x7fe4300009b8] main input error: ES_OUT_RESET_PCR called
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS duplicate 
(received 0, expected 1) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 8) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 8) for PID 4096
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 3) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 13) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 13) for PID 4096
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS duplicate 
(received 0, expected 1) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 3) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 3) for PID 4096
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 6) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 13) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 13) for PID 4096
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 10) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS duplicate 
(received 0, expected 1) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS duplicate 
(received 0, expected 1) for PID 4096
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 13) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 2) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 2) for PID 4096
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 11) for PID 17
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 10) for PID 0
[0x7fe428c02668] ts demux error: libdvbpsi (PSI decoder): TS discontinuity 
(received 0, expected 10) for PID 4096

What software did you use to produce those videos (.ts streams)?

Original comment by serv...@google.com on 10 Dec 2014 at 2:48

[GoogleCodeExporter]

I'm using ffmpeg to take an existing H.264 stream inside an arbritry container 
and segment the video stream and if needed transcode the audio to the correct 
format. This is done on demand when the user selects a video from their 
collection.

Here is a fairly high bitrate sample 
https://www.dropbox.com/sh/hxr2kyxs64or6qi/AACmNoAB3hf-jOzIkVSUKEW1a, I'll try 
to generate some lower bitrate ones that also show the problem after work today.

Original comment by willlunn...@gmail.com on 10 Dec 2014 at 8:05

[GoogleCodeExporter]

RE #17. The reason the stream is creating gaps on Chromecast is that the stream 
bitrate is too high.  The size of the first three segments (at 10 seconds per 
segment) is

17,272,876
18,587,560
29,132,480

MPL tries to buffer 20 seconds.  The first two segments flood the source buffer 
resulting in data being ejected that hasn't been played yet, creating gaps as a 
result.

It looks like the effective bitrate for this stream is ~27 Mbps.  The 
recommendation is to not go over ~7 Mbps.

Original comment by vadi...@google.com on 10 Dec 2014 at 5:55

[GoogleCodeExporter]

Hi, the problems with the stream from #17 are caused by a known bug in Chrome:
https://code.google.com/p/chromium/issues/detail?id=421694
The problem is that SourceBufferStream implementation in Chrome uses a garbage 
collection algorithm that is overly aggressive and doesn't take playback 
position into account as required by MSE spec. This causes some unconsumed data 
to be dropped from the SourceBuffer prematurely and creates gaps and stalls 
during playback.
We are looking into ways to fix this.
But this is a completely separate issue from what we've seen in the stream 
described in comment #1, so I'd suggest opening a separate bug.

Original comment by serv...@google.com on 10 Dec 2014 at 6:05

[GoogleCodeExporter]

RE #17 - please note that even if the source buffer is fixed, your sample 
stream would generate an error rather than creating a gap, so it would still be 
unplayable on Chromecast.  You should look at limiting the bitrate for your 
streams.

Original comment by vadi...@google.com on 10 Dec 2014 at 6:08

[GoogleCodeExporter]

Hi,

OK thank you for the explination. I've just done some testing with streams of 
varying bitrates and so far the lower bitrate streams now playback without any 
problems under MPL 1.0 so it is now just streams with high bitrates that don't 
work.

Unfortunately the only way I can limit the bitrate for the streams my app will 
use is to force the videos to be re-encoded on the fly, but then users that run 
the server software on a low power NAS won't be able to cast. It also increases 
the video load time.

Is the bitrate limit any higher on Android TV devices such as the Nexus Player? 
I presume the current low limitation is based on how much memory can be 
dedicated for the source buffer. Is there any hope of rasing the supported 
bitrates in future versions on the current hardware?

One final point, please could you document the supported bitrates somewhere 
such as https://developers.google.com/cast/docs/media

Original comment by willlunn...@gmail.com on 10 Dec 2014 at 7:49

[GoogleCodeExporter]

Your sample stream will likely work on Android TV, please see

https://code.google.com/p/chromium/codesearch#search/&q=kSourceBufferVideoMemory
Limit&sq=package:chromium&type=cs

Original comment by vadi...@google.com on 11 Dec 2014 at 12:25