Adaptive Stream and "Auto" decision

[morbificagent]

Hi together,

I have configured OME for adaptive output and was testing LLHLS and WEBRTC via the demo player.
But in both versions i have the same problem:

It always falls to the lowest resolution/bitrate.

I have configured 720 (1,8Mbit), 480 (600kbit), 240 (300kbit) but even when it starts playing at 720 it changes to 480 first and then to 240.

The bandwith-settings are like this:

                <Video>
                    <Name>720p_h264</Name>
                    <Codec>h264</Codec>
                    <Bitrate>1500000</Bitrate>
                    <Width>1280</Width>
                    <Height>720</Height>
                    <Framerate>30</Framerate>
                </Video>
                <Video>
                    <Name>720p_vp8</Name>
                    <Codec>vp8</Codec>
                    <Bitrate>1500000</Bitrate>
                    <Width>1280</Width>
                    <Height>720</Height>
                    <Framerate>30</Framerate>
                </Video>
                <Video>
                    <Name>480p_h264</Name>
                    <Codec>h264</Codec>
                    <Bitrate>800000</Bitrate>
                    <Width>854</Width>
                    <Height>480</Height>
                    <Framerate>30</Framerate>
                </Video>
                <Video>
                    <Name>480p_vp8</Name>
                    <Codec>vp8</Codec>
                    <Bitrate>800000</Bitrate>
                    <Width>854</Width>
                    <Height>480</Height>
                    <Framerate>30</Framerate>
                </Video>
                <Video>
                    <Name>240p_h264</Name>
                    <Codec>h264</Codec>
                    <Bitrate>300000</Bitrate>
                    <Width>426</Width>
                    <Height>240</Height>
                    <Framerate>30</Framerate>
                </Video>
                <Video>
                    <Name>240p_vp8</Name>
                    <Codec>vp8</Codec>
                    <Bitrate>300000</Bitrate>
                    <Width>426</Width>
                    <Height>240</Height>
                    <Framerate>30</Framerate>
                </Video>

I have tested it in chrome on two different machines (home macos, work win) with two different internet speeds (home 16Mbit, work 200Mbit) and the OME server is inside an RZ a few miles away with a good peering.
Manual selecting the 720p variant works great without problems...

So i cant understand why it always chooses the badest stream.

I have tested LLHLS in THEOplayer and there everything is fine as it selects my 720p variant.

Does anyone have this problem too?

[nums]

I have the same issue on my side.
For now, I don't know if the source of the issue is hls.js or ovenplayer.
Maybe, we can resolve this with a custom "Auto decision", while using window.op_hls.abrController.bwEstimator.getEstimate() the data return of this method seems good and then we can adapt the quality level compared to that.
I will do some check and let you know

[nums]

I suggest this quick and dirty temporary fix:

ovenPlayer.on('ready', (evt) => {
  setInterval(() => {
    let currentBW = window.op_hls.abrController.bwEstimator.getEstimate();
    
    let levels = ovenPlayer.getQualityLevels();
    levels = JSON.parse(JSON.stringify(levels));
    levels.sort((a, b) => a.bitrate - b.bitrate);
    let index = -1;
    for(var i in levels) {
      let level = levels[i];
      if(currentBW > level.bitrate)
      index = i;
    }
    
    if(index != -1 && index != ovenPlayer.getCurrentQuality() && ovenPlayer.getState() == 'playing') {        
      console.log('ABR', 'we change index or quality level', currentBW, index, levels[index]);        
      ovenPlayer.setCurrentQuality(parseInt(index));            
    }
    
  }, 3000)
})

I have tested it with the bandwidth limitation of chrome developer tool.

[morbificagent]

@nums

Many thanks!

I will test this too and respond after the weekend...
Have a nice one

[Remboooo]

I've run into this as well and provided some analysis on what's going on in this issue on the OvenMediaEngine project. The root cause is that Chrome reports a value for availableIncomingBitrate that is way too low. Seems to just be a bug in Chrome, in firefox this mechanism works fine.

[nums]

Hi @Remboooo, on my side I have two topics : WebRTC ABR and LL-HLS ABR, I have made more investigation on these here : AirenSoft/OvenMediaEngine#1684

The LLHLS ABR issue is due to how hls.js calculates available bandwidth with very small chunks.
WebRTC ABR is more on the OME side, relying on the goog-remb algorithm for bandwidth estimation.

[Remboooo]

@nums Interesting! I do notice that WebRTC ABR on Firefox works just fine, suggesting it's not a problem om the OME side. Additionally, on Chrome it's totally broken even when streaming full-motion content at a fairly constant bitrate, so not just stills as in the issue you linked. It just reverts to the lowest quality eventually even when streaming 8Mbps video on a Gbit link. I got excited by the workaround you posted, but ofcourse this only works for HLS as it relies on window.op_hls. Have you by any chance found a workaround that works for WebRTC on chrome as well?

[nums]

hey @Remboooo, my idea would be to analyze the customer side stats. But what is complicated is that Safari, Chrome and Firefox does not always dissolve the same information.
For example Firefox does not give info on the round trip which is the very interesting to understand the problem of engorgement network of UNT user: https://bugzilla.mozilla.org/show_bug.cgi?id=1542938
For the estimation of the bandwidth, I think it is not possible like that, we must wait for the implementation of transport-CC.
I am looking for statistics given by all browsers who could give us information on possible lags of viewers