[gstreamer-bugs] [Bug 169391] [rtpL16enc/parse] don't work (patch attached)

bugzilla-daemon at bugzilla.gnome.org bugzilla-daemon at bugzilla.gnome.org
Thu Mar 24 03:47:49 PST 2005


Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=169391
 GStreamer | gst-plugins | Ver: 0.8.7





------- Additional Comments From Julian Cable  2005-03-24 06:47 -------
Hi Ali - I'm still working on this code - I can send you a snapshot but I'll
wait a bit if that's OK. As far as mtu is concerned there are a number of
options, but JUST having it in the udpsink element won't work. Basically udpsink
MUST NOT fragment RTP packets. The problem is RTP doesn't have a length field,
it relies on UDP framing, so if UDP fragments then the receiver sees one short
RTP packet and another unidentifiable packet with no RTP header.

Note that tcp and udp unicast can use path mtu discovery so it doesn't really
need a parameter but udp multicast probably needs the parameter, and its the rtp
element that needs to know it.

One solution is for the rtp encoder to query the udpsink for mtu.

The solution I'm using is to decide a priori what the number of samples should
be and set it upstream in the pipeline. This is best for live streaming since it
keeps the packet encode latency known.

BTW - I'll propably make the plugin rtpLxx and handle 8/16/20/24 bit (20 is the
only hard one). Also, should the rtp elements be bigendian only (rtp is always
bigendian) or should they support endian swaps internally?

Julian

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.




More information about the Gstreamer-bugs mailing list