Make `RtpPacketBuilder` generic over payload type and allow custom serialization about rtp-types HOT 7 CLOSED

What if, we had a stateful builder for a list of packets (returned through an iterator) that kept track of at least the sequence number and allowed editing each packet's other header values (marker, csrc, timestamp, extension data, etc) while generating a payload with a FnMut. That would allow the reading side to (dynamically) put as many bytes as it wants into the rtp payload.

On the generating side, a trait to write into whatever the user provided would probably be best here.

Maybe something like: https://gist.github.com/ystreet/ad93b54c02885583385e86f2ea6889eb

from rtp-types.

Having Boxes in there seems like a bad idea because of the additional heap allocations.

For writing, this doesn't allow e.g. to append a gst::Memory as payload and then when writing it out creating a gst::Buffer that contains the header in a new gst::Memory and the payload just refs the original gst::Memory another time.

from rtp-types.

The idea is to use the same RtpPacketListBuilder for multiple packets. e.g. a complete video frame. If you are only generating a single packet, then the existing approach is fine already.

Can certainly add a separate push_payload function and associated generics on the RtpWriter trait for the separate header and payload concern.

from rtp-types.

I'll later have to read your suggestion more carefully then, I think I didn't understand it :)

from rtp-types.

Updated gist has a version with a RtpWriter::push_payload() with a generic lifetime that seems to work.

from rtp-types.

I don't need any fancy gst::Buffer or gst::Memory stuff at this point btw, I just want to be able to generate/writeout N bytes into place directly with a closure or whatever without first writing it all into an intermediary buffer and then having the builder copy it over. (e.g. to swizzle some bytes during payloading)

from rtp-types.

Custom extension/payload data and modifying payload data on the fly should be reasonably possible now with #10.

More specific use-cases can be discussed in new issues.

from rtp-types.