```
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.
