Support EXT-X-DISCONTINUITY without EXT-X-DISCONTINUITY-SEQUENCE (for live HLS with version<6)

[xenDev]

Video playback freezes with this sample stream.
http://52.203.119.217:8180/cdn/linear/espn-new/index.m3u8

The exact error I see is "com.google.android.exoplayer.demo E/AudioTrack: Discontinuity detected [expected 24035133, got 9012800]" coinciding with the freeze.

We are simply looping through five segments with a #EXT-X-DISCONTINUITY tag. It's unclear to me if EXT-X-DISCONTINUITY-SEQUENCE is a MUST if there are no variants as per the HLS draft#19.

FWIW, this same stream plays fine on Apple devices (Safari/Quicktime, iOS, etc.). May be Apple is more lenient with discontinuities.

[ojw28]

The HLS specification is very clear that you must include EXT-X-DISCONTINUITY-SEQUENCE in this case. Specifically:

If the server wishes to remove segments from a Media Playlist containing an EXT-X-DISCONTINUITY tag, the Media Playlist MUST contain an EXT-X-DISCONTINUITY-SEQUENCE tag.

And:

If the server removes an EXT-X-DISCONTINUITY tag from the Media Playlist, it MUST increment the value of the EXT-X-DISCONTINUITY-SEQUENCE tag so that the Discontinuity Sequence Numbers of the segments still in the Media Playlist remain unchanged.

And:

Clients can malfunction if each Media Segment does not have a consistent Discontinuity Sequence Number.

The fact that EXT-X-DISCONTINUITY-SEQUENCE is pitched in the HLS spec as being useful to the client where there are multiple variants/renditions doesn't mean you can ignore MUST clauses in the specification in the single variant case. Adding EXT-X-DISCONTINUITY-SEQUENCE to be spec compliant will resolve the issue you're seeing.

[xenDev]

Thanks for the details but do you know why iOS devices have no issue playing the same stream. Does Exoplayer expect the HLS stream to be a certain version compliant while the iOS players are able to support older rev? I don't know which draft introduced EXT-X-DISCONTINUITY-SEQUENCE.

[ojw28]

EXT-X-DISCONTINUITY was added to the spec quite a long time before EXT-X-DISCONTINUITY-SEQUENCE. It's likely that the iOS player doesn't rely on EXT-X-DISCONTINUITY-SEQUENCE as much as ExoPlayer does as a result. It's unclear to me whether or not the spec was under-specified (to the extent that the player had to "guess what to do" in some cases) prior to the addition of EXT-X-DISCONTINUITY-SEQUENCE, but I suspect this is likely to be the case.

EXT-X-DISCONTINUITY-SEQUENCE has been in the spec for around 3 years now. Given it's relevant to live streams (only), it's not like there's a huge volume of legacy content that omits the tag. It seems reasonable for us to require that live stream providers aren't more than 3 years behind the spec.

[hancockks]

The manifest in question uses EXT-X-VERSION:3. According to the EXT-X-VERSION:
3.4.17. EXT-X-VERSION

The EXT-X-VERSION tag indicates the compatibility version of the
Playlist file. The Playlist file, its associated media, and its
server MUST comply with all provisions of the most-recent version of
this document describing the protocol version indicated by the tag
value.

The most recent spec documenting protocol version 3 is https://tools.ietf.org/html/draft-pantos-http-live-streaming-06 which does not contain EXT-X-DISCONTINUITY-SEQUENCE. It would be improper for the client that implements compatibility with VERSION 3 to require tags that are not part of the version 3 specification.

[ojw28]

Yep. So I think you can consider ExoPlayer as not supporting live streams prior to version 6 in the specific case that they include EXT-X-DISCONTINUITY tags. As per above, it seems reasonable that live stream providers shouldn't be using a spec that's 3 years old.

ExoPlayer will successfully play on-demand streams and live streams that do not include EXT-X-DISCONTINUITY tags that are prior to version 6.

We could proactively detect the unsupported case and fail with a clearer warning, if you feel that would be worthwhile.

[hancockks]

It does seem reasonable to proactively fail unsupported formats and/or versions.

[theBradfo]

FWIW it seems like it's just the video renderers that have issues with this older HLS spec. We play an audio-only stream (http://espn.edge-1.cis.abacast.net/espn-network-cloud.m3u8?source=espnradio) using hls v3, see EXT-X-DISCONTINUITY tags without corresponding EXT-X-DISCONTINUITY-SEQUENCE tags and playback works as expected.

So perhaps we don't always want to proactively fail playback in all cases?

[meenapola]

1. In my experience so far, some of the live stream providers are still supporting protocol version 3,
   e.g., UFC and AOL. We see EXT-X-DISCONTINUITY without EXT-X-DISCONTINUITY-SEQUENCE tag, a lot

2. Interestingly, y'day I encountered EXT-X-DISCONTINUITY @ the beginning of a growing live playlist.
   exoplayer(2.0.4) was able to playback the content without a hiccup.
   #EXTM3U
   #EXT-X-VERSION:3
   #EXT-X-TARGETDURATION:7
   #EXT-X-MEDIA-SEQUENCE:1418
   #EXT-X-PLAYLIST-TYPE:EVENT
   #EXT-X-DISCONTINUITY
   #EXTINF:0.033,
   20161108T165357/index-500/00000/index-500_01418.ts
   #EXTINF:6.006,
   20161108T165357/index-500/00000/index-500_01419.ts
   #EXTINF:6.006,
   20161108T165357/index-500/00000/index-500_01420.ts
   ...
   ...

[ojw28]

We now plan to provide best-effort support for EXT-X-DISCONTINUITY without EXT-X-DISCONTINUITY-SEQUENCE. We'll likely do this sometime in Jan.

[ojw28]

The latest dev-v2 branch should handle this issue properly in most circumstances. There may still be issues if there are discontinuities very close together and if high latency is experienced refreshing the HLS playlists.