Livestreams: separate out video stream quality forcing between high-latency and low-latency clients

[vldt]

Describe the feature request

For livestream viewing, separate out video stream quality forcing between high-latency and low-latency clients.

Assuming all stream qualities are available from Protect, this will have 3 major benefits:

1. For remote, if not transcoding, we will only transmux and save a lot of CPU.
2. For remote, if transcoding and local is forced to High, we will potentially transcode a smaller res stream thus saving CPU
3. For local, we can keep forcing to high and not transcoding without compromising remote performance.

The story behind this is my own setup:

• All video stream qualities available from Protect
• HKSV (hogging a lot of CPU)
• Livestream quality force to high <--- must-have for Local
• Livestream Local using to transmux <--- must-have
• Livestream Remote forced to transcode <---- inefficient compromise to due to requirements for Local

If remote livestreams had the freedom to choose the stream directly from the Protect controller, then no transcoding might be needed thus saving a lot of CPU. Even if transcoding would still be necessary for some cameras, this plugin could potentially pick a lower res stream thus saving CPU.

Describe the proposed solution

1. In Video Feature Options, add the following 3 knobs:

   • [ ] When viewing livestreams from High-Latency clients, force the use of the high quality video stream from the Protect controller.
   • [ ] When viewing livestreams from High-Latency clients, force the use of the medium quality video stream from the Protect controller.
   • [ ] When viewing livestreams from High-Latency clients, force the use of the low quality video stream from the Protect controller.

2. When all 3 of the above are unchecked, auto select video stream similar to how it currently works for the current triplet of force video stream quality options.

3. Make the original 3 only apply to Low-Latency clients and update the wording.

Describe alternatives you have considered to the enhancement

As an alternative, just add a single extra checkbox instead of the 3 I proposed:

• [ ] When viewing livestreams from High-Latency clients, do not force the use of a specific quality video stream from the protect controller.

[hjdhjd]

Thanks for the request...I'll consider this for the future, but unlikely to add it at this time.

[hjdhjd]

I should further add - the world is likely going to look significantly different in the future within HBUP, given the direction we're heading. If you want to use a solution that's not going to hurt your CPU...then, as you can today:

1. Transmux locally - stream quality is irrelevant by and large and you're largely CPU-constrained by your network stuff.
2. Anchor on a lower stream quality than High.

You've already outlined the correct tradeoffs. Ultimately, if this is a real issue in your life, and you're using something like HBUP...I would advise ensuring you have the appropriate horsepower for the best experience.

I have a few things in mind for the future that will ease some of this...but none of it eliminates the core issue: you can choose to run on underpowered hardware and have a suboptimal experience, but it's still suboptimal.

[vldt]

More powerful hardware than an RPi5 would result in a steep increase in TCO for my case. I would gladly pay if necessary, but right now I think SW can do better enough to avoid the TCO increase.

I think the feature I requested is a sensible optimization that sits well before the point of negligible returns. ~30% CPU savings when RPi5 is already running at capacity due to HKSV can greatly lower latency for remote viewing.

There is plenty of room at the top :)

[hjdhjd]

Appreciate the request...we disagree that it's a sensible one at this time. HBUP is opinionated software by design...I hope you'll continue to trust my opinions as it progresses and appreciate what is in store for the future.

Pi5 is not ready for primetime for this use case, yet. Software stack on the Pi5 is still wobbly, at best. But perhaps later this year.

Thanks again for the discussion.

[github-actions[bot]]

This issue is locked to prevent necroposting on closed issues. Please create a new issue for related support requests, bug reports, or feature suggestions.