4 Comments
User's avatar
Concerned Citizen's avatar

why not "just" use HLS/LL-HLS/DASH etc, things designed for livestreaming over TCP?

https://moq.dev/blog/distribution-at-twitch/

https://moq.dev/blog/replacing-hls-dash/

^ website is about QUIC/HTTP3 which you obviously can not use, but it has nice summaries of the existing solutions

but the hacky solution would be to tunnel something else over tcp :p

joeyjojo55's avatar

If the system package is missing functionality you consider important, please consider at the absolute least making a bug report about that. Complaining on your blog is satisfying and all, but ultimately not helpful.

Mikail's avatar

I’m curious about the video codec exploration process here. Were lower bitrates tested with h.264 before moving to the JPEG solution? I’m wondering because video compression typically handles mostly-static screen content really efficiently, especially at lower bitrates where you’re mainly dealing with text and UI elements that don’t change much frame-to-frame.

Also curious if you considered newer codecs like AV1, or even just dropping to 720p at a higher quality setting? The delta compression in video codecs seems like it would be particularly well-suited for this use case.

Was it a matter of implementation complexity? Compatibility?

youfa's avatar

how about use dynamic framerate with h264 streaming?

like what webrtc does:

1. detect network bandwidth -----> change encoder bitrate rate

2. VideoSource -----> Encoder -----> EncodedImage ---> detect image quality(qp) / output bitrate

| |

whether drop this frame <----------------------------------------------feedback