We're likely to add more examples with more dependencies (e.g. ffmpeg,
gstreamer, webrtc). Nice to not have their deps in the main crate's
dev-dependencies, and likewise to have each example show its true
dependencies.
As mentioned here:
https://github.com/scottlamb/retina/issues/19#issuecomment-902302720
Part of #47
The main benefit is that `VideoFrame::into_data` can cheaply return a
`Vec<u8>` that the caller can mutate. In particular, they could convert
H.264 data from Annex B to AVC form or skip non-VCL NALs. Neither of
these transformations add bytes so they're both possible without
allocation.
Audio and message frames still use `Bytes` internally, as that allows
them to avoid copying when the frame is wholly contained in a packet.
I think this is much more common than for video. I didn't add an
`AudioFrame::into_data` or `VideoFrame::into_data`.
* and take advantage of it to use `Box<str>` rather than `String`
in a couple places (saving a couple words)
* also rename clock_rate to clock_rate_hz for clarity
As described in #47 and #58: revamp this type to keep the full raw
packet, and provide accessors rather than raw fields. It's also
smaller now, which is nice.
As listed in #47.
This improves throughput in the client/h264 benchmark by about 20%,
I think because we copy fewer bytes around. CodecItem went from 256
bytes to 176.
This was accidentally looking at the bottom bit of the V=2 field, so
it effectively never subtracted padding from the payload.
This bug didn't have any effect...yet. We currently only support
parsing the sender report. RFC 3550 says that SRs are sent
in "compound packets" that start with the SR and have at least one
other entry (a CNAME). Only the last packet within the compound packet
can have padding, so it's never come up in SR parsing. Fix this bug now
before we start parsing more things and run into trouble.
