Idea is to use it for scalability, to enable more viewers than a single server can bear. If we re-encode stream with ffmpeg, it works just fine, but results in a high CPU load for encoding. Without encoding though, result looks like this:
Of course i read this. It only says “application should implement something similar to what the router.pipeToRouter() method already does”. Is there any practical, real world example of this? We have spent about 90 hours of work time trying to put together an example, and still nowhere.
I don’t think there are examples of that. Examples of what exactly? What you need to do is exactly the same as pipeToRouter() does but taking into account that, in your case, your mediasoup Worker instances live into different hosts, so you need to do signalling between both hosts to replicate what pipeToRouter() does. Just that. You can interconnect your servers via HTTP (in both directions), WebSocket, any PUB-SUB mechanism, etc. That’s up to you.
It’s super serious. No magic here. You can use libmediasoupclient (or other tools such as gstreamer/ffmpeg) to behave as a re-encoder. No public example of it AFAIK.
My client really really wants to NOT do any transcoding. I heard that Mediasoup throttles FIRs to no more than one per second. Is there a way to maybe increase this value to say once in 3 seconds or once in 5 seconds? If it takes changing C++ code, fine - can you point us at the line with constant?
My idea is that if it’s once per 5 seconds it means that some clients will have to wait for a few seconds for a keyframe, so fine, let it be, but the stream won’t swell up 3x in bitrate just ~1.4x which is acceptable?
*“i heard” is precisely, from here: https://github.com/versatica/mediasoup/issues/227 Currently the Producer.cpp class in mediasoup server already limits the number of PLI/FIR sent to the client. Basically, no more than 1 PLI/FIR per second is sent. If another PLI/FIR is requested in the meanwhile, it's delayed.
And yes, i just discussed with my client. Just simply switching that limit from one FIR in 1 second to one in 5 seconds, even if it has to be hardcoded, will do. How can i do that? Thanks!
But does it sound like a good solution to you? Apart from resulting in slightly increased bitrate for same quality of video, and having people wait an extra couple seconds for the first frame to arrive, does it allow for limitless scalability of the same stream without taking any additional technical debt, and without any transcodings?
In theory yes. Said that, if a viewer looses many packets and needs to ask a keyframe, given the 5 seconds “protection”, it may happen that such a viewer gets frozen video during up to 5 seconds (if other viewers are also requesting a keyframe).
