HLS playback fails after a few minutes.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use the following video tag in a web page to cast an Apple HLS stream to 
Chromecast using Android Chrome.
<video id="movie" 
src="http://185.62.88.18:1935/live/arte_15.stream/playlist.m3u8" preload 
controls autoplay width="640" height="360"></video>
2. Other streams that show similar behavior:
http://185.62.88.18:1935/live/daserste_15.stream/playlist.m3u8
http://185.62.88.18:1935/live/daserste_38.stream/playlist.m3u8
http://185.62.88.18:1935/live/arte_38.stream/playlist.m3u8

What is the expected output?
Continuous playback

What do you see instead?
Video plays for a while but eventually fails, usually after just a few minutes. 
 Before failure, some video glitches and brief stalls are also seen.  Not sure 
if these are encoding issues.

What version of the product are you using? On what operating system?
Chromacast Information:
Firmware Version: 38401
Country Code: US
MAC Address: 6C:AD:F8:7D:90:AF
IP Address: 10.0.2.68

Please provide any additional information below.
The streams are being generated by a Envivio encoder and segmented for HLS 
using Wowza Streaming Engine.
The same HLS streams play continuously in other players, although with the same 
video glitches and brief stalls.  But playback never dies completely in the 
other players.

Original issue reported on code.google.com by rcollins...@gmail.com on 28 Aug 2015 at 7:27

[GoogleCodeExporter]

Are you using Chrome Beta to cast from Android Chrome?

Original comment by jonathan...@google.com on 31 Aug 2015 at 9:02

• Changed state: NeedInfo

[GoogleCodeExporter]

No just Chrome from the Play store.  Looks like Chrome v44.0.2403.133
Is there still a Chrome Beta?  I don't see it in the Play Store anymore.

Original comment by rcollins...@gmail.com on 2 Sep 2015 at 7:37

[GoogleCodeExporter]

Actually it appears that Android Chrome just updated to v44.0.2403.133 on Sept 
1 (yesterday), so I must have been testing with the previous version.
I just retested and the problem persists, although it took 10 minutes for the 
playback to die.
Where you are originating the cast from shouldn't matter, right?  As I 
understand it, Android Chrome is just sending the video URL to the Chromecast 
and the Chromecast does everything else as far as the actual streaming/playback?

Original comment by rcollins...@gmail.com on 2 Sep 2015 at 7:55

[GoogleCodeExporter]

Casting is not fully supported on Android Chrome. In addition, Chromecast 
follows MSE specification so just because a stream works on other players, that 
doesn't necessarily mean it should work on Chromecast.

Original comment by jonathan...@google.com on 2 Sep 2015 at 9:13

• Changed state: Duplicate

[GoogleCodeExporter]

Fair enough, but it seems to me that if the video starts playing ok and can 
play continuously for a number of minutes but then just stops, there's a 
problem either in the player (or EME implementation or the Chromecast audio or 
video decoder) or in the source encoding of the media, not in the component 
that initiates the cast.  I was hoping that someone on the Chromecast side 
could tell me what specifically is causing the failure in playback of these 
streams.
I'm admittedly not familiar with the Chrome Sender API or what Android Chrome's 
involvement would be (as the initiator of the cast) once playback has begun.
Maybe an explanation of how this issue is a duplicate of issue 418 would clear 
that up?

Original comment by rcollins...@gmail.com on 9 Sep 2015 at 8:08

[GoogleCodeExporter]

It could be an issue with the stream's segments, but it's difficult to say 
since casting via Android Chrome (which is different from Desktop Chrome) isn't 
fully supported, so you shouldn't expect it to work 100%. The fix for Issue 418 
would enable you to cast via Android Chrome the same way as on Desktop, which I 
thought would bypass the issue you were getting.

Alternatively, you can try casting the same stream using an Android sender (via 
a native Android app) and using a Styled Receiver. If you still see the same 
issue, you can provide the stream(s) you used for testing and we can look into 
it.

Original comment by jonathan...@google.com on 10 Sep 2015 at 10:53

[GoogleCodeExporter]

