andrey/retina
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4e52e7b19a
retina/CHANGELOG.md

52 lines
2.1 KiB
Markdown
Raw Normal View History

v0.2.0
2021-08-21 03:48:22 +04:00
## `v0.2.0` (2021-08-20)
workaround for Reolink spurious data 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.
2021-08-19 23:56:54 +04:00
* BREAKING CHANGE: `retina::client::Session::describe` now takes a new
`options: SessionOptions`. The `creds` has moved into the `options`, along
with some new options.
* BREAKING CHANGE: renamed `PlayPolicy` to `PlayOptions` for consistency.
* Added options to work around bugs found in Reolink cameras.
join control URLs with base in the "live555 way" 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.
2021-08-20 03:19:18 +04:00
* [#9](https://github.com/scottlamb/retina/issues/9). Improve compatibility
with how some cameras handle the `control` and `RTP-Info` urls. This
adopts a URL joining behavior which isn't RFC-compliant but seems to
be more compatible in practice.
workaround for Reolink spurious data 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.
2021-08-19 23:56:54 +04:00
remove rtcp dependency, prep v0.1.0 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.
2021-08-13 22:22:34 +04:00
## v0.1.0 (2021-08-13)
use SET_PARAMETERS for keepalive 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.
2021-07-12 06:45:52 +04:00
* use `SET_PARAMETERS` rather than `GET_PARAMETERS` for keepalives.
The latter doesn't work with GW Security GW4089IP cameras.
remove rtcp dependency, prep v0.1.0 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.
2021-08-13 22:22:34 +04:00
* removed `rtcp` dependency. Fixes
[#8](https://github.com/scottlamb/retina/issues/8). Avoids picking up
various transitive dependencies needed by later versions of the `rtcp`
crate, including `tokio`. (`retina`'s own `tokio` dependency will likely
become optional in a future version.)
use SET_PARAMETERS for keepalive 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.
2021-07-12 06:45:52 +04:00
prepare v0.0.5
2021-07-09 02:20:55 +04:00
## v0.0.5 (2021-07-08)
speed up interleaved data parsing This is a 20% improvement on the freshly-added benchmark.
2021-06-28 21:28:48 +04:00
shrink several large datastructures * 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 ```
2021-07-09 01:45:18 +04:00
* BREAKING CHANGE: New opaque error type with more uniform, richer error
messages. No more `failure` dependency.
* BREAKING CHANGE: `retina::client::Stream::parameters` now returns parameters
by value. This allows shrinking depacketizer types.
* BREAKING CHANGE: `retina::codec::VideoFrame::new_parameters` is now boxed.
This allows shrinking `VideoFrame` and `CodecItem` by 80 bytes each (on
64-bit platforms). The box is only rarely populated.
mp4 example: handle initial video param change 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.
2021-07-09 02:17:37 +04:00
* in `client mp4` example, handle an initial video parameter change correctly.
overhaul error type * 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.
2021-07-08 21:52:39 +04:00
don't break after keepalive response! 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.
2021-06-29 02:29:52 +04:00
## v0.0.4 (2021-06-28)
* bugfix: Retina stopped receiving packets after receiving a keepalive response.
prepare v0.0.3 release
2021-06-29 01:13:18 +04:00
## v0.0.3 (2021-06-28)
directly implement Stream on Session<Playing> 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.
2021-06-29 00:36:02 +04:00
* BREAKING CHANGE: `Session<Playing>` now directly implements `Stream` instead of
through `pkts()`.
speed up interleaved data parsing This is a 20% improvement on the freshly-added benchmark.
2021-06-28 21:28:48 +04:00
* Performance improvements.
prepare v0.0.2
2021-06-26 03:47:30 +04:00
## v0.0.2 (2021-06-25)
directly implement Stream on Session<Playing> 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.
2021-06-29 00:36:02 +04:00
* BREAKING CHANGE: Video frames are now provided as a single, contiguous `Bytes`, and
prepare v0.0.2
2021-06-26 03:47:30 +04:00
H.264 depacketization is more efficient ([#4](https://github.com/scottlamb/retina/issues/4)).
## v0.0.1 (2021-06-09)
use SET_PARAMETERS for keepalive 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.
2021-07-12 06:45:52 +04:00
Initial release.
Reference in New Issue Copy Permalink