Once again, this was supposed to be v3.9.0, but Ubiquiti totally derailed that when a Streamie user updated Protect to v1.12.22 and we found that under heavy network load, we’d see invalid RTSP fragmentation units. After determining a testing procedure that would reliably cause the stream corruption, and then identifying the invalid data, I updated Streamie to fail gracefully, which basically means dropping subsequent video frames until the next key frame. This prevented any decoder failures that would have necessitated recreating the decoder instance and it almost entirely hides the issue from the user, who will at most see a frozen image for a couple of seconds. Normally.
We thought the story was over at this point, but we saw that sometimes the state on the Protect system that produced the invalid fragmentation units in the RTSP stream would never resolve itself, resulting in a “We are stalled!” alert because Streamie was never able to get a good key frame due to the frequency of the bad fragmentation units. In considering a solution to this, I removed an RTSP-specific activity checker that only cared about continued network traffic, and replaced it at a higher level with an activity checker that cares about video frames — a more generalized solution that’s better in line with what we actually care about (having video frames to show the user), and which works with all of the streaming mechanisms (RTSP, WebRTC, Attached, etc). This change didn’t make it in time for this v3.8.3 release though; look for it in the next one.
This issue and it’s resolution makes Streamie less trusting that fragmentation units will always be correct, making us a little bit more resilient in the face of bad data, which is good; that was the whole point in moving away from FFmpeg. Moving the activity checker solves a whole class of problems and provides a consistent user experience when video frames aren’t showing up.
- Improves error handling for SMB configurations, preventing crashes and showing (hopefully) helpful error messages to the user.
- Removes use of 'GetHostname' in CMCOnvifService because 1) we weren't doing anything with the result and, 2) it turns out not all cameras support it. This fixes a compatibility issue with Vikylin cameras, which apparently don't support the GetHostname request. [DS]
- Fixes a regression where the camera delay time was not being honored. [DV]
- Improves compatibility with cameras running Darwin Streaming Server (Wansview) where the order of elements in the SDP was not as expected. [RS]
- Fixes a crash that occurs when tapping on a placeholder cell for an empty list when browsing NAS recordings.
- Adds a delay indicator to each camera cell so that you can quickly see which cameras have been configured with a timing delay.
- Improves support for RTSP streams that have invalid fragmentation units (as seen with Ubiquiti UniFi Protect when under heavy load). [DV]
- Reverts a previous change back to our custom options menu view instead of a UIAlertController because presenting the controller caused streaming instability. (tvOS)
- Adds mention of typical support hours of operation to the Support screen.
- Adds support for checking the pasteboard for a URL when creating an RTSP or ONVIF camera. (iOS)