- Bugfix for input options categories in checking if there are custom parameters in a push url
- Option groups now have an ability to expand/collapse. When collapsed a summary of non-default configured options is shown.
- Question marks in the target should be kept as part of the target url. Additional params should always be added after an additional ?.
- Improved (mostly SRT) push param options layout
- Fixed option groups:
- 1: Typing in PUSH TARGET will reset all settings set up below
- 2: If you hide settings the settings do not propogate
- 3: Sublist and option categories share the same container class name, causing CSS collisions
- Return ICE headers for WHIP/WHEP/WISH OPTIONS requests already to help clients that cannot change ICE servers post-SDP-request-generation
- Fixes to WebRTC WHIP/WHEP GET param parsing
- Added "constant" GET param for forcing constant-rate playback
- Use correct syntax for WebRTC Link headers
- Fixed several possible segfaults when selecting non-existing tracks in HLS
- Fixed error when requesting a stream with no compatible HLS tracks
- Fix a possible segfault when playing back an invalid track
- Fixed HLS cache control logic
- Fixed slow lookup of blank hostnames (now skips lookup entirely)
- HLS output replies with 204 rather than 200 for OPTIONS requests
- Removed out-of-the-box compatibility with iOS 10 and lower in the HTML output, in favor of better iOS 11+ support.
The Bosch FLEXIDOME 4000i camera sets the RTP payload type to 35 for
H264, which causes MistServer to output "FAIL: Payload type 35 not
supported!"
The camera probably uses 35 for H264 because the ATSC standard requires
it. A/153 Part 7 states: [1]
> In addition, for RTP packets that carry AVC video elementary stream,
> the payload_type field in the RTP header shall have value 35.
The camera also sends "a=rtpmap:35 H264/90000" to explicitly map the
value 35 to H264. This is perfectly valid; although payload types 96
through 127 are recommended for dynamic use, the RTP protocol allows any
AVP payload type to be dynamically reassigned. The relevant section of
RFC 3551 states: [2]
> This profile reserves payload type numbers in the range 96-127
> exclusively for dynamic assignment. Applications SHOULD first use
> values in this range for dynamic payload types. Those applications
> which need to define more than 32 dynamic payload types MAY bind
> codes below 96, in which case it is RECOMMENDED that unassigned
> payload type numbers be used first. However, the statically assigned
> payload types are default bindings and MAY be dynamically bound to
> new encodings if needed. Redefining payload types below 96 may cause
> incorrect operation if an attempt is made to join a session without
> obtaining session description information that defines the dynamic
> payload types.
If the payload type is not recognized, assume that an rtpmap line will
follow that defines it. If in the end there is no rtpmap line, error out
in the same way whether the payload type is between 96 and 127 inclusive
or whether it is outside of that range.
[1] https://prdatsc.wpenginepowered.com/wp-content/uploads/2021/04/A153-Part-7-2012.pdf#page=14
[2] https://datatracker.ietf.org/doc/html/rfc3551#page-6
- Fix various incompatibilities and differences between Linux and Cygwin builds
- Make usrsctp an optional dependency
- Fix building without SSL
- Add new secure random bytes function, use it for websockets
- Switch to libsrtp2 v2.6.0 (currently latest release)
- Add patch that makes latest libsrtp2 build in latest Cygwin
- Add patch that makes srt build in latest Cygwin
- Correctly allow linking libsrtp2 and srt to local mbedtls version
