After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731982 - hlsdemux: Don't use approximate duration for fragment buffer pts
hlsdemux: Don't use approximate duration for fragment buffer pts
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-06-20 18:42 UTC by GstBlub
Modified: 2015-01-08 13:11 UTC
See Also:
GNOME target: ---
GNOME version: ---

Example playlist (1.92 KB, text/plain)
2014-06-20 18:45 UTC, GstBlub
Patch (3.18 KB, patch)
2014-06-20 18:46 UTC, GstBlub
needs-work Details | Review
Updated patch (2.87 KB, patch)
2014-06-23 15:13 UTC, GstBlub
needs-work Details | Review

Description GstBlub 2014-06-20 18:42:54 UTC
The HLS demuxer currently uses the duration supplied by the playlist file and uses this information to set the PTS of the first buffer of each fragment.  These values are approximate only, and even worse on playlist versions 1 and 2 these are only rounded integer values (in seconds).  The result is that there are continuously playback skips between the fragments.  The duration information is only really helpful for seeking purposes.
Comment 1 GstBlub 2014-06-20 18:45:06 UTC
Created attachment 278860 [details]
Example playlist

This is an example.  Each fragment is roughly 10 seconds (rounded integer value in #EXTINF), but if you look at #EXT-X-PROGRAM-DATE-TIME tags you can see that the actual duration of the fragments is slightly different.
Comment 2 GstBlub 2014-06-20 18:46:24 UTC
Created attachment 278861 [details] [review]

Patch to fix this issue:  Only set the very first buffer's PTS, do not set it for the first buffer of every subsequent fragment.
Comment 3 GstBlub 2014-06-20 19:08:34 UTC
This is probably the same as bug #731824
Comment 4 GstBlub 2014-06-20 19:13:23 UTC
Also seems to be a duplicate of bug #724983
Comment 5 Sebastian Dröge (slomo) 2014-06-22 12:17:07 UTC
I guess that's the best we can do here, and not try to be too clever. Thanks for the patch.
Comment 6 Sebastian Dröge (slomo) 2014-06-22 12:21:01 UTC
Comment on attachment 278861 [details] [review]

This will break seeking though. After a seek we're supposed to send a buffer downstream with a new timestamp (corresponding to the beginning of the buffer, not the seek position) again.
Comment 7 GstBlub 2014-06-23 14:20:22 UTC
(In reply to comment #6)
> (From update of attachment 278861 [details] [review])
> This will break seeking though. After a seek we're supposed to send a buffer
> downstream with a new timestamp (corresponding to the beginning of the buffer,
> not the seek position) again.

Hm, do you have any idea how this could be fixed?
Comment 8 Sebastian Dröge (slomo) 2014-06-23 14:26:23 UTC
HLS is just an ill-defined format :)

I think for seeking we should use the approximation that was used before, and that is still used in the seek handler to find the corresponding fragment.
Comment 9 GstBlub 2014-06-23 15:13:20 UTC
Created attachment 279042 [details] [review]
Updated patch

This patch unconditionally sets demux->reset_pts to TRUE when processing a seek event.
Comment 10 Sebastian Dröge (slomo) 2014-06-23 17:26:34 UTC
Comment on attachment 279042 [details] [review]
Updated patch

This breaks playback of

After the first fragment it will switch from the default playlist to the 4th for me... that's at 10 seconds. But it will immediately jump from 10 seconds to 20 seconds.
Comment 11 Thiago Sousa Santos 2014-08-19 20:37:34 UTC
Any update?
Comment 12 GstBlub 2014-08-22 19:11:16 UTC
I would really appreciate some help with this.  I don't seem to have the jumping issue, but at the same time I don't think mine is switching from the default playlist?  Sebastian, is this still happening, or is this that may have been fixed in the meanwhile?
Comment 13 Thiago Sousa Santos 2014-12-24 13:54:06 UTC
*** Bug 740461 has been marked as a duplicate of this bug. ***
Comment 14 Thiago Sousa Santos 2015-01-07 14:54:22 UTC
Patch updated to the latest codebase and fixed the issue with resyncing when changing the playlist.

commit cd6069f5af03b35fd0182ac9dfac3b4c0eccbe4d
Author: Thomas Bluemel <>
Date:   Fri Jun 20 12:38:59 2014 -0600

    hlsdemux: Don't use approximate duration for fragment buffer pts
    The duration values in playlists are approximate only, and for
    playlist versions 2 and older they are only rounded integer values.
    They cannot be used to timestamp buffers.  This resulted in playback
    gaps and skips because the actual duration of fragments is slightly
    different.  The solution is to only set the pts of the very first
    buffer processed, not for each fragment.
Comment 15 Sebastian Dröge (slomo) 2015-01-08 12:18:15 UTC
Thiago, how does this work with seeking though? If we can't use the durations to timestamp buffers then we also can't use them for seeking for the same reason
Comment 16 Thiago Sousa Santos 2015-01-08 12:22:38 UTC
We still keep track of the timestamps of the segments but we only provide a timestamp when it is the first segment pushed after a seek, when starting or when we switch bitrates.

For seeking it uses rough approximation that the playlist provides. So seeking should be just like before but we get more accurate timestamps during playback and we only resync with the playlist's timestamps when needed.
Comment 17 Sebastian Dröge (slomo) 2015-01-08 12:26:35 UTC
That would mean that seeking near the current playback position could take you somewhere completely different though :)
Comment 18 Thiago Sousa Santos 2015-01-08 13:04:58 UTC
There's not much that can be done regarding that in HLS. I assumed continuous/smooth playback was more important than seeking accuracy. One other option would be to always push a new segment with every fragment to resync timestamps with HLS without disrupting playback, but that would likely mean that the position would jump a bit every segment.

I'm hoping people will move to newer HLS specs that allow using floats to express time related values instead of integers, so this will likely be easier for us.
Comment 19 Sebastian Dröge (slomo) 2015-01-08 13:11:35 UTC
Yes, smooth playback is more important. I was just curious if you found a better solution :)