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.
* 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.
* support setting transport to UDP
* breaking change: use new PacketContext rather than RtspMessageContext
in places where an RTP/RTCP packet is expected, as it can now be over
UDP instead of via RTSP interleaved data
* send teardown, which is important with UDP sessions. (It also will
help somewhat with Reolink TCP.) Along the way, make Session Unpin
so that teardown can consume it without tripping over tokio::pin!().
* refactor to shrink the amount of data used by Session and how much
gets memmoved around on the stack, instead of further growing it.
Because of missing RTCP RR and reorder buffer support, this is only
appropriate for using on a LAN. That's enough for me right now.
Fixes#17
I'm accumulating unit testing debt, but I think I'd rather get this
quickly out in the field to test against scenarios I haven't anticipated
than get my unit tests in order for scenarios I have anticiapted.
* stop using deprecated failure crate and its deps
* more uniformly detailed error messages
* an enum of the type of error, currently internal-only. I'm not
confident enough I understand what cases a caller might want to
distinguish, so I added a comment inviting input instead of
exposing it now.
* while I'm at it, separate connection context and message contexts.
This shrinks some of the data memmoved around in PacketItem and
CodecItem.
The new implementation has several benefits:
* it's more correct, in a way that probably doesn't matter now but
will if we ever send ONVIF backchannel audio. See the removed
comment about deadlock possibility. Similarly, I realized that if
packets became readable halfway through flushing a keepalive, the
keepalive future would be improperly dropped as described at
the beginning of this blog post:
https://carllerche.com/2021/06/17/six-ways-to-make-async-rust-easier/
* we'll be able to make other method calls on the Session while using
the stream, eg sending audio with ONVIF backchannel
* it's 8% faster according to the client benchmark.
* it doesn't pull in the async-stream dependency anymore.
* we can name the type of the stream, avoiding a Box in some cases.
* add a couple tests
* fix#4: put the whole video frame (including multiple NALs) into
a single Bytes. This is simpler to use and speeds up the
depacketize/h264_aac_writevideo benchmark. It's also a behavior
change; now I include non-VUI data such as SPS/PPS/SEI into the
data. I think this is a better default but it might be worth
making customizable.
* add variant which writes video to /dev/null
* (try?) to compile with debug symbols. (it seems to work but
cargo flamegraph still seems to complain?)
* faster parsing of inline data. I'd like to figure out why this is
slow with rtsp_types and fix it, but anyway in this benchmark I want
to just focus on the depacketization
