Live HLS doesn't play live point with Infinity start time

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Prepare AES-128 Live HLS, with DVR window 0-90 minutes.
2. Cast #1 stream on Custom Receiver, with MediaPlayer.load(hlsProtocol, 
Infinity).
3. Video playing from beginning instead of the live point. Issue happens with 
70% chance.

What is the expected output? What do you see instead?
It should play the live point. However, sometimes it plays from the beginning.
Also I saw sometimes the console prints the log:
- [  2.785s] [cast.player.hls.Iterator] update: 454 not found media_player.js:24

What version of the product are you using? On what operating system?
MediaPlayer 1.0.0
Receiver 2.0.0

Please provide any additional information below.

Original issue reported on code.google.com by vincent...@neulion.com on 27 Dec 2014 at 4:27

Attachments:

• receiver_live_infinity_beginning.txt

[GoogleCodeExporter]

Could you please provide a sample stream so that we can investigate the issue.

Original comment by na...@google.com on 29 Dec 2014 at 11:59

• Changed state: NeedInfo

[GoogleCodeExporter]

I cannot give the account credential here. I will turn on the debug logger and 
attach the log here to see if the log would help.

cast.receiver.logger.setLevelValue(cast.receiver.LoggerLevel.DEBUG);
cast.player.api.setLoggerLevel(cast.player.api.LoggerLevel.DEBUG);

Original comment by nicevinc...@gmail.com on 30 Dec 2014 at 10:09

[GoogleCodeExporter]

Attached 2 games console log from Chromecast device with setting 
LoggerLevel.DEBUG.

The 'ts' file pattern is simple: ${game_name}_${bitrate}_${YYYYMMDDHHMMSS}.

In each log, search keyword 'not found'. You can see that after 'not found', 
the media player requesting the ts from beginning.

Take log1.txt as example, the 'not found' is in Line 153.
And you can see all the ts file requests before Line 153 are 20141231xxxxxx. 
However after Line 153, the ts file requests became 20141230xxxxxx.

I couldn't find out the pattern how to exactly reproduce it. Sometimes it 
happened at the very beginning when the stream starts... 

(See log2.txt happens late if you search 'not found'...)

Original comment by nicevinc...@gmail.com on 31 Dec 2014 at 2:29

Attachments:

• log1.txt
• log2.txt

[GoogleCodeExporter]

This happens if the sequence number of the current segment (i.e. the segment on 
which MPL is working to append to the source buffer) is not found in the 
reloaded playlist.  MPL then resets to the beginning of the reloaded playlist.

Original comment by vadi...@google.com on 2 Jan 2015 at 9:51

[GoogleCodeExporter]

Is MPL too aggressive to download the segment? What's the suggested workaround 
to avoid this issue?

Original comment by nicevinc...@gmail.com on 2 Jan 2015 at 9:54

[GoogleCodeExporter]

Any updates?

Original comment by nicevinc...@gmail.com on 5 Jan 2015 at 3:07

[GoogleCodeExporter]

You would need to ensure sequence number consistency when playlists are 
updating.  Are sequence numbers consistent across stream renditions for all 
bitrates?  If the sequence numbers are not in sync it would lead to this 
problem.

Original comment by vadi...@google.com on 5 Jan 2015 at 5:10

[GoogleCodeExporter]

Thanks for updating. Is it possible that MPL handle this problem?

The reason I am asking, is because we are hosting the media files on CDN. 
However, we can't control multiple m3u8 consistency across birate. Seem more 
likely CDN issue but hard to resolve. 

Original comment by nicevinc...@gmail.com on 5 Jan 2015 at 5:21

[GoogleCodeExporter]

If sequence number consistency is indeed the problem, it's a known issue in 
MPL.  However, other developers using MPL for live HLS, have been able to 
ensure sequence number consistency across playlists.

MPL could use #EXT-X-PROGRAM-DATE-TIME when looking for the next segment to 
play after switching playlists due to a bitrate change, but it currently 
doesn't - instead looking for the sequence number in the new playlist.  If it 
doesn't find it, it resets to the first segment in the new playlist.

So, yes - it's a known issue, and it could be handled by MPL.

