mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-19 14:56:36 +00:00
oggdemux: Drop data before new segment
When calculating duration in push-mode we seek to a certain position and discard any data until we get data from that requested position. The problem is that basing ourselves solely on offset to determine whether we reached the target offset is wrong since the source might be fast enough to send us that target position *before* it processed the requested seek. This would end up in a situation where: * We think we're done with duration estimate * We fire a seek back to "0" in the loop thread * We resume normal processing * ... except that we're still getting data from too far ahead which we decide to process. * And we start doing totally wrong granule/time/duration calculation and pushing wrong data. Instead of this confusion, wait until we receive data from the requested seek. We do that by using the fact that the seqnum in seek_event_drop_til will be non-zero until the SEGMENT corresponding to the requested SEEK has been received. Bonus: makes startup slightly faster
This commit is contained in:
parent
0a49b93ade
commit
c86df789ed
1 changed files with 6 additions and 0 deletions
|
@ -1687,6 +1687,12 @@ gst_ogg_pad_handle_push_mode_state (GstOggPad * pad, ogg_page * page)
|
|||
ogg->push_time_length = t;
|
||||
}
|
||||
|
||||
/* If we're still receiving data from before the seek segment, drop it */
|
||||
if (ogg->seek_event_drop_till != 0) {
|
||||
GST_PUSH_UNLOCK (ogg);
|
||||
return GST_FLOW_SKIP_PUSH;
|
||||
}
|
||||
|
||||
/* If we were determining the duration of the stream, we're now done,
|
||||
and can get back to sending the original event we delayed.
|
||||
We stop a bit before the end of the stream, as if we get a EOS
|
||||
|
|
Loading…
Reference in a new issue