Support different #EXT-X-PROGRAM-DATE-TIME tags for different #EXT-X-DISCONTINUITY sections
See original GitHub issueProblem
There is a chance that HLS content provider may produce discontinuities in stream. For example, because the server was restarted. In this case, according to the standard (https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-08#section-4.4.4.3), there must be #EXT-X-DISCONTINUITY tag in manifest. As far as I can understand, exoplayer will try to correct the position using the PTS. In general, PTS is not the best source of truth for this because after #EXT-X-DISCONTINUITY tag there may be any timestamp (even descending). But even if the PTS monotonously increased during, for example, a server reboot, there is another problem: seeking. Assume, that we have VOD HLS manifest:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-START:TIME-OFFSET=0
#EXT-X-TARGETDURATION:10
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-PROGRAM-DATE-TIME:2020-12-02T18:33:03.447Z
#EXTINF:7.920,
2020-12-02/18/segment_1.ts
#EXT-X-PROGRAM-DATE-TIME:2020-12-02T18:33:10.887Z
#EXTINF:9.080,
2020-12-02/18/segment_2.ts
#EXT-X-DISCONTINUITY
#EXT-X-PROGRAM-DATE-TIME:2020-12-02T19:33:20.567Z
#EXTINF:9.040,
2020-12-02/18/segment_3.ts
#EXT-X-PROGRAM-DATE-TIME:2020-12-02T19:33:29.607Z
#EXTINF:9.720,
2020-12-02/18/segment_4.ts
#EXT-X-ENDLIST
If we play sequentially, without seeking, then the player, based on the PTS, will jump the gap (that is, getCurrentPosition
will return the time one hour later). But if we seek after the gap, then the player will not know anything about the gap and will return the time that we specified in seekTo
.
Summation: discontinuities in stream in conjunction with seeking lead to incorrect position.
Proposed solution
Take #EXT-X-PROGRAM-DATE-TIME after #EXT-X-DISCONTINUITY into account if present (especially after seeking).
There is a recommendation in standard: https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-08#section-6.2.1
The server MAY associate an absolute date and time with a Media
Segment by applying an EXT-X-PROGRAM-DATE-TIME tag to it. This
defines an informative mapping of the (wall-clock) date and time
specified by the tag to the first media timestamp in the segment,
which may be used as a basis for seeking, for display, or for other
purposes. If a server provides this mapping, it SHOULD apply an EXT-X-PROGRAM-DATE-TIME
tag to every segment that has an EXT-X-DISCONTINUITY tag applied to it.
And also:
The Server MUST NOT add any EXT-X-PROGRAM-DATE-TIME tag to a Playlist
that would cause the mapping between program date and Media Segment to become ambiguous.
So it is server-side responsibility to provide correct EXT-X-PROGRAM-DATE-TIME values.
An exemplary algorithm for how this can work
If, during sequential playback, we have reached EXT-X-DISCONTINUITY tag and the next segment starts with EXT-X-PROGRAM-DATE-TIME then correct player’s position and duration. Moreover, it is possible to correct duration earlier, when this tags appear in manifest.
During seek, player should set position considering previous EXT-X-DISCONTINUITY, EXT-X-PROGRAM-DATE-TIME tags. For live playlists player can remember these tags and correct position based on them
ExoPlayer version: 2.12.1
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (6 by maintainers)
Top GitHub Comments
I don’t think that’s a good idea because it will confuse window/playlist position and duration with wall clock position/duration based on EXT-X-PROGRAM-DATE-TIME. I suggest:
currentPosition
consistent whether we have reached it with or without seek and allow an application to mapcurrentPosition
to playlist item and relative position inside this item.currentPosition
to/from wall clock time based on EXT-X-PROGRAM-DATE-TIME tags. It should probably be left to the application to decide how to map wall clock time to window time because of potential gaps in wall clock time.Over to @christosts who’s now maintaining HLS.