17 comments on “getUserMedia resolutions III – constraints unleashed

  1. Chad,

    Great post! In so far as the webcams are concerned there are a few additional things that you might consider.

    1 – You need some newer webcams. The MS Lifecam is a quirky beast that relies heavily upon a Windows device driver for decent performance. Logitech’s C500 is ancient. Neither are capable of 1080p.

    The Logitech C920 and C930e are really the current benchmarks. Logitech seems to have rebranded the C930e as the HD Pro Webcam.

    2 – Consider frame rates, especially at higher resolutions. There are a few webcams that deliver 1920 x 1080 pixel frames, but may not deliver them at rates that you might consider useful. If the application doesn’t leverage UVC1.1 (MJPEG) or UVC1.5 (H264, VP8?, SVC?) to request compressed frames the frames will be uncompressed. Thus the maximum frame rate rate will be limited by the USB 2.0 bus speed.

    3 – Does getusermedia() allow the use of such flags for compression?

    • Since I have several webcams hereabouts a simple experiment or two has answered some of my own questions:

      With respect to the Microsoft Lifecam Studio, when using the sample resolution select page that you cited, the camera can be asked for “Full HD” and returns a stream that is that dimension. However, I believe that the camera is actually delivering 720p that’s being scaled up. The result is simply not as sharp as selecting Full HD from a C920.

      Further, the C920 delivers a proper 1080p stream. I suspect that GUM is using the UVC1.1 capability to deliver MJPEG encoded frame. In infer this by observing that there’s minimal latency to the video.

      When I’ve used software (vMix) that has explicit control of the webcam encoding I can use the UVC1.5 capability to request H264. This always returns a stream that’s delayed around a second.

      • Michael – thanks for the great comments!

        1. I am definitely in need of a new camera and will use your suggestions. I was actually considering getting a 4k camera which is what prompted me to check to see the max resolution support in the source code (where I discovered 4K would be a waste at this point).

        2. I have played around with framerates in similar test as this. I ran out of time to work on that as part of this post.

        3. Not that I know of or have seen anywhere. It certainly is not in the spec.

        • A few years ago, seeing that they were destined to become ever more important, I started to explore the state of the art in webcams. It sad really, how little progress has been made in the realm. It’s basically stagnant.

          4K “webcams” are a rarity. USB 3.0 capable webcams are nearly as rare. These fact are related.

          There’s more to image quality that the sheer number of pixels. Noise, performance in varying lighting and color depth are all things that could be improved, even at 720p or 1080p.

          I suspect that 4K webcams won’t matter at all for another couple of years, even as 4K displays become commonplace.

          If you want to pick a fight, how about we charge manufacturers with installing built-in webcams that can compete with their aged external counterparts? That’s be a noble effort.

  2. Chad,

    Great post! It is highly appreciated!

    1. -=1080p max =-
    You mentioned in the port that you couldn’t find any 1080p max limit in chrome source.

    In JSEP I found a 1080p default max value may this is what you are looking for:

    2. -=4k & WebRTC=-

    January 2015 I had received a great opportunity from PSNC, and tested webrtc in 4k environment.
    Let me share in nutshell here my experiences.

    That time my experience was that I could use and grab 4K input.
    My setup was the following
    * PC (Core i7 850 3.07Ghz CPU, 6 GB RAM, 1 TB storage)
    * Blackmagic Decklink 4K Extreme card
    * Blackmagic Production Camera 4K UHD (3840 × 2160) @ 30FPS

    I could successfully grab with getusermedia 4k UHD

    * chrome (Windows 7):
    Canary 42.0.2280.2
    Dev 41.0.2272.3
    Beta: 40.0.2214.85
    Stable 39.0.2171.99
    * Opera(Windows 7)

    Failed to grep input with mozilla firefox (balck screen)
    * Firefox
    Stable 35
    Nightly 38

    Please see some images about the successful tests:


    I used also your handy camera/resolution finder tool during the tests. It worked perfectly, and so it is appreciated very much your hours you had spent developing it. Many thanks again!!

    I also tested peerconnection.
    To setup a peerconnection with UHD 4k media I tested with apprtc.

    You could see a screenshoot about the webrtc internals page:
    * googFrameWidthInput ~4k
    * googFrameHeightInput ~2K
    but encoded and sent video was only 2K.
    * googFrameWidthSent ~2k
    * googFrameHeightSent ~1k

    I could grab 4k video with getusermedia, but chrome encoded and transmitted only 2K.

    All in all according my experiences 4k was experimental at the beginning of 2015. Had some promising signs, partially working getusermedia, but also had many limitations.

    I look forward to your next great post..

    • Wow. That is really interesting.
      On #1, I meant that I could not find reference to a resolution greater than 1920×1080 in the source code anywhere (thanks for sharing the search link). Your results indicate that the Chrome and Opera team must have changed this – in the desktop versions at least.

      I was hoping to see getUserMedia return a 4K resolution on my Galaxy S5, but it did not. That is the only 4K camera I have. I would be curious to see if other people are able to get 4K on mobile.

      Thank you so much for sharing!

  3. This smells like a bug on mobile…

    I’ve seen the same strange behavior here…

    On my SG5, all vertical resolutions < 265 require a 16:9 resolution

    The "smallest" 16:9 resolution is 354×199

    In comparison: The Nexus 7 did pass the test very well, not a single 2×2 video tag has been generated.

    Our Nexus 9 and Nexus 5 passed every single test from 320 to 120 without any problems.

    A Moto G2 has the smallest "4:3" resolution of 321×241 and a minimal 16:09 resolution of 322×181

    I am still collecting more data …

    Our WebRTC application is bandwidth sensitive and the resolution has still a deep impact on the total bandwidth needed.

    With a variety of many different devices and results… how could we possibly set bandwidth friendly resolutions in a "standard" way without probing for an unknown amount of resolutions?

  4. Hi!

    Do you know how to solve the “Orientation” problem???

    I want it to give me landscape video when the person is using the phone in portrait….

    I’ve tried the old and new constraints an none work… It always gives me portrait video….

  5. Hello vuys;
    in the article you are describing tests of front/back facing cameras in mobile headsets.

    is there any way to push eg. Firefox mobile to support external USB camera connected to USB HOST port in mobile device?

    I have tried

  6. I have tried tried mobile versions of Firefox, Chrome but none of them lists external USB camera as available video ource for webrtc connection?

  7. I noticed what I think are a couple of typos in the constraints code up above.
    1) in your “old” code, you have an extra “{” in minWidth (line 6)

    2) in your “new” code, you need to delete the extra “}” on line 7 since there is no “mandatory” component anymore that put it there in the old code.

    Great writeup, thanks!

  8. I am looking for some pointers to keep the resolution at its best and drop the frames if required if WebRTC has low bandwidth. How can I achieve this?

    Any help is appreciated.

    • Unless you have an unusual circumstance, It is generally best to use ‘ideal’ when setting up your constraints and then allow the WebRTC engine to optimize. The WebRTC engine includes a bandwidth optimizer that will alter the resolution, image quality, and framerate automatically based on the bandwidth it estimates.

      Are you looking to drop frames before reducing the image quality/resolution when you experience bandwidth issues?

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.