currently Firefox forces format 640x480 30fps see webRTC bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20733 Suggestion: browser should honour user defined format and frame rate. possibly subject to camera providing given format and frame rate, afaict There is currently no defined way to negotiate the video format A camera may offer a variety of formats and frame rates The user may have chosen a desired format and frame rate The browser may auto-select a format and frame rate Evidence: Method: set format and frame rate:** $ v4l2-ctl --set-fmt-video=width=320,height=240 //320x240 $ v4l2-ctl --set-parm=60 //60fps $ v4l2-ctl --all // check current settings load http://www.gnote.org in browser check format and frame rate again: $ v4l2-ctl --all // ie did they change? Results: Chrome v24.0.1312.52 format is changed to 640x480 user defined fps is retained Opera v12.12.1707 user defined format is retained fps is changed to 25fps Firefox 21.0a1 (2013-01-21) format is changed to 640x480 fps is changed to 30fps Tests were not exhaustive, it may be helpful to have other tests, particularly using a UVC compliant camera my apologies if I missed something obvious. ~:" ** v4l2 is a Linux API to control camera output v4l2-ctl provides an interface to this API Camera: Sony Eye Camera available formats: 640x480@15 640x480@30 640x480@40 640x480@50 640x480@60 320x240@30 320x240@40 320x240@50 320x240@60 320x240@75 320x240@100 320x240@125
Instead of requiring users to use v4l configs, we will be supporting dynamic resolution and framerate control based on bandwidth in PeerConnections, and constraints-based support for resolution and framerate for getUserMedia(). Details of how defaults will be handled have not yet been set.
#1 Randell, No requirement for users to use v4l2 was suggested or implied. afaict your comment does not address this bug as stated in the summary and description. perhaps you could elaborate? ie in respect of meeting the users chosen method to define frame rate and format? which may for example be v4l2 whilst bandwidth is clearly a constraint, it does not elucidate the relation between frame rate and format, which the author and user will need to control, as this is directly dependent on purpose.
Yes, a way to configure the initial webcam settings (via v4l2 tools or otherwise) is quite important. Nowadays 1080p webcams are a reality, with internet bandwidths also being sufficient for streaming such, so being forced into 640x480 without any note or warning is quite unfortunate. Dynamic control of it would be nice indeed, but perhaps in the mean while user-set settings should be taken into account? Some things, like the aspect ratio, will have to be taken into account regardless, I believe.
We support getUsermedia constraints now, and those drive what frame size / frame rate ends up being selected. You can see this in the bug linked in the original comment which is now RESOLVED FIXED with a reference to the spec. There's also settings in about:config to control the defaults if the webpage doesn't request anything specific. So I think this has been RESOLVED FIXED for a while already?
What are the mentioned settings called, then?
media.navigator.video.default_width media.navigator.video.default_height media.navigator.video.default_fps But note that, as already explained above, the *webpage* that requests the camera usage should define what format it desires via constraints (and it's free to ask the user what values he deems appropriate or select good default based on the purpose of the page). Those settings just define what happens if it says "give me video, I don't care what size" which isn't going to be the case you want to be in.
Ah, thanks. Changing these does indeed change which resolution is used (I'm testing it on appear.in), though not which pixel format. It seems to prefer MJPEG (although the default 0x0 results in it selecting 640x480 YUV, not any of the MJPEG ones), and for me that always results in nothing but a green flickering frame, but I suppose that's a separate issue.
Yes, please file with as much details as possible (platform)? Preferring MJPEG sounds wrong because YUV should be faster to convert to the I420 that the video encoder uses (but it's entirely possible that at HD rates the camera forces MJPEG due to USB bus bandwidth constraints, or something).
OK, opened bug #1166664 for that.