* 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.
* out-of-order packets should be ignored (except for logging).
* after ignored RTP or RTCP packet, don't incorrectly return Pending
without both underlying sockets actually returning Pending. This
could lead to not rechecking the sockets until prompted for another
reason, like an RTSP keepalive.
This didn't work; I wasn't able to get working audio from them.
I'm not sure they even actually have a microphone! They may just
be sending uninitialized/stale buffer contents on this channel.
Just don't use the audio channel with this camera.
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.
* make handle_keepalive_timer, handle_response, and handle_data proper
methods. (pin-project is still confusing for me, but I think I'm
starting to get the hang of it.)
* swap a couple fields between Session and RtspConnection to improve
clarity for #30
This isn't RFC-compliant, but it seems to be quite common, and it
works with some cameras where the RFC-compliant way does not.
Fixes#9
Based on lucaszanella's PR #12, including his vstarcam test.
```
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.
