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

[bugzilla-daemon at bugzilla.gnome.org]

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.