This would be an application level implementation.

Thanks for sharing this Chris – I’ll definitely take a look!

It might be worth reviewing how we implemented ABR for WebRTC using Red5 Pro. https://www.red5pro.com/docs/autoscale/transcoder.html#red5-pro-autoscaling—transcoding-and-abr

We don’t actually transcode at the edge server, instead we use the variants provided by either the encoder hardware directly, or our transcoder node in the deployment. We then just deliver the best stream based on REMB coming over the RTCP channel.

With VOD or static video streaming it is slightly different – today much of the effort there is also about the network quality of the viewer since you don’t want him to experience buffering incidents if you can help it. Which is why ABR is employed – static content is then generated in multiple bitrates in small chunks (2 seconds or so usually).

Theoretically, you can try to do the same for WebRTC as an ABR solution, deciding on “chunk” sizes or defining these chunks dynamically while looking across all your viewer population.

Because there’s not much in the way of ABR today in WebRTC media servers, doing it there is harder – especially considering that you’ll need to do things dynamically as well and not only offline by creating static files.