WebRTC is not recovering resolution of video call

[William Cheung]

Hi WebRTC,

Working with an Android device and I've noticed that as the call progresses, the resolution of the video decreases. This is ok, as I believe it is WebRTC adjusting to changing resources. However I've found it never goes in the other direction, i.e. recover to the original resolution when resources are available.

Also WebRTC also seems to ignore session description min resolution constraints. If you set minimum width and height, WebRTC's dynamic resolution changer will definitely go below this if it wants.

Is this normal behaviour? A bug?  Anybody else had similar experiences?

Thanks

[Christoffer Jansson]

On Friday, November 13, 2015 at 6:23:03 AM UTC+1, William Cheung wrote:

Hi WebRTC,

Working with an Android device and I've noticed that as the call progresses, the resolution of the video decreases. This is ok, as I believe it is WebRTC adjusting to changing resources. However I've found it never goes in the other direction, i.e. recover to the original resolution when resources are available.

This sounds like a bug if your network and CPU has enough headroom. Please file an issue at https://bugs.chromium.org/p/webrtc/issues/entry if Native WebRTC and at https://code.google.com/p/chromium/issues/entry if Chrome. 

Also WebRTC also seems to ignore session description min resolution constraints. If you set minimum width and height, WebRTC's dynamic resolution changer will definitely go below this if it wants.

This is the resolution the camera is opened at, what's sent out on the wire is the camera resolution and potentially down 2 steps in resolution, i.e. If you open the camera at 1280x720, it can scale down to 960x540 and finally 640x360 depending on CPU usage and network bandwidth (effectively the video bit rate) .

[Peter Boström]

What device/app setup is this? If you're using AppRTCDemo you can turn on call statistics under the 3dot menu, here you can check bitrates etc. during a call. There's an (i) button that you can click to see a bunch of stats (I'd like to know codec). If your bitrates recover quite high, we might need to update the quality thresholds for the codec used.

I believe we use the min constraints for device resolution, but if bitrate / quality / cpu usage is bad enough we go down if we think that'll make things better (even if that means ignoring these constraints). Fun fact: H264 at the crappiest quality looks like you've downscaled resolution with about /16 either way, blocky and very minecraft-esque, so I'm not sure taking these constraints into account will look the way you want it either way. :)

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ce3a84cc-1a9e-4bd7-b04b-6dbc179d698f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.