Remove Bridged Cameras

[dgreif]

It's time to finally remove bridged cameras. This PR still needs some extensive testing, but I'd also like to see if we can drop ffmpeg entirely.

@tsightler do you still have a branch around which doesn't use ffmpeg?

[tsightler]

@dgreif I was able to find it on my old laptop, but it's super hackish. Should be easier with bridge camera logic completely removed though so let me see if I can clean it up and get it to merge with this branch. I'll try to do it later today or tomorrow at the latest.

[tsightler]

I put a somewhat cleaned up no-ffmpeg branch, using this no-bridge branch as the base, but it's not quite working yet, and I haven't managed to get to return audio yet, but it's a start. Hopefully I'll be able to figure out what I broke as it worked the last time I tested it, but it was way more hackish and didn't have the latest updates for opus-packetizer.

[dgreif]

Awesome, thanks for looking into it! Any chance Scrypted has what we need, given that's where we got the repacketizer?

[tsightler]

I actually brought over the latest opus-repacketizer fixes from Scrypted, so I'm thinking that's how I broke it, as it changes how packetizer works somewhat (returns an array of packets). I thought I handled everything correctly, but still digging into it a bit as it's not really obvious at the moment as I see can see the RTP packets making their way through the chain, and everything looks correct, but I get no audio. Homekit Opus audio is so incredibly picky, but it works pretty well once you get it right!

[tsightler]

OK, as I dug into this, I realized that the problem is a bit deeper and perhaps this is not worth it. The issue is that Homekit requests a bitrate and frame duration as part of it's negotiation and, while it is tolerant of the bitrate not matching (as long as timestamps are accurately calculated) it is 100% intolerant of frame duration being different. If it requests 20ms frame duration, it really expects 20ms frames, if it requests 60ms frames, it expects 60ms frames.

So it seems, as long as the timestamps are manipulated correctly, that Homekit can deal with the 48K bitrate that Ring cameras send, even though it typically requests 24k bitrate or even lower, but it cannot deal with the fact that Ring cameras send 60ms Opus frames by default, while Homekit requests 20ms when running on LAN. For WAN/LTE, Homekit requests 60ms so just passing frames through, with nothing more than timestamp changes, appears to work just fine.

The opus-repacketizer code combines frames, so if you have 3 frames of 20ms duration, and homekit has requested 60ms duration, it will combine them into a single 60ms frame, but it doesn't split longer duration frames into smaller ones. I could code this up, but I'm wondering if it's worth it as, technically, the current behavior having ffmpeg transcode the audio to the correct bitrate/frame duration seems to be the more correct option.

[tsightler]

@dgreif I'm going to pull the no-ffmpeg branch. After much testing, I can't make it reliable enough or get rid of the choppiness of the audio without transcoding and, in some cases (Apple Watch for example), it just doesn't seem to work at all. I do have some minor improvements for the audio streaming code though, but I will publish it under a different branch with a full explanation and it will still use ffmpeg.

If we really wanted to get rid of ffmpeg, we could potentially use a libopus encoder/decoder library, there are some WASM based libraries that seem to work fairly well, but it adds more complexity than it removes since you still have to deal with building RTP packets, which ffmpeg handles for us.

[dgreif]

Thanks for continuing to dig into it! I think your understanding of what's required is better than mine at this point, so I trust your judgment on keeping ffmpeg. Simply dropping the aac-led requirement should help some, so I'll work on getting this merged in the next week or two (holidays are busy for me).