[gst-devel] BUG: no default clock-rate in rtph263[p](pay|depay)

[Wim Taymans]

On Tue, 2007-01-16 at 15:52 +0100, Antoine Pitrou wrote:
> Hi,
> 
> There is a small bug in rtph263pay, rtph263ppay and rtph263pdepay (and
> possibly other RTP elements). In those elements, the RTP clock-rate is
> only initialised when one sets the sink pad caps (this can be seen in
> gst_basertppayload_setcaps and gst_base_rtp_depayload_setcaps).
> 
> This means that when one doesn't explicitly set the sink pad caps, the
> pipeline refuses to play and an error is printed because the internal
> clock-rate value of the RTP element is 0.
> 
> Since the H263 clock-rate is, AFAIK, always 90000, it should be the
> default value at element initialisation.
> 
> I've experienced the bug with gst-plugins-good 0.10.4, but looking at
> the source it hasn't been fixed in 0.10.5.

The real problem is that no caps negotiation is happening. A plugin is
free to refuse any buffers when they have no type information. If you
are using UDP to feed the payloaders, set the "caps" property on udpsrc
with the info from the SDP (or similar). See also:
http://webcvs.freedesktop.org/gstreamer/gst-plugins-good/gst/rtp/README?revision=1.9&view=markup
in the "usage with UDP" section.

Wim
> 
> Regards
> 
> Antoine.
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-- 
Wim Taymans <wim at fluendo.com>