Last Comment Bug 833314 - honour user defined format and frame rate
: honour user defined format and frame rate
[getUserMedia] [blocking-gum-]
Product: Core
Classification: Components
Component: WebRTC: Audio/Video (show other bugs)
: unspecified
: All All
P3 normal 35 with 1 vote (vote)
: ---
Assigned To: Randell Jesup [:jesup]
: Jason Smith [:jsmith]
: Maire Reavy [:mreavy] Please needinfo me
Depends on: 846188
  Show dependency treegraph
Reported: 2013-01-22 05:42 PST by jonathan chetwynd
Modified: 2015-05-20 03:22 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image jonathan chetwynd 2013-01-22 05:42:57 PST
currently Firefox forces format 640x480 30fps

see webRTC bug:

Suggestion: browser should honour user defined format and frame rate.
possibly subject to camera providing given format and frame rate, 


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


    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 in browser

    check format and frame rate again:
      $ v4l2-ctl --all  // ie did they change?

    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:
Comment 1 User image Randell Jesup [:jesup] 2013-01-31 03:14:14 PST
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.
Comment 2 User image jonathan chetwynd 2013-01-31 13:28:00 PST
#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.
Comment 3 User image Dainius 'GreatEmerald' 2015-05-16 13:54:27 PDT
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.
Comment 4 User image Gian-Carlo Pascutto [:gcp] 2015-05-19 05:40:07 PDT
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?
Comment 5 User image Dainius 'GreatEmerald' 2015-05-19 05:58:06 PDT
What are the mentioned settings called, then?
Comment 6 User image Gian-Carlo Pascutto [:gcp] 2015-05-19 08:43:53 PDT

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.
Comment 7 User image Dainius 'GreatEmerald' 2015-05-19 10:44:57 PDT
Ah, thanks. Changing these does indeed change which resolution is used (I'm testing it on, 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.
Comment 8 User image Gian-Carlo Pascutto [:gcp] 2015-05-19 11:19:58 PDT
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).
Comment 9 User image Dainius 'GreatEmerald' 2015-05-20 03:22:18 PDT
OK, opened bug #1166664 for that.

Note You need to log in before you can comment on or make changes to this bug.