This is the method recommended by the ONVIF Streaming Specification
version 21.06 section 5.2.2.2.
I was using GET_PARAMETERS. This matched ffmpeg's behavior if the
OPTIONS shows that GET_PARAMETERS is supported, although I wasn't doing
the initial OPTIONS request.
Apparently the GW Security GW4089IP will simply ignore GET_PARAMETERS,
not even sending a 405 Method Not Allowed response. It supports and
responds to SET_PARAMETERS.
I've noticed some (buggy) cameras' out-of-band parameters don't quite
match the initial in-band parameters. Out-of-band parameters aren't
required anyway, and this is progress toward handling in-band only.
* Box the remaining Depacketizer variants. I already boxed the largest
ones, which are also the most common. Might as well box the others
and not have so much dead space in the common case...
* Don't keep around a full codec::Parameters on all codecs. This
shrinks several depacketizers. I also avoid some awkward
destructuring.
* Box VideoFrame::new_parameters, which is populated rarely.
```
sizes changes on 64-bit platforms:
type before after
client::Stream 512 312
codec::Depacketizer 224 16
codec::aac::Depacketizer 232 208
codec::g723::Depacketizer 200 104
codec::h264::Depacketizer 560 552
codec::onvif::Depacketizer 216 128
codec::simple_audio::Depacketizer 208 112
codec::CodecItem 240 160
codec::VideoFrame 232 152
codec::AudioFrame 104 104
codec::MessageFrame 104 104
client::rtp::SenderReport 72 72
```
* 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.
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!
