[gstreamer-bugs] [Bug 562312] New: Lip-sync generates wrong `ts-offset' in GstRtpBin

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=562312

  GStreamer | gst-plugins-bad | Ver: 0.10.20
           Summary: Lip-sync generates wrong `ts-offset' in GstRtpBin
           Product: GStreamer
           Version: 0.10.20
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: chao.zhang at access-company.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: 2.21/2.22
   GNOME milestone: Unspecified


I write a rtsp-player and I always found the audio or video freezes when I seek
the movie. This doesn't happen every time. After debugging, I found that the
reason is a GstBuffer comes after seeking has a BIG timestamp. This makes sink
waits until clock reaches this timestamp. And the reason for generating this
large timestamp is the Lip-sync codes in gstrtpbin.

So I analyse the source code of `gst_rtp_bin_associate'. This function do a lot
of things and finally generates a `ts-offset'. And this `ts-offset' depends on
`stream->unix_delta'. But I think this `unix_delta' should be reset when seek
occurs. During debugging, I found out that one stream's unix_delta has been
updated but another hasn't, in this situation, the `ts-offset' gets a BIG
value. For example, seek occurs, audio stream received new SR & SDES packet and
generates a new `unix_delta'. Then, audio stream checks the video stream's
unix_delta and generates the `ts-offset'. But maybe in this time, the
`unix_delta' of video stream hasn't been updated(still the value before seek),
so the wrong ts-offset is generated.

The `stream->unix_delta' depends on stream->last_extrtptime,
stream->clock_base, stream->clock_base_time and stream->last_unix. I think
these 4 variables should also be reset when seeking because they all may change
after seek.

So I created a patch which listens the events received in ghost pad of
`recv_rtp_sink' pad and if the event is GST_EVENT_FLUSH_STOP, I reset these
variables I mentioned above then forward the event to the target pad of this
ghost pad. Seems this patch works for me now.

My gst-plugins-bad version is 0.10.8. In gst-plugins-bad 0.10.9, I noticed in
gstrtpbin.c, there is a new `last_clock_base' member and seems some reset logic
has been involved. I am not clear whether these changes are for this problem,
If it is, I am sorry for submitting this resolved bug and just obsolete this
bug please.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=562312.