All posts tagged camera

Back in October 2013,  the relative early days of WebRTC, I set out to get a better understanding of the getUserMedia API and camera constraints in one of my first and most popular posts. I discovered that working with getUserMedia constraints was not all that straight forward. A year later I gave an update after the situation with Chrome was greatly improved, but Firefox at the time effectively only supported a single resolution so constraints were not much help. Specifically, I am interested in understanding what happens when you ask for a specific resolution. You might want to have a specific resolution returned by getUserMedia if you want to match the camera resolution to a specific video area to have a 1 to 1 pixel correlation, in a computer vision application where each pixel represents a distance, or if you are dealing with non-standard video devices. ...  Continue reading

Note: See February 2016 update here.

{“editor”, “chad“}

Last October I did a post on some quirks I found when applying camera resolutions constraints with getUserMedia. Surprisingly I found the resolutions that were returned were sometimes different than what you ask for, even if you make your constraints mandatory. Firefox didn’t support programmable video resolution constraints at all.

That was a while ago, so earlier this summer I checked my getUserMedia camera resolution finder again. This time Chrome 36 passed all my tests:

Ask Chrome 30 Chrome 36
1280×720 pass: 1280×720 pass: 1280×720
960×720 pass: 960×720 pass: 960×720
640×480 pass: 640×480 pass: 640×480
640×360 fail: 320×180 pass: 640×360
320×240 pass: 320×240 pass: 320×240
320×180 fail: 160×88 pass: 320×180

Constraint handling has clearly changed, but how? I could not find any coherent documentation on this, so I decided to update my resolution scanning code and re-run my analysis to empirically determine how mandatory constraints are handled.  If you choose to read-on below, you’ll see much has been fixed, but there are still a few nagging issues. ...  Continue reading

Newer note: February 2016 update here.

Note: Behavior has changed with latest versions of Chrome (v35+). Please see my update to this post here.

{“editor”, “chad“}

I have a confession to make about my WebRTC Motion Detecting Baby Monitor – the video quality was inconsistent and poor on the baby side of my original demo video, so I swapped out my old HTC Thunderbolt for another laptop in the 2nd half of the video. The stream and motion processing consumes a full core on my 2 GHz Intel i7 laptop processor. Fortunately I have more cores there, but this would clearly be a problem for a lot of devices – both in terms of having enough CPU to meet the application’s demands and on battery life. There are also bandwidth concerns in the real world. I was am running everything over WiFi, so I was not too concerned about bandwidth, but there is no reason why one should not be able to run this on a LTE or 3G network where there are bandwidth constraints and data plan usage concerns. ...  Continue reading