[Bug 698050] tsdemux: seeking doesn't even work in pull mode

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=698050
  GStreamer | gst-plugins-bad | git

--- Comment #10 from Josep Torra Valles <n770galaxy at gmail.com> 2013-05-23 07:56:19 UTC ---
(In reply to comment #4)
> Yes, I talked with him about that the other day on IRC, apparently it had to do
> with timeshifting:
> 
> 
> #gstreamer 23-04-2013 12:50:01
> 
>    tim: AD-N770, do you remember what the rationale was for
> http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=150376efe476f4b9ea6c6cef54af1399cf6f478e
> ?
>    tim: AD-N770, flushing observations doesn't exactly help with seeking, if
> I'm not mistaken
>  josep: I don't remember now, was something related with tsdemux and the leak
> on _dispose
>  slomo: AD-N770: so only a leak, no functional reason?
>  josep: I've the feeling that was also a functional reason but I can't remember
> now
>  josep: I mean that the feeling I've is that the leak on dispose was found as a
> side effect 
>  josep: but I can't remember the exact reason for it was needed
>  josep: __tim: as for the context of the moment I've commited it I think that
> was somehow related to on the use case that the time seek is handled upstream
> like in my timeshift element or hlsdemux
>    tim: AD-N770, and I remember you fixed that nasty crash where it cleaned up
> stuff in FLUSH_START instead of STOP, but I didn't see how those commits were
> related to that
>  josep: well at that time I was trying to make the timeshift element work with
> tsdemux in 1.0
>  josep: that triggered the raising of multiple issues
>  josep: my gut feeling is that having previous observations after seek when it
> was handled upstream caused something nasty with the timestamps or the segment
>  josep: well dvbsrc is the exception
>  josep: ah, yes it's live
>  josep: but I think that demuxer always create de segment
>    tim: AD-N770, even if upstream is TIME?
>  josep: you should ask bilboed, but I think that is recreated in demuxer always
>    tim: hrm, maybe it creates a new one based on the input values then, which
> would be ok
>    tim: anyway, I now know what to look out for if I poke at it, thanks

I think that the reason was that when the seek in time was handled by the
upstream element a wrong offset was applied on the produced timestamps due
previous observations causing the the pts not being related anymore on the
upstream provided segment event.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.