Original comment by vadi...@google.com on 5 Jan 2015 at 7:01

[GoogleCodeExporter]

This problem happened on m3u8 with DVR window.

The pure live m3u8 doesn't problem, because even it has problem, the pure live 
m3u8 normally has 6 segments, when it seek back to the beginning, the end user 
won't notice too much...

Also I notice that the MPL download and play the latest segment when stream 
starts.

https://tools.ietf.org/html/draft-pantos-http-live-streaming-14#section-6.3.2
==================
6.3.2.  Loading the Media Playlist file
   A client MUST NOT assume that segments with the same Media Sequence
   Number in different Variant Streams or Renditions have the same
   position in the presentation; Playlists MAY have independent Media
   Sequence Numbers.  Instead, a client MUST use the relative position
   of each segment on the Playlist timeline and its Discontinuity
   Sequence Number to locate corresponding segments.

https://tools.ietf.org/html/draft-pantos-http-live-streaming-14#section-6.3.3
==================
6.3.3.  Playing the Media Playlist file
   The client SHALL choose which Media Segment to play first from the
   Media Playlist when playback starts.  If the EXT-X-ENDLIST tag is not
   present and the client intends to play the media normally, the client
   SHOULD NOT choose a segment which starts less than three target
   durations from the end of the Playlist file.  Doing so can trigger
   playback stalls.

Original comment by nicevinc...@gmail.com on 5 Jan 2015 at 7:41

[GoogleCodeExporter]

For a live playlist, when Infinity is passed in, MPL starts three target 
segment durations from the end of the playlist.  If that's not what you 
observe, please provide a repro stream that can be used for investigation.

Original comment by vadi...@google.com on 5 Jan 2015 at 7:56

[GoogleCodeExporter]

I wrote a php Live m3u8 media server simulator hosted on Google App Engine.

Test Live m3u8 DVR:
- http://dulcet-cable-817.appspot.com/main.m3u8

Receiver:
1. Clone from Cast Github
 - https://github.com/googlecast/cast-custom-receiver/blob/master/sample_media_receiver.html
2. Replace Line 
    window.mediaPlayer.load(protocol, initialTimeIndexSeconds);
   with
    window.mediaPlayer.load(protocol, Infinity);
3. Change MPL to 1.0.0
4. The Custom Receiver is put on
 - http://dulcet-cable-817.appspot.com/nba/sample_media_receiver.html

Use your sender to load the test stream, connect to the 9222 debugger, I 
guarantee you will see the result similar with my screenshot.

Original comment by nicevinc...@gmail.com on 6 Jan 2015 at 6:03

Attachments:

• [Screen Shot 2015-01-06 at 12.49.58 AM.png](https://storage.googleapis.com/google-code-attachments/google-cast-sdk/issue-467/comment-12/Screen Shot 2015-01-06 at 12.49.58 AM.png)

[GoogleCodeExporter]

Thank you for providing the repro!  You're right - it incorrectly seeks to the 
last segment due to a regression in MPL.  We'll fix this when MPL is next 
updated.

Original comment by vadi...@google.com on 6 Jan 2015 at 7:19

[GoogleCodeExporter]

Thank you for the following up.

Original comment by nicevinc...@gmail.com on 6 Jan 2015 at 7:20

[GoogleCodeExporter]

Original comment by na...@google.com on 7 Jan 2015 at 12:01

• Changed state: Acknowledged

[GoogleCodeExporter]

Any update on this issue? Even we are exactly facing the same issue..

Original comment by roop....@gmail.com on 29 Jan 2015 at 10:38

[GoogleCodeExporter]

The fix will be available as soon as the Cast SDK is next updated.

Original comment by vadi...@google.com on 29 Jan 2015 at 5:12

[GoogleCodeExporter]

Could you please validate against the latest deployed media player library?

Original comment by vadi...@google.com on 4 Feb 2015 at 4:58

[GoogleCodeExporter]

I did a quick test, and the release/patch is good.

Original comment by nicevinc...@gmail.com on 4 Feb 2015 at 5:23

[GoogleCodeExporter]

Original comment by na...@google.com on 4 Feb 2015 at 6:19

• Changed state: Fixed