![]() In this quick demo I just used the 6 resolutions identified above. You can check it out yourself here: and see the code here: For more on what this fingerprint could look like I suggest checking out this Electronic Frontier Foundation site.įortunately using the techniques above it is possible to determine what camera resolutions are available in Chrome by simply trying all six resolution options and seeing what is returned. Looking through the W3C mailing list, it looks like this was suggested but dropped due to concerns about using this information to help further fingerprint users based on their hardware. This is helpful for testing but has limits the kinds of applications where you could make use of changing video resolutions.Īn API for discovering possible camera resolutions sure would be nice. You can however manually set the default parameters in the about:config preference selections under media: Firefox about:config settings for getUserMedia() Don’t bother changing constraints in Firefox todayįireFox as of 24.0 does not support the video resolution constraints. Chrome for Andriod requires permissions for every getUserMedia() call, even on https. Fortunately the https option allows constraints to be changed more seamlessly, at least in the desktop version. ![]() In most situations dropping the stream and then the user for permission repeatedly will not generate a good experience. If you select Allow on a "https" URL, your preference will be remembered in future visits. If you select Allow on a "http" URL your preference will not be remembered in future visits. The object, as defined in the getUserMedia() W3C specification looks like this:Īllow : This allows the site to access your camera and microphone at this time and a notification will appear confirming that you' ve granted access. I discovered this is not as straight forward as one would think, so I am posting my observations here.Īs covered in the What happens when there’s missing media sources? post, getUserMedia() takes a constraints object. This got me experimenting with getUserMedia() constraints to see what affect adjusting the source resolution and framerate has on CPU utilization and bandwidth consumption. 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. There are also bandwidth concerns in the real world. 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. The stream and motion processing consumes a full core on my 2 GHz Intel i7 laptop processor. 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 2 nd half of the video. Note: Behavior has changed with latest versions of Chrome (v35+).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |