GNOME Bugzilla – Bug 562312
Lip-sync generates wrong `ts-offset' in GstRtpBin
Last modified: 2008-11-26 12:04:06 UTC
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.
Created attachment 123406 [details] [review] patch for lip-sync bug
I'm not quite sure this fix is needed after the changes of late but I'll add a signal to gstrtpbin anyway to reset the lip-sync parameters. This signal should typically be performed by rtspsrc after a seek.
With these too patches if should be fixed given that rtspsrc clears the payload type map after each play request: * gst/rtpmanager/gstrtpbin.c: (get_client), (gst_rtp_bin_reset_sync), (gst_rtp_bin_associate), (gst_rtp_bin_handle_sync), (create_stream), (gst_rtp_bin_class_init), (new_ssrc_pad_found): * gst/rtpmanager/gstrtpbin.h: Remove a lot of per stream state that is not needed and pass new info in the method call. Add signal to reset sync parameters. Avoid parsing the caps to get a clock_base, we get this from the sync signal now. * gst/rtpmanager/gstrtpbin.c: (gst_rtp_bin_reset_sync), (gst_rtp_bin_clear_pt_map): Reset the sync parameters when clearing the payload type map too. Fixes #562312.