[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 31 10:37:40 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-31 13:37 -------
Hi Ali, sorry for the delay - wasn't checking home email over Easter.
This code:
this_samples = this_packet_len / 2 / rtpL16enc->channels;
/* if space_for_samples not right for a fixed number of samples, adjust! */
this_packet_len = 2 * rtpL16enc->channels * this_samples;
is to cater for a possible case where the (remaining) buffer size is not a
multiple of the channels*depth (or is it width?). In this case we should not use
the last few octets of the buffer.
The sample_rate, payload_type, and the number of
channels properties could be readonly - no need to be able to set them. rtpmap
is fundamental for handling dynamic payload types, which is everything except
rate=44100, one or two channels 16 bit.
I'm attaching my latest codebase - this has much improved timestamping and a
number of other improvements.
I've changed the "mtu" parameter to "bytesperbuffer" since mtu means the size of
the IP datagram, not the UDP payload. I still think its useful to have here,
especially for file sources, etc. This is also what the sync parameter is for,
to pace sending files.
I haven't done the other depths & widths yet, and the code is a bit dirty but at
least it works better than what's there at the moment.
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