Skip to content

Commit 8a6a015

Browse files
ntrrgccalvaris
authored andcommitted
[MSE][GStreamer] Simplify handling of running time for non-resetting flushes
https://bugs.webkit.org/show_bug.cgi?id=263126 Reviewed by Philippe Normand. The computation of `base` and `start` for the GstSegment in webKitMediaSrcStreamFlush() is superfluous, as the same running time values can be obtained by preserving the original segment. * Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp: (webKitMediaSrcStreamFlush): Canonical link: https://commits.webkit.org/269358@main
1 parent 9ca878f commit 8a6a015

1 file changed

Lines changed: 2 additions & 23 deletions

File tree

Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp

Lines changed: 2 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -623,32 +623,11 @@ static void webKitMediaSrcStreamFlush(Stream* stream, bool isSeekingFlush)
623623
// The resulting segment is brand new, but with a different start time.
624624
WebKitMediaSrcPrivate* priv = stream->source->priv;
625625
DataMutexLocker streamingMembers { stream->streamingMembersDataMutex };
626-
streamingMembers->segment.base = 0;
627626
streamingMembers->segment.rate = priv->rate;
628627
streamingMembers->segment.start = streamingMembers->segment.time = priv->startTime;
629-
} else {
630-
// In the case of non-seeking flushes we don't reset the timeline, so instead we need to increase the `base` field
631-
// by however running time we're starting after the flush.
632-
633-
GstClockTime pipelineStreamTime;
634-
gst_element_query_position(findPipeline(GRefPtr<GstElement>(GST_ELEMENT(stream->source))).get(), GST_FORMAT_TIME,
635-
reinterpret_cast<gint64*>(&pipelineStreamTime));
636-
GST_DEBUG_OBJECT(stream->source, "pipelineStreamTime from position query: %" GST_TIME_FORMAT, GST_TIME_ARGS(pipelineStreamTime));
637-
// GST_CLOCK_TIME_NONE is returned when the pipeline is not yet pre-rolled (e.g. just after a seek). In this case
638-
// we don't need to adjust the segment though, as running time has not advanced.
639-
if (GST_CLOCK_TIME_IS_VALID(pipelineStreamTime)) {
640-
DataMutexLocker streamingMembers { stream->streamingMembersDataMutex };
641-
// We need to increase the base by the running time accumulated during the previous segment.
642-
643-
GstClockTime pipelineRunningTime = gst_segment_to_running_time(&streamingMembers->segment, GST_FORMAT_TIME, pipelineStreamTime);
644-
assert(GST_CLOCK_TIME_IS_VALID(pipelineRunningTime));
645-
GST_DEBUG_OBJECT(stream->source, "Resetting segment to current pipeline running time (%" GST_TIME_FORMAT") and stream time (%" GST_TIME_FORMAT ")",
646-
GST_TIME_ARGS(pipelineRunningTime), GST_TIME_ARGS(pipelineStreamTime));
647-
streamingMembers->segment.base = pipelineRunningTime;
648-
649-
streamingMembers->segment.start = streamingMembers->segment.time = static_cast<GstClockTime>(pipelineStreamTime);
650-
}
651628
}
629+
// In the case of non-seeking flushes we don't reset the timeline, so the buffers will
630+
// have the same running time as before and we don't need to alter the segment.
652631

653632
if (!skipFlush) {
654633
// By taking the stream lock we are waiting for the streaming thread task to stop if it hadn't yet.

0 commit comments

Comments
 (0)