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
* by default send a TEARDOWN even if we haven't sent a PLAY.
* make the behavior more customizable. I want the ability to turn
teardowns off for testing the live555 bug.
* deprecate the older teardown method
* avoid half-written output (fixes#32)
* try to send TEARDOWN even on error while reading the stream.
This isn't perfect as noted in the TODO. I think I'll want to
change the API a bit, but not right now.
This was an attempt at #17 that didn't work out. Besides additionally
hitting the framing error, my Reolink test camera never timed out
the old session while the new one was in progress. This behavior is
different than the vanilla 2013.04.06 live555 server, so apparently
Reolink sprinkled in their own brokenness on top. In any case,
the other solutions described in that bug are more likely to work.
There's one narrow case I want to keep working: ignoring RTCP messages
immediately prior to the PLAY response. More recent Reolink cameras
do this. I just have this behavior on all the time now.
* 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.
```
thread 'main' panicked at 'range start index 1 out of range for slice of length 0', examples/client/mp4.rs:171:44
stack backtrace:
0: rust_begin_unwind
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:515:5
1: core::panicking::panic_fmt
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/panicking.rs:92:14
2: core::slice::index::slice_start_index_len_fail
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/slice/index.rs:34:5
3: client::mp4::TrakTracker::write_common_stbl_parts
4: client::mp4::Mp4Writer<W>::write_audio_trak
5: client::mp4::run::{{closure}}
6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
7: tokio::park:🧵:CachedParkThread::block_on
8: tokio::runtime::thread_pool::ThreadPool::block_on
9: tokio::runtime::Runtime::block_on
10: client::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```
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.
rtcp recently had an accidental semver break, so this fixes#8.
I also don't like that newer versions depend on several unnecessary
crates including tokio. retina also depends on tokio, but in the future
I want it to be IO library-agnostic.
I'm moving to v0.1.0 so I *can* release versions that claim semver
compatibility. There are still plenty of API changes to make but also
likely upcoming camera compatibility changes that won't break anything.
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.
* 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.
* 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.
