17 comments on “WebRTC Video Resolutions 2 – the Constraints Fight Back

  1. I’m puzzled by your reference to the Microsoft Lifecam Studio as being 1080p capable. I don’t believe that it’s produces 1080p video. MS is unclear on the matter as they claim it has a 1080p sensor, but that it’s capable of “720p video chat.”

    As a USB 2.0 connected camera without an onboard encoder it cannot pass uncompressed 1080p frames at rate that many people would consider “video.”

    Webcams that are 1080p capable, like the Logitech C920, C930e, BBC950 and CC3000e have an onboard encoder chip that compresses the frames using either MJPEG or H.264. The software that init’s the camera needs to know about these modes in order to correctly init the camera to deliver a compressed stream.

    • I read the same reviews about quasi-1080p support on the Lifecam Studio, but did not think much about it since Chrome only used to do 720p. All I can say I did a getUserMedia request with mandatory constraints asking for 1920×1080 and it returned a stream that was 1920×1080. The Chrome FPS monitor indicates it is running at 20 FPS.

      I just did this quick test:
      https://www.dropbox.com/s/ft75cw4g821bu9y/Lifecam%201080p%20check.png?dl=0

      I guess it is possible Chrome is stretching the image, but it does appear to be clearer than a normal 720p stream. Also, Chrome does not stretch for resolutions above 1080p, or on other cameras above 720p, so it seems odd it would stop at 1080p.

      I will do some more tests and let you know if I find anything interesting.

  2. Hi, I’ve been doing some research for a project looking at providing a cheap, reliable ‘digitisation’ solution for family heritage projects, something that could be set up in libraries, local history society events etc. If I can get good quality 1080p still images from a webcam and a browser interface, that starts to become realistic and would be an amazing step forward compared to tethered digital SLRs and bespoke software.

    So, my questions are:
    – for testing, what sort of webcam is currently available that might let me test this? I note the comments above that say the Microsoft one is not true 1080p, and the Logitech ones compress, which implies some sort of degradation in quality for stills at least
    – how soon do you think the browser technology will move forward to a stage where 4k might be possible, and what devices exist to capture this? Could a 4k phone camera like the S5 be rigged up to an external device?

    If you think I am going up the wrong road for this then do let me know!

    Thanks, James

    • I did not state this clearly, but camera 0 and camera 1 in the result data was my Galaxy S5. I tried doing a 4K capture but I could only get up to 1080p.

      I am not sure if you will be able to get consistent high-quality images from WebRTC today. However, I think this situation is improving. First, I would look into the Camera API. I have not tried any of this, but you can see some details on this here: https://developer.mozilla.org/en-US/docs/Web/Guide/API/Camera It looks like this is more of a mobile solution.

      I have not heard any statements on this, but I would guess increasing WebRTC’s maximum resolution to 4K will make more sense in Chrome when they add VP9 support for WebRTC. Justin stated this would happen by the end of the year (see Tsahi’s summary here).

      As I talk about in my first WebRTC Camera Resolutions post, Firefox does not let you dynamically change the resolution, but you can manually adjust the settings. I have not tried manually specifying a 1080p or 4K resolution tests in Firefox’s navigator.media.video settings, but that would be a good experiment.

      Lastly, some of the ORTC recommendations could make specifying different media parameters. However, taking high quality photos is not in the initial target applications for ORTC.

  3. Really good post.

    But I have some trouble with the correct identification of some resolutions. I run Chrome 40 with a Logitech C310 camera.

    The highest resolution which are supported by the camera is sometimes listened and sometimes not. 720p@16:9 is a problem. I get this resolution just if I clone your code locally and run it via http (with manual confirmation of the camera Access for each Resolution test). Then it appears on the list as “passed” and may be selected and get displayed in the Video window.

    When running the https test this Resolution sometimes passes and sometimes not (fail: mismatch).

    Regards
    Matthias

    Could be a timing Problem because the timing is quite different when I must manually confirm the camera access when using http instead of https.

    • Thanks for the comment Matthias. Yes – I notice this very infrequently on some large scans too.

      To start out I would recommend changing line 220 of resolutionScan.js to a value greater than 100, like 200, to see if this helps.

      Better would be to identify a more reliable event trigger before reading the resolution from the video element. I was unable to find one, thus the “100 ms” delay I added on line 220.

      It may also be better to not use jQuery to bind to the event to minimize the delay.

  4. To add to this post:
    – the resolutions supported by the Capture Device(s) are listed in chrome://media-internals — after the user having allowed at least once either capture or device listing (e.g. [1] and click on “Get Devices”).
    – Chrom(ium) will try to get from that list the closest resolution to the one requested by the user, in terms of “amount of pixels distance”, yet still with each dimension >= than the requested. The captured video frames will be cropped if needed.
    – Sometimes cameras do not enumerate correctly depending on the combination of OS version, vendor/kernel support and API arcanes, in that case Chrome will fall back to a list of precooked, widely supported resolutions.
    – Sadly there’s no way to get the supported resolution list from JavaScript, although it can be retrieved from a Chrome App.

    [1] https://src.chromium.org/svn/trunk/src/chrome/test/data/webrtc/manual/peerconnection.html

  5. Pingback: The Best WebRTC Tutorials! | Share For Life

  6. hi,

    thanks for your great work!!

    one question:
    when I start your scan, your program get access to my webCam without asking me if it can.
    how did you do this?
    In my project the call of getUserMedia leads to the pop-up where the user have to give the ok for the access to the webCam.

    regards
    Matt

  7. I updated the scanner, added Edge, ran new scans, and made some new findings to this post here:

    • By best available, do you mean highest? Note that higher resolutions often result in lower frame rate capabilities. Definitely check out the update to this post here: https://webrtchacks.com/getusermedia-resolutions-3/

      There is no way to ask for “give me the highest available” in implementations today. If you check out the Media Capture and Streams spec, something closer to this is coming, but I don’t believe anyone has implemented it yet.

      Generally the browsers provide the best available resolution they can determine if you provide a realistic range. Manually trying to determine what is available with something like the scanner I made definitely does not provide for a great user experience but is one way to do it.

  8. Hello Chad,

    The video is freezing after some time when communication started in between web(Chrome) with android native webRTC.

    We are using Chrome 56.0.2924.87 and Android 6.0.1

    But in same devices (web to web) and (mobile to mobile) its working good.

    This issue is coming when the Chrome updates to 56 and it worked in the previous version of Chrome.

Leave a Reply

Your email address will not be published. Required fields are marked *