[Bug 635701] rtspsrc: seeking is broken

[GStreamer (GNOME Bugzilla)]

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.