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.
* Call `note_stale_live555_data` when this happens in playing state.
This makes it more consistent with what happens while waiting for
a response in the described state, or in playing state on an
assigned channel.
* Print a hex dump of some initial bytes, enough to analyze it to
see if it looks like RTP or RTCP, what the ssrc is, etc. And do the
same for other places we log (parts of) packets.
