prepare v0.0.4 immediately; v0.0.3 is effectively unusable.
I want to test this properly, but I haven't yet figured out how to set
up good mocks of tokio::Sleep and such. For now just fix the bug.
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
These are huge, not present for every stream, and only allocated once at
describe time, so boxing makes sense. I probably should listen to that
clippy lint!
