GNOME Bugzilla – Bug 565509
rtpsource on receiver side can't get clock-rate for h264, h263 or mpeg4
Last modified: 2008-12-29 14:22:03 UTC
Please describe the problem: normally, it is not necessary to specify payload type on the receiver side's udpsrc caps for an rtp session. However, for h264, h263 and mpeg4 video streams, if you don't specify payload-type, you get the following warning: rtpsource rtpsource.c:865:calculate_jitter: cannot get clock-rate for pt 96 Steps to reproduce: Setup a stream such as the one described here: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-gstrtpbin.html using either h264, h263 or mpeg4, and set GST_DEBUG level to two Actual results: rtpsource rtpsource.c:865:calculate_jitter: cannot get clock-rate for pt 96 Expected results: The payload type would not need to be specified and we would not get this warning. Does this happen every time? Yes. Other information: I have not observed this behaviour for any audio codec/payloader/depayloader combinations.
Created attachment 125232 [details] Testcase for h264 run two instances of this program, one with r as an argument, one with s as an argument.
It's because the payload type is not included in the caps. I'm going to change it so that if there is no payload type on the caps but there is a clock-rate, the first payload type received in the RTP packets will receive the clock-rate.
* gst/rtpmanager/rtpsource.c: (rtp_source_init), (rtp_source_update_caps), (get_clock_rate): * gst/rtpmanager/rtpsource.h: When no payload was specified on the caps but there was a clock-rate, assume the clock-rate corresponds to the first payload type found in the RTP packets. Fixes #565509.