[Bug 635701] rtspsrc: seeking is broken
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Thu Mar 26 05:19:51 PDT 2015
https://bugzilla.gnome.org/show_bug.cgi?id=635701
--- Comment #14 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Sebastian Dröge (slomo) from comment #11)
> Review of attachment 300315 [details] [review]:
>
> Seems correct.
>
> For the PAUSED case this probably also behaves different depending on
> whether the clock continues running in paused (system clock) or stays at the
> same position (most audio clocks). What are exactly the symptoms with
> PAUSED, what running times do we output and what would be expected at this
> point (clock_time - base_time)?
When we go in pause, seek, and then in playing, the jitterbuffer does not
output anything anymore. I suspect a bug in the fact that seeking in this case
is handle using a slightly different code path in rtspsrc. My intestention
today was to check that, and maybe make sure we have a single path. When going
to pause before seeking, part of the perform_seek() code is skipped, and is
then executed within the streaming thread loop. I was wondering if in fact
everything should be done in the streaming thread. I believe doing blocking
network operation in the seeker thread isn't ideal.
>
> ::: gst-libs/gst/rtp/gstrtpbasedepayload.c
> @@ +588,2 @@
> segment.time = priv->npt_start;
> + segment.position = 0;
>
> Shouldn't position be pts? Not that this value matters much anyway ;)
I was not sure, so I left it as it was before. Is is the position from start,
in which case it should be segment.start, hence PTS, or the position as an
offset from start ?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list