After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 511683 - gstrtpbin fails to associate streams together for lipsync
gstrtpbin fails to associate streams together for lipsync
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 0.10.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-01-24 00:46 UTC by Olivier Crête
Modified: 2008-01-27 21:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to get the clockrate from the request-pt-map signal (3.53 KB, patch)
2008-01-24 00:46 UTC, Olivier Crête
committed Details | Review

Description Olivier Crête 2008-01-24 00:46:16 UTC
GstRtpBin will not associate streams together for lip-sync unless they have the clock-rate set. The only way their clock-rate can be set it from the pad that comes out of the ssrc demux, but this pad never has caps on it (the caps are just set on the buffer later in the pt demuxer!). So the association never happens.

I'm attaching a patch that uses the ptdemuxer's payload-type-changed signal to signal what is the last pt that was received on that stream, this PT is then used to request the pt-map and then get the clock-rate.
Comment 1 Olivier Crête 2008-01-24 00:46:53 UTC
Created attachment 103589 [details] [review]
patch to get the clockrate from the request-pt-map signal
Comment 2 Wim Taymans 2008-01-25 17:01:21 UTC
        Patch by: Olivier Crete <tester@tester.ca>

        * gst/rtpmanager/gstrtpbin.c: (gst_rtp_bin_associate),
        (create_stream), (payload_type_change), (new_ssrc_pad_found):
        Also handle lip-sync when the clock-rate is not provided with caps but
        with a signal.
Comment 3 Olivier Crête 2008-01-27 21:50:48 UTC
I'd like to point out, that after applying this patch, I have issues with the TS jumping forward about 300,000 seconds after a few seconds (but I haven't had time to investigate yet).