Just to provide more feedback while rcollins...@gmail.com replies. We tried 
this from several senders and native apps, we have our own that has been 
working flawlessly in the past. We also tried with different stream providers 
sending their streams to the chromecast to test the sender and it worked 
without any issue (the streams played for hours without problem). But, when it 
comes to this particular streams that rcollins shows in the first comment:
http://185.62.88.18:1935/live/daserste_15.stream/playlist.m3u8
http://185.62.88.18:1935/live/daserste_38.stream/playlist.m3u8
http://185.62.88.18:1935/live/arte_38.stream/playlist.m3u8

Chromecast starts playing and randomly between 1-15 minutes the stream just 
stops. We were wondering if you can gain some insight in the chromecast player 
and maybe shed some light on what issue may be affecting the playback of those 
channels.

Original comment by david.co...@gmail.com on 11 Sep 2015 at 5:28

[GoogleCodeExporter]

Do you see this same issue on streams that aren't Envivio encoded?

Original comment by jonathan...@google.com on 11 Sep 2015 at 7:58

[GoogleCodeExporter]

We managed to reproduce it with streams from other providers like NoisyPeak, 
but since this is part of a customer deployment, the streams in production are 
all Envivio G5 based. 

Can you see anything in the streams that the Chromecast player is not liking? 

Original comment by david.co...@gmail.com on 11 Sep 2015 at 8:09

[GoogleCodeExporter]

We'll look into it and let you know.

Original comment by jonathan...@google.com on 11 Sep 2015 at 8:25

• Changed state: Acknowledged

[GoogleCodeExporter]

We managed to get a call with Envivio to discuss also the topic with them. This 
call will happen tomorrow 11:00 CEST. Could you give us any insight on the 
playback issues by then? Anything you could give us I'm sure it'll be helpful.

Original comment by david.co...@gmail.com on 15 Sep 2015 at 3:55

[GoogleCodeExporter]

You can tell Envivio that you're seeing an error in the Chromium logs that the 
stream may be missing timestamps in the middle of the stream and ask if they 
can suggest any workarounds.

Original comment by jonathan...@google.com on 16 Sep 2015 at 12:40

[GoogleCodeExporter]

Thanks for the feedback. As result of our meeting, Envivio would like to get 
logs in order to investigate further the issue. Would it be possible to you to 
attach here the logs with all detailed debug information about the streaming so 
they can debug?

Original comment by david.co...@gmail.com on 16 Sep 2015 at 9:29

[GoogleCodeExporter]

I've attached the logs you can give to Envivio. Both logs show the same error 
(mpeg2ts parsing error towards the end), but one is shorter. Let us know if 
Envivio needs anything else.

Original comment by jonathan...@google.com on 18 Sep 2015 at 10:35

Attachments:

• chromium-envivio-log1.zip
• chromium-envivio-log2.zip

[GoogleCodeExporter]

Issue 646 has been merged into this issue.

Original comment by jonathan...@google.com on 3 Oct 2015 at 12:10

[GoogleCodeExporter]

After testing these last 2 weeks and finally applying the change in production 
2 days ago we can consider the Chromecast issue solved with the change Envivio 
suggested on the encoder. 

They saw 2 "misconfigurations" on the streams:
- RAP signaling
- Video Frames not being aligned with the PES packets.

We performed a few tests moving different channels to IDR signaling, Aligning 
the video frames to the PES packets and some of them with both parameters and 
what seems to solve the issue is the video frames/PES packets alignment. 
However, as per their suggestion, we applied both parameters as the final 
configuration for the streams:
- IDR signaling
- Video frames aligned with the PES packets.

Thank you very much for your support on this issue. We consider this incident 
as solved.

Original comment by david.co...@gmail.com on 9 Oct 2015 at 5:03

[GoogleCodeExporter]

Glad to hear you were able to resolve the issue. Thanks for letting us know.

Original comment by jonathan...@google.com on 9 Oct 2015 at 10:49

[GoogleCodeExporter]

Original comment by jonathan...@google.com on 13 Oct 2015 at 9:43

• Changed state: Done