Websocket backpressure and adaptive bitrate
Whilst direct C++ node connections can now drop frames and detect bandwidth problems, going via the web service does not allow for this yet. It is necessary to detect websocket backpressure in the socket service and use this information to generate a new bitrate request.
Each video stream is enabled by requesting N frames (typically 30) at a time, along with specifying a suggested bitrate in the request. The source machine can then encode that video at the best overall bitrate for all observers and broadcast that to everyone who requested it. When the web service is involved, it must take on this responsibility by monitoring for any bandwidth limitations of the observers connected via the webservice and coming up with a combined suggested bitrate to send back to the source. The websocket send
method has a callback as the second argument that is called when the message data is actually written. The idea is then that this could be used to decrement a counter that is incremented when send
is called, and the value of the counter would be 0 or 1 under good conditions, but would increase if data could not be sent fast enough. As the counter increases it indicates that the bitrate requested is too high and should be reduced.
Note that the bitrate of all clients watching that stream must be estimated and then the overall minimum must be used when generating a request. Currently, each client directly makes its own bitrate request. This is not ideal, the socket service should combine requests into a single best request to match the poorest connection.