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.