Most HLS streams generated by VLC fail to play

[GoogleCodeExporter]

What steps will reproduce the problem?
1.attempt to stream any of the streams from the archive below

What is the expected output? What do you see instead?

expected - stream plays

Actual - player drops back to splashscreen, or sticks with the loading bar

What version of the product are you using? On what operating system?

chromecast build 19084
ios sdk 2.4
playing either to my styled player (app id: 39097C94) or to the default app id

Please provide any additional information below.

all of these streams play ok on iOS and Android.
all of these streams pass validation with Apple's mediastream validator tool 
(though most of them have a warning about not having a keyframe in segment 01

dumping the first segment from these streams (removing it from the playlist) 
does allow most of these files to play.

the error in the debug console is 'Load metadata error cast_receiver.js:18'

you can get the streams here:
https://drive.google.com/file/d/0ByQXlcPccBwuV0hTVTRXb3RfUU0/edit?usp=sharing

Original issue reported on code.google.com by rob.jon...@gmail.com on 28 Sep 2014 at 2:58

[GoogleCodeExporter]

Original comment by lnicho...@google.com on 28 Sep 2014 at 3:03

• Changed state: Acknowledged

[GoogleCodeExporter]

Hi Rob,
I'm a developer on the Chromecast media team, I've seen your discussion with 
Ali and Leon at https://plus.sandbox.google.com/+RobJonson/posts/ewfSP2h3ofB
And I agree you have some good points. Chromecast should never crash/hang even 
on streams that are not fully standard compliant. If you see hangs/crashes, 
please report them, we'll investigate those as highest priority issues. As for 
the other cases, we'll try to make our best effort to play stream that are not 
completely standard compliant, but in some cases Chrome's MSE implementation 
constraints might limit what we can do.
Thanks for providing the sample streams, I'll take a look and will update this 
bug with my findings.

Original comment by serv...@google.com on 29 Sep 2014 at 6:40

[GoogleCodeExporter]

Thanks for looking. Let me know if I can help.
You won't be seeing any more discussion from me on the G+ group. 
I'm not sure if it was my comments about HLS, or my suggestion that RTFM was an 
unhelpful response ( http://bit.ly/1wVFvDN ) - but one of the two got me banned 
from the group.

Original comment by rob.jon...@gmail.com on 30 Sep 2014 at 10:17

[GoogleCodeExporter]

Quick update: I've tried playing all your streams and in all cases except 
stream N, I got one of two issues, which look like they have the same root 
cause.
1. Streams 1, 6, E, Z failed because we couldn't figure out a timestamp for the 
first audio buffer. Unfortunately it currently causes Chromecast shell process 
to exit.
2. All the other streams, again except N, failed to play because we read a PES 
in mpeg2 ts that doesn't have a PTS.
In case of stream N we started playing video, but there was no audio, it looks 
like it's a separate issue, I'll investigate that later. For now let's focus on 
the two issues above, affecting most of the streams.
I'm not the original author of mpeg2 ts parser in Chrome, but I spoke to him 
and he told me that Apple HLS spec recommends that each PES in the mpeg2 ts 
stream has a PTS info. Looks like we are not the only ones affected by this 
(for example here's an issue that sounds very similar: 
https://github.com/denivip/osmf-hls-plugin/issues/93). And, by the way, it 
looks like even VLC (I've tried latest VLC 2.1.5 64-bit on Windows) has some 
issues when playing the streams you gave us. For all the streams seeking to the 
positions close to the end of stream doesn't work. When the playback naturally 
progresses to the end of stream, there's often a frozen video frame and audio 
issues, audio restarts from the beginning for a few seconds. And there are 
audio issues during normal playback in streams 8 and C.
We'll still try to do our best to play such streams correctly, since we don't 
know how many of these are out there in the wild. But we need to decide on the 
best course of action. We'll need to get timing info from somewhere. I've 
noticed that there are some SEI NALUs in H264 video stream, for example and 
these might contain timing info. But Chrome H264 parser currently doesn't know 
how to extract timing info from SEI NALUs. And for audio streams, we'll also 
have to either get the timing info from somewhere, or drop a few first audio 
frames until we get a PES with timing info (seems like that's what VLC is 
doing).

Original comment by serv...@google.com on 30 Sep 2014 at 11:17

[GoogleCodeExporter]

thanks for digging in to these. 

Most of this goes over my head I'm afraid - but certainly, dumping problematic 
frames until you can get something useful sounds like a sensible approach.

I'll pass this info back to one of the VLC devs who has done a lot of work on 
the HLS output. I expect it will be very helpful.

re audio issues in 8 and C;
C comes from an mkv a sample which has tortured VLC for a long time. VLC used 
to fail completely to convert it, and it is quite likely that there is just a 
corruption in the original source.
8 comes from the official mkv test samples, and deliberately has an audio gap - 
so no surprise that the HLS output has an audio gap too.
(I'd be happy to share my originals on these, but I suspect they're not 
helpful).

Original comment by rob.jon...@gmail.com on 1 Oct 2014 at 12:25

[GoogleCodeExporter]

Another quick update on this.
We have made some fixes in Chrome upstream mpeg2ts parser and now we are able 
to play successfully 12 streams out of 20 (on Chromecast build 20965).
The remaining issues:
1. Streams 7, 8, I and K used to fail right at the start. Now we start playback 
successfully, but after a few seconds the playback stalls due to gaps in the 
input streams. (Btw, VLC also has some issues with these. In stream 7 VLC loses 
audio, but continues playing video. In stream 8 VLC has audio and video glitch, 
but is able to recover and continue playback with both audio and video).

2. For streams C, M, O and T mpeg2ts stream parsing still fails, I'm 
investigating further.

Original comment by serv...@google.com on 9 Oct 2014 at 11:12

[GoogleCodeExporter]

excellent sounds like great progress.

fwiw - thee all play without issue on iOS 8 (my main streaming destination) - 
though it is only with recent versions of VLC that this has been the case.
Some comments:
7 - (there is an audio discontinuity as per the original file)
8 - plays (almost) completely cleanly
I - this isn't one that has been problematic historically.
K - this is one where VLC used to struggle with the audio conversion
C -this one has been problematic historically
M - this is audio only. Could that be the problem?
T - this clearly a messed up snippet

re; VLC, 2.2 RC1 plays all of these fine.
{http://nightlies.videolan.org/ latest nightly on the 2.2 branch)

I'm not sure how much you want to go digging in their code, but it might be 
informative to see how the HLS module has changed, or which contribs have been 
updated.

Original comment by rob.jon...@gmail.com on 10 Oct 2014 at 11:44

[GoogleCodeExporter]

Have there been any further updates on this issue (now that it is a couple 
months later)? 

I am trying to play audio only HLS streams, a use case that seems like it is 
another example of the "M" stream described in the previous comment.

Here is an example url that fails when tried against the sender/receiver app 
available on github:
https://s3-us-west-1.amazonaws.com/hls-audio/example.m3u8

That same url works correctly in Safari and through the use of the 
osmf-hls-plugin in Adobe Flash in Chrome or Firefox.

Original comment by arshiak...@gmail.com on 10 Dec 2014 at 9:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm also having problems playing hls live streams at all using the latest 
firmware (22062).

Previously when I tested hls streams on chromecast using the previous firmware 
I was at least able to play them. 

Back then we had two problems which at least were not blocking issues:
1) if the stream contained dvr/timeshift feature the chromecast player started 
playing the content from the beginning of the stream, not from the live moment. 
And seeking wasn't working jumping to the live moment was not possible.

2) If the stream contained multiple bitrate streams the playback ended in an 
error after couple of seconds. 

Now with the latest firmware using test streams:
single bitrate: 
http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1CTV_1@196725/master.m3u8
multi bitrate: 
http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/master.m3u8

Chromecast test receiver: https://github.com/googlecast/Cast-Player-Sample or 
https://github.com/googlecast/CastMediaPlayerStreamingDRM

The debug output is as follows:
[ 44.868s] [cast.player.api.Player] Version: 1.0.0.5 media_player.js:24
 [ 44.895s] [cast.player.api.Player] load  media_player.js:24
 [ 45.080s] [goog.net.XhrIo] Opening Xhr [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/master.m3u8 -1] media_player.js:24
 [ 45.110s] [goog.net.XhrIo] Will abort after 30000ms if incomplete, xhr2 false [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/master.m3u8 -1] media_player.js:24
 [ 45.118s] [goog.net.XhrIo] Sending request [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/master.m3u8 -1] media_player.js:24
 [ 45.967s] [goog.net.XhrIo] Request complete [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/master.m3u8 200] media_player.js:24
 [ 46.085s] [cast.player.hls.Parser] filtered out mp4a.40.2 stream media_player.js:24
 [ 46.092s] [cast.player.hls.Parser] filtered out mp4a.40.2 stream media_player.js:24
 [ 46.220s] [cast.player.core.QualityManager] 0: from undefined to 1128000 media_player.js:24
 [ 46.230s] [cast.player.hls.Playlist] update: http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_3_av-p.m3u8?sd=10&rebase=on media_player.js:24
 [ 46.260s] [goog.net.XhrIo] Opening Xhr [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_3_av-p.m3u8?sd=10&rebase=on -1] media_player.js:24
 [ 46.278s] [goog.net.XhrIo] Will abort after 30000ms if incomplete, xhr2 false [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_3_av-p.m3u8?sd=10&rebase=on -1] media_player.js:24
 [ 46.293s] [goog.net.XhrIo] Sending request [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_3_av-p.m3u8?sd=10&rebase=on -1] media_player.js:24
 [ 46.459s] [goog.net.XhrIo] Request complete [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_3_av-p.m3u8?sd=10&rebase=on 200] media_player.js:24
 [ 47.415s] [cast.player.core.SegmentManager] 0: seek success 0 media_player.js:24
 [ 47.427s] [goog.net.XhrIo] Opening Xhr [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/segment141416195_3_av-p.ts?sd=10&rebase=on -1] media_player.js:24
 [ 47.436s] [goog.net.XhrIo] Will abort after 20000ms if incomplete, xhr2 false [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/segment141416195_3_av-p.ts?sd=10&rebase=on -1] media_player.js:24
 [ 47.442s] [goog.net.XhrIo] Sending request [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/segment141416195_3_av-p.ts?sd=10&rebase=on -1] media_player.js:24
 [ 48.738s] [goog.net.XhrIo] Request complete [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/segment141416195_3_av-p.ts?sd=10&rebase=on 200] media_player.js:24
 [ 48.766s] [cast.player.core.QualityManager] 0: current=8979204.77, average=7602794.21 media_player.js:24
 [ 48.773s] [cast.player.core.SegmentManager] 0: process segment media_player.js:24
 [ 48.782s] [cast.player.hls.Adaptation] process segment media_player.js:24
 [ 49.196s] [cast.player.hls.Adaptation] start: 67818.8304222222 media_player.js:24
 [ 49.201s] [cast.player.core.SegmentManager] 0: segment processed media_player.js:24
 [ 49.207s] [cast.player.core.SourceBufferManager] 0: abort media_player.js:24
 [ 49.213s] [cast.player.core.SourceBufferManager] 0: timestampOffset = -67818.8304222222 media_player.js:24
 [ 49.218s] [cast.player.core.SourceBufferManager] 0: append media_player.js:24
 [ 49.230s] [cast.player.core.QualityManager] 0: from 1128000 to 3128000 media_player.js:24
 [ 49.236s] [cast.player.hls.Playlist] update: http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_1_av-p.m3u8?sd=10&rebase=on media_player.js:24
 [ 49.240s] [goog.net.XhrIo] Opening Xhr [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_1_av-p.m3u8?sd=10&rebase=on -1] media_player.js:24
 [ 49.245s] [goog.net.XhrIo] Will abort after 30000ms if incomplete, xhr2 false [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_1_av-p.m3u8?sd=10&rebase=on -1] media_player.js:24
 [ 49.250s] [goog.net.XhrIo] Sending request [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_1_av-p.m3u8?sd=10&rebase=on -1] media_player.js:24
 [ 49.417s] [goog.net.XhrIo] Request complete [GET http://iltasanomat_live-lh.akamaihd.net/i/ISTVLive1_1@196725/index_1_av-p.m3u8?sd=10&rebase=on 200] media_player.js:24
Uncaught InvalidStateError: Failed to set the 'duration' property on 
'MediaSource': The MediaSource's readyState is not 'open'. media_player.js:221
 [ 50.463s] [cast.receiver.MediaManager] Load metadata error cast_receiver.js:18
 [ 50.323s] [cast.player.api.Player] error media_player.js:24
 [ 50.327s] [cast.player.api.Host] error 1 media_player.js:24
 [ 50.332s] [cast.player.api.Player] unload  media_player.js:24
 [ 50.514s] [cast.receiver.MediaManager] Load metadata error cast_receiver.js:18
 [ 51.369s] [cast.receiver.MediaManager] Not sending LOAD error as there is no on going LOAD request 

Load metadata error also happens using this test stream: 
http://solutions.brightcove.com/jwhisenant/hls/brightcove/fishtank/16x9-fishtank
-master.m3u8

Original comment by tim...@reaktor.fi on 17 Dec 2014 at 11:28

[GoogleCodeExporter]

We are having serious problems with chromecast mpegts demuxer. Below are links 
to 2 (as far as I can tell perfectly valid) mpeg ts files, which play using 
every player out there except for chromecast.

https://s3.amazonaws.com/MatejK/Samples/Chromecast/seg0.ts
https://s3.amazonaws.com/MatejK/Samples/Chromecast/fileSequence0.apple__new.ts

Error message from logs:

  [  3.277s] [cast.player.core.SourceBufferManager] 0: abort
media_player.js:20  [  3.280s] [cast.player.core.SourceBufferManager] 0: 
timestampOffset = -599.958288888889
media_player.js:20  [  3.281s] [cast.player.core.SourceBufferManager] 0: append
cast_receiver.js:13  [  3.518s] [cast.receiver.MediaManager] Load metadata error
media_player.js:20  [  3.353s] [cast.player.api.Player] errormedia_player.js:20 
Ab
media_player.js:20  [  3.355s] [cast.player.api.Host] error 1media_player.js:20 
Ab
media_player.js:20  [  3.358s] [cast.player.api.Player] unload 

Can someone please shed some light into this? We have 100% control over the 
muxer and can change pretty much anything, but I need to know what exactly is 
breaking the demuxer. This is really frustrating.

Original comment by matej.kn...@gmail.com on 19 Feb 2015 at 12:46