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

98 lines
4.0 KiB
Markdown
Raw Normal View History

prepare v0.3.5
2021-12-01 00:37:03 +04:00
## `v0.3.5` (2021-11-30)
H.264: don't require valid out-of-band params It's allowed for a server to send only in-band parameters, although I haven't encountered this yet. The VStarcam cameras sometimes send invalid out-of-band parameters; treat that as if it sent nothing. Fixes #42
2021-11-30 21:34:13 +04:00
* [#42](https://github.com/scottlamb/retina/issues/42): support servers that
don't send out-of-band H.264 parameters or send invalid parameters; wait for
in-band parameters in this case. The in-band parameters must be valid.
documentation improvements
2021-11-30 23:35:53 +04:00
* documentation improvements.
H.264: don't require valid out-of-band params It's allowed for a server to send only in-band parameters, although I haven't encountered this yet. The VStarcam cameras sometimes send invalid out-of-band parameters; treat that as if it sent nothing. Fixes #42
2021-11-30 21:34:13 +04:00
prep v0.3.4
2021-10-27 08:32:27 +04:00
## `v0.3.4` (2021-10-26)
* use `rtsp-types` 0.0.3, and thus `nom` 7.0.
v0.3.3, fix #25: better HTTP auth support
2021-10-21 00:38:49 +04:00
## `v0.3.3` (2021-10-20)
* [#25](https://github.com/scottlamb/retina/issues/25): better HTTP
authentication support via the new [`http-auth`
crate](https://crates.io/crates/http-auth). Before, `retina` would only
authenticate properly if the first requested challenge was `Digest`. Now, it
will pick out a `Digest` or `Basic` challenge from a list.
prepare v0.3.2
2021-09-29 16:48:36 +04:00
## `v0.3.2` (2021-09-29)
mention TEARDOWN improvements in changelog Fixes #34
2021-09-29 16:30:58 +04:00
* better `TEARDOWN` handling, which often avoids the need to wait for session
expiration ([(#34](https://github.com/scottlamb/retina/issues/34)).
prepare v0.3.1
2021-09-10 09:01:58 +04:00
## `v0.3.1` (2021-09-09)
warn about #30
2021-09-01 00:27:13 +04:00
* warn when connecting via TCP to a known-broken live555 server version.
prepare v0.3.1
2021-09-10 09:01:58 +04:00
* improve Geovision compatibility by skipping its strange RTP packets with
payload type 50.
UDP fixes (#30) * 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.
2021-09-08 05:22:59 +04:00
* UDP fixes.
use sdp-types 0.1.3 with more permissive parsing Fixes #26 Fixes #33
2021-09-06 23:13:26 +04:00
* improve compatibility with cameras with non-compliant SDP, including
Anpviz ([#26](https://github.com/scottlamb/retina/issues/26) and
Geovision ([#33])(https://github.com/scottlamb/retina/issues/33)).
new more reliable TEARDOWN mechanism
2021-09-10 04:34:49 +04:00
* new mechanism to more reliably send `TEARDOWN` requests.
warn about #30
2021-09-01 00:27:13 +04:00
version 0.3.0
2021-08-31 17:59:47 +04:00
## `v0.3.0` (2021-08-31)
fix missing 44.1 kHz (#22)
2021-08-23 21:18:27 +04:00
get rid of ignore_spurious_data 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.
2021-08-31 17:48:23 +04:00
* BREAKING CHANGE: [#30](https://github.com/scottlamb/retina/issues/30):
experimental UDP support. Several `RtspMessageContext` fields have been
replaced with `PacketContext`.
* BREAKING CHANGE: remove `retina::client::SessionOptions::ignore_spurious_data`. This
was an attempted workaround for old live555 servers
([#17](https://github.com/scottlamb/retina/issues/17)) that was ineffective.
fix missing 44.1 kHz (#22)
2021-08-23 21:18:27 +04:00
* [#22](https://github.com/scottlamb/retina/issues/22): fix handling of
44.1 kHz AAC audio.
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
prepare v0.3.5
2021-12-01 00:37:03 +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.3.5
2021-12-01 00:37:03 +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
prepare v0.3.5
2021-12-01 00:37:03 +04:00
## `v0.0.4` (2021-06-28)
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
* bugfix: Retina stopped receiving packets after receiving a keepalive response.
prepare v0.3.5
2021-12-01 00:37:03 +04:00
## `v0.0.3` (2021-06-28)
prepare v0.0.3 release
2021-06-29 01:13:18 +04:00
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.3.5
2021-12-01 00:37:03 +04:00
## `v0.0.2` (2021-06-25)
prepare v0.0.2
2021-06-26 03:47:30 +04:00
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)).
prepare v0.3.5
2021-12-01 00:37:03 +04:00
## `v0.0.1` (2021-06-09)
prepare v0.0.2
2021-06-26 03:47:30 +04:00
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