Incorrect seeking behaviour for live events with no type

[fougere-mike]

Live playlists which do not provide a playlist type (#EXT-X-PLAYLIST-TYPE) are being interpreted as TYPE_VOD. This has the effect of preventing seeks when the playlist is a live event (with no type).

[fougere-mike]

I have fixed this in my fork, and opened a pull request: #21

[martinbonnin]

I'm afraid this will break this part of the spec:

If the EXT-X-ENDLIST tag is not
present and the client intends to play the media regularly (i.e.  in
playlist order at the nominal playback rate), the client SHOULD NOT
choose a segment which starts less than three target durations from
the end of the Playlist file.

What needs to be done is decorrelate the firstRememberedMediaSequence from the first played sequence. I'll try to do something for this.

[martinbonnin]

and actually, the playlist as of now are not interpreted as TYPE_VOD but just as TYPE_UNKOWN which is also valid. What the type information says is :

• VOD => playlist should never change
• EVENT => playlist should only be appended to
• UNKNOWN => playlist can be both appended to and removed from

[martinbonnin]

Still thinking about this... Can't you just add a method like HLSSampleSource.setForcedPlaylistType(int type) and call this from your application code ? I'm not a fan of changing the behaviour for all live playlists that don't specify the playlist type as this will significantly slowdown the startup time (we need to fetch the first segment to get the timestamp from it then switch back to the 'live' segment to avoid stalling if the player falls a bit behind the server).

[martinbonnin]

I just added setForcedPlaylistType, please tell me if this is acceptable to you.

[fougere-mike]

Does this solution require my application code to download and parse the playlist in order to setup the SampleSource? I may be wrong about this, but shouldn't it be possible to determine the type of playlist by checking:

1. Whether an ENDLIST tag exists.
2. Current value of MEDIA-SEQUENCE?

In my case, events will always have a MEDIA-SEQUENCE of 1 and have an ENDLIST tag appended once complete. Would this require my application code to listen for the addition of the ENDLIST tag and set the playlist type to VOD?

According to the HLS spec the PLAYLIST-TYPE tag is not required, so I don't think it's appropriate to offload this responsibility to the application code if its not included.

[martinbonnin]

you don't need to download the playlist in the application code, you can just call HLSSampleSource.setForcedPlaylistType(VariantPlaylist.TYPE_EVENT) and it will force the behaviour you want.

[fougere-mike]

Oh my mistake -- I had assumed that HLSSampleSource.setForcePlaylistType() would force the playlist type, and override the detected type. I didn't realise it was just specifying a fallback in case of TYPE_UNKNOWN.

I still don't think the application code should have to know anything about how HLS works, or what type of playlist is being used; but this should work for my case.

Cheers!

[martinbonnin]

yea, you're right, the name is a bit misleading, I'll rename that to setFallbackPlaylistType() [edit: done].

I agree it would be nicer to not have anything in application code but thing is if type is unknown then it is unspecified whether we should start from the first or the last segment. Testing MEDIA-SEQUENCE==1 is not engough to assume VOD as I have seen VOD playlists with MEDIA-SEQUENCE > 1...

[fougere-mike]

Understood -- although it should be possible. When I test our streams on iOS devices, the type is correctly detected, and I do not have to make any special configuration changes. I'm not sure how they're doing it though.

[martinbonnin]

yeaaa, Apple is magic ;-)

[martinbonnin]

Or maybe they just unconditionally download the first segment before doing anything else, in which case we should start much faster :-)