[Bug 787621] adaptivedemux: Pre-rolling problem after seeks on HLS streams

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=787621

--- Comment #4 from luckychou <luckychsj at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #3)
> Your analysis sounds plausible, and this seems to be completely unrelated to
> GstPlayer indeed.
> 
Yes,just used to write the test code using Gstplayer.

> It might be related to how adaptivedemux is doing things though, so let's
> move it there for now.

gstadaptivedemux.c gst_adaptive_demux_prepare_streams()'s code annotation,
seems to have dealt with this situation?
-----------------
 /* The demuxer segment is just built from seek events, but for each stream
     * we have to adjust segments according to the current period and the
     * stream specific presentation time offset.
     *
     * For each period, buffer timestamps start again from 0. Additionally the
     * buffer timestamps are shifted by the stream specific presentation time
     * offset, so the first buffer timestamp of a period is 0 + presentation
     * time offset. If the stream contains timestamps itself, this is also
     * supposed to be the presentation time stored inside the stream.
     *
     * The stream time over periods is supposed to be continuous, that is the
     * buffer timestamp 0 + presentation time offset should map to the start
     * time of the current period.
     *
     *
     * The adjustment of the stream segments as such works the following.
     *
     * If the demuxer segment start is bigger than the period start, this
     * means that we have to drop some media at the beginning of the current
     * period, e.g. because a seek into the middle of the period has
     * happened. The amount of media to drop is the difference between the
     * period start and the demuxer segment start, and as each period starts
     * again from 0, this difference is going to be the actual stream's
     * segment start. As all timestamps of the stream are shifted by the
     * presentation time offset, we will also have to move the segment start
     * by that offset.
     *
     * Likewise, the demuxer segment stop value is adjusted in the same
     * fashion.
     *
     * Now the running time and stream time at the stream's segment start has
     * to be the one that is stored inside the demuxer's segment, which means
     * that segment.base and segment.time have to be copied over (done just
     * above)
-----------------

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.