Commit d1c5669a authored by Sebastian Dröge's avatar Sebastian Dröge 🍵

adaptivedemux: Properly implement timestamping of multi-period streams

Each period will start again with pts 0 + period presentation offset, which is
also going to be the presentation time inside the container stream if any.
However all periods together should form a continuous timeline, with regard to
stream time and running time.

For making this possible we keep track of the "user requested segment", i.e.
the seek events, inside the demuxer without adjusting anything and taking this
demuxer segment only as orientation for modified segments per stream.

This per stream segments will have their segment.start at pts that would be
produced for this stream in this period, and the segment.base/time adjusted so
that this pts maps to the running and stream time this period should have in
the context of all other periods.

https://bugzilla.gnome.org/show_bug.cgi?id=754222
parent b5697b8c
......@@ -408,6 +408,19 @@ struct _GstAdaptiveDemuxClass
* @stream.
*/
GstClockTime (*get_presentation_offset) (GstAdaptiveDemux *demux, GstAdaptiveDemuxStream *stream);
/**
* get_period_start_time:
* @demux: #GstAdaptiveDemux
*
* Gets the start time of the current period. Timestamps are resetting to 0
* after each period but we have to maintain a continuous stream and running
* time so need to know the start time of the current period.
*
* Return: a #GstClockTime representing the start time of the currently
* selected period.
*/
GstClockTime (*get_period_start_time) (GstAdaptiveDemux *demux);
};
GType gst_adaptive_demux_get_type (void);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment