4 ms·
So far I think the best option will be to do it on my own. But I would do it this way - the source would have to be VBR, not CBR since no transcoding would take
by hknmtt 4y ago
So far I think the best option will be to do it on my own. But I would do it this way - the source would have to be VBR, not CBR since no transcoding would take place. What is put in is also what will be put out. With 1Mbit recommended quality.. The ingress will simply chunk the stream into 1-2 second segments and those will be sent to my "CDN" servers which will serve it from memory only with about 30sec buffer. The data would be pumped out via websocket(so i can easily send binary data) into MediaSource js object as uri for html video src. If the client is too slow consumer, he'll buffer the video. I don't need to provide youtube level of service.
--
Just did a small test with 10 sec desktop video recording in OBS:
CBR 3.35 MB
VBR 343 kB
ABR 840 kB
CRF 344 kB
So by not using CBR the data stream can deliver the same quality at 10x lower size(VBR, CRF) or 3.9x in case of ABR. CBR is needed for transcoding due to speed needed for that process but if I would pipe the data 1:1 as I said, then CBR is detrimental.
- bobdvb 4y agoNote that if you use VBR instead of CBR the video player will have more trouble with buffering logic because (many players) will buffer a fixed duration or number of segments. When there's lots of action the bitrate will be high and when it's idle it will be low, so the variability causes buffer challenges. Capped VBR is one of the most common ways to do VBR on live streaming.
- hknmtt 4y agoi understand. the ingress will chunk the stream into those segments(1-2 seconds long), remember the encoded video is packed in mp4 container, and pass them on to the egress/edge/cdn servers into their in-memory buffers. so the only processing will be done in regards to those chunks.