833314 - honour user defined format and frame rate

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect, P3)

Description

[jonathan chetwynd]

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

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

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

[jonathan chetwynd]

#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

[Dainius 'GreatEmerald']

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

[Gian-Carlo Pascutto [:gcp]]

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

[Dainius 'GreatEmerald']

What are the mentioned settings called, then?

Comment 6

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 7

[Dainius 'GreatEmerald']

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.

Comment 8

[Gian-Carlo Pascutto [:gcp]]

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

[Dainius 'GreatEmerald']

OK, opened bug #1166664 for that.