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.
* export a `Session::tool` to allow callers to see the server's
version. Servers have many quirks (including but not limited to
the live555 version bug), and exposing this can help hunt them down.
* call out when we see the live555 stale session bug with a tool not
known to be affected.
* in several log messages, identify the session group and stale
session seqnum.
* add a `log::trace!` for status within
`SessionGroup::await_stale_sessions`, just in case I get really
puzzled again.
Found by inspection. It'd be nice to fuzz the tokio module to more
reliably find problems like this, but it looks like I'd have to make
a bunch more stuff public for that. Maybe later...
This .unwrap() call would panic on e.g. an empty string, which
it would get from 'fmtp:96 ' (empty parameters).
This is for example produced by v4l2-rtspserver when it
fails to extract SPS/PPS from the first (?) packet:
d0da079177/src/H264_V4l2DeviceSource.cpp (L52)
