hi, any response?

Please let us know what supported formats are reported for your camera in the Video tab at chrome://media-internals/ (camera needs to have been initialized/used after Chrome startup for this to populate).

attached pdf

Deleted: Media Internals.pdf 127 KB

Media Internals.pdf 127 KB Download

In general, Chrome does support cameras sending Mjpeg.
I just tested with a Logitech C920, which reports the same supported formats as your C922. I can get smooth looking 30fps at 1920x1080 when testing on https://webrtc.github.io/samples/src/content/getusermedia/resolution/ 

Could you give the above link a try as well on your system and let me know what you find?

please try the "HD" button on this link (1280x720) in my case
it gives only 10fps, although like you have reported above
1920x1080 gives me 30fps

let me know if you also get same experience like myself.
thanks!

Tried with both a C920 and a C930e. Both work fine on my Windows laptop at both HD and Full HD. While testing, I noticed that for the C930e, at first, switching from Full HD to HD, the website ended up switching from the C930e to the laptop internal camera. I fixed that by going to the content settings in Chrome and selecting the C930e as default.

so the webrtcp resultion sample link reveals the same result like recorded before using my own application.

i prepare for you another recording, showing all modes in c922.
you will notice everything works smoothly BESIDE 'HD' mode (1280x720).

recording ->
http://www.maspick.co.il/records/c922HD10fps.webm

conclusion:

A. it is not hardware issue, the cameras works perfectly with native windows 10 apps such as XSplit (demonstrated in above recording) BUT using MJPG compression.

B. chrome 'HD' need instant fixing for c922 and perhaps other modern cameras as well. c920 you had been testing is an older less modern camera (2-3 years old model i believe).

C. remote p2p webrtc sessions
Certainly i would not want to force users to stream to remote users using "Full HD" for webrtc p2p video sessions camera capture as it takes too much of bandwidth with very few advantage over 'HD', most of users can not use such high bandwidth conditions especially if you add also screen share in parallel.

many many thanks
Danny  

Difficult to say what is causing this. I will need to reproduce this locally and add some debug logs to see more of what is going on. I assume your theory is that Chrome for some reason opens the camera in YUV mode, leading to a low frame rate.

I have ordered a C922, which should arrive later this week. Will post an update as soon as I get my hands on it.

thanks, looking forward to hear from you soon

Got the camera this morning.
The reported issue reproduces on my laptop. 720p comes out at too low of a frame rate while 1080p works as expected.

I am going to dig into this and see what I can find.

Analysis of what is happening:

The list of supported formats as reported in chrome://media-internals shows 
720p @ 30Hz. This is what gets requested when opening the camera.
The code that handles the request now tries to find the best match against 
a more detailed list of formats supported by the camera. As opposed to the list 
that can be seen in media-internals, this list differentiates between pixel 
formats, in this case YUV2 and MJPEG. In this more detailed list, there are two
entries for 720p which are
1. 10fps via YUV2 and
2. 60fps via MJPEG. 
The code selects 10fps, because the absolute difference to the requested 30fps 
is samller than for 60fps.

Even though it is questionable that selecting 10fps is better than 60fps if 
30fps was requested, it seems the root of the problem is that the list of 
supported formats exposed to the Web client is inconsistent with the list that 
the device code uses to make a final decision.

In addition to that, it seems problematic that in the detailed list, 720p with 
MJPEG does not appear with lower fps than 60.

I will start working on fixing these things. 

Since this is not a regression, I don't think this will warrants a merge into 
M60 stable, and will probably also not meet the bar for a merge into M61 beta.
Let's see how the fix works out first, and then we can check with the release 
owners whether or not they feel it should be included in the respective 
milestones.

very interesting indeed.

i can reassure you that 720p (30/60 fps) mode is most wanted & preferred webrtc camera p2p desire. so this bug fixing / enhancement really is most wanted feature for webrtc users! it will truly upscale the webrtc experience for users who want to use chrome for their online video meetings.

many thanks
Danny

hi, any updates with this fix ?

I created a local patch that consolidates the logic that creates the lists of supported formats. With that, the frame rate for 720p for the C922 now gets listed as 60 fps, and when opening https://webrtc.github.io/samples/src/content/getusermedia/resolution/ and choosing HD, I do get 60 fps.

However, this is probably not what we really want. I believe what we do want is to have all supported frame rates for each resolution get listed as supported. Currently there is logic in place that filters out all frame rates except the highest one. This may have made sense in the past where it may have been a sound assumption that the user always wants the highest supported frame rate. But with cameras supporting 60fps, this is probably no longer the case.

I will continue by testing what happens if we list all supported frame rates, and if nothing breaks because of it, I will put the patch up for review.

guidou@, mcasas@: Are you aware of any reasons why we should not list all supported frame rates?

guidou@: I'm not aware of the historical reasons not to list all supported frame rates. I think all of them should be listed. The application can use constraints to control which mode is selected.
If no constraints are given, getUserMedia selects the mode with area closest to 640x480 and frame rate closest to 30Hz.

guidou@: While we are already discussing exposing more detailed lists of supported formats ... is there any Web exposed constraint for selecting which pixel format a capture device should deliver? Besides I420, there can be Y16 for depth cameras. But if a single capture device were to offer both I420 and Y16 at the same resolution and frame rate, with today's code, only one of the two would show up in the list of supported formats. If the JavaScript side can select the desired format, then we probably want to make sure we list both formats in such cases.

chfremer@: there isn't any constraint for selecting pixel format. I guess the way to go is to propose one. Can you file an issue in https://github.com/w3c/mediacapture-main/issues ?

Just not to run out of my bug context,

using 1080 mode (30 or even 60 fps) isn't possible for smooth webrtc p2p sessions, as it occupy too much bandwidth, comparing to a 720p capture. because of the only pick of 10fps we are forced to downgrade to lower resultion (VGA -640x480px) in order to gain the wanted 30/60fps experience hence users who invested on better equipped hardware such as c922 users can not actually take care of their advance cameras.
IMHO this doesn't make too much sense to hold to the existing support of formats, perhaps in the past it was the best choose, not any more.

many thanks

Code review is up: https://chromium-review.googlesource.com/c/611183

With the change, 720p @ 30fps is working on the C922. And other fps including the 60 fps should work when requested via the getUserMedia constraints. Here is what the list of supported formats on chrome://media-internals shows before/after the change:

C922 Pro Stream Webcam (046d:085c)

Before:
resolution  fps storage
160x90  30.00 CPU
160x120 30.00 CPU
176x144 30.00 CPU
320x180 30.00 CPU
320x240 30.00 CPU
352x288 30.00 CPU
432x240 30.00 CPU
640x360 30.00 CPU
640x480 30.00 CPU
800x448 30.00 CPU
864x480 30.00 CPU
800x600 30.00 CPU
1024x576  30.00 CPU
960x720 30.00 CPU
1280x720  30.00 CPU
1600x896  30.00 CPU
1920x1080 30.00 CPU
2304x1296 2.00  CPU
2304x1536 2.00  CPU

After:
resolution  fps storage
160x90  30.00 CPU
160x90  24.00 CPU
160x90  20.00 CPU
160x90  15.00 CPU
160x90  10.00 CPU
160x90  7.50  CPU
160x90  5.00  CPU
160x120 30.00 CPU
160x120 24.00 CPU
160x120 20.00 CPU
160x120 15.00 CPU
160x120 10.00 CPU
160x120 7.50  CPU
160x120 5.00  CPU
176x144 30.00 CPU
176x144 24.00 CPU
176x144 20.00 CPU
176x144 15.00 CPU
176x144 10.00 CPU
176x144 7.50  CPU
176x144 5.00  CPU
320x180 30.00 CPU
320x180 24.00 CPU
320x180 20.00 CPU
320x180 15.00 CPU
320x180 10.00 CPU
320x180 7.50  CPU
320x180 5.00  CPU
320x240 30.00 CPU
320x240 24.00 CPU
320x240 20.00 CPU
320x240 15.00 CPU
320x240 10.00 CPU
320x240 7.50  CPU
320x240 5.00  CPU
352x288 30.00 CPU
352x288 24.00 CPU
352x288 20.00 CPU
352x288 15.00 CPU
352x288 10.00 CPU
352x288 7.50  CPU
352x288 5.00  CPU
432x240 30.00 CPU
432x240 24.00 CPU
432x240 20.00 CPU
432x240 15.00 CPU
432x240 10.00 CPU
432x240 7.50  CPU
432x240 5.00  CPU
640x360 30.00 CPU
640x360 24.00 CPU
640x360 20.00 CPU
640x360 15.00 CPU
640x360 10.00 CPU
640x360 7.50  CPU
640x360 5.00  CPU
640x480 30.00 CPU
640x480 24.00 CPU
640x480 20.00 CPU
640x480 15.00 CPU
640x480 10.00 CPU
640x480 7.50  CPU
640x480 5.00  CPU
800x448 30.00 CPU
800x448 24.00 CPU
800x448 20.00 CPU
800x448 15.00 CPU
800x448 10.00 CPU
800x448 7.50  CPU
800x448 5.00  CPU
864x480 30.00 CPU
864x480 24.00 CPU
864x480 20.00 CPU
864x480 15.00 CPU
864x480 10.00 CPU
864x480 7.50  CPU
864x480 5.00  CPU
800x600 30.00 CPU
800x600 24.00 CPU
800x600 20.00 CPU
800x600 15.00 CPU
800x600 10.00 CPU
800x600 7.50  CPU
800x600 5.00  CPU
1024x576  30.00 CPU
1024x576  24.00 CPU
1024x576  20.00 CPU
1024x576  15.00 CPU
1024x576  10.00 CPU
1024x576  7.50  CPU
1024x576  5.00  CPU
960x720 30.00 CPU
960x720 24.00 CPU
960x720 20.00 CPU
960x720 15.00 CPU
960x720 10.00 CPU
960x720 7.50  CPU
960x720 5.00  CPU
1280x720  60.00 CPU
1280x720  30.00 CPU
1280x720  24.00 CPU
1280x720  20.00 CPU
1280x720  15.00 CPU
1280x720  10.00 CPU
1280x720  7.50  CPU
1280x720  5.00  CPU
1600x896  30.00 CPU
1600x896  24.00 CPU
1600x896  20.00 CPU
1600x896  15.00 CPU
1600x896  10.00 CPU
1600x896  7.50  CPU
1600x896  5.00  CPU
1920x1080 30.00 CPU
1920x1080 24.00 CPU
1920x1080 20.00 CPU
1920x1080 15.00 CPU
1920x1080 10.00 CPU
1920x1080 7.50  CPU
1920x1080 5.00  CPU
2304x1296 2.00  CPU
2304x1536 2.00  CPU

can you provide a download link for binary including this patch (win64 exe) for testing ?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8d5627c41dac13bffda1741cfc9b578c7fafd093

commit 8d5627c41dac13bffda1741cfc9b578c7fafd093
Author: Christian Fremerey <chfremer@chromium.org>
Date: Sat Aug 12 03:15:11 2017

[Video Capture, Windows] List all supported frame rates instead of just highest

Before this CL, there were two almost identical code paths for obtaining a list
of supported capture formats from a device on Windows. One path was used for
reporting a simplified list (only one frame rate per resolution) of supported
formats to JavaScript clients as well as device and format selection logic. The
other path was used for deciding at the device-level which actual format to use
based on an incoming request.

This CL consolidates the two code paths into one, so that the same list of
supported format is output in both cases.

Bug: 750431
Change-Id: I232f72c1c98fb22e0e2408eee889fb3f2c590590
Reviewed-on: https://chromium-review.googlesource.com/611183
Commit-Queue: Christian Fremerey <chfremer@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493950}
[modify] https://crrev.com/8d5627c41dac13bffda1741cfc9b578c7fafd093/media/capture/video/video_capture_system_impl.cc
[modify] https://crrev.com/8d5627c41dac13bffda1741cfc9b578c7fafd093/media/capture/video/win/video_capture_device_factory_win.cc
[modify] https://crrev.com/8d5627c41dac13bffda1741cfc9b578c7fafd093/media/capture/video/win/video_capture_device_win.cc
[modify] https://crrev.com/8d5627c41dac13bffda1741cfc9b578c7fafd093/media/capture/video/win/video_capture_device_win.h

The change has landed and can be tested in Canary builds starting with 62.0.3184.0. Please let me know if it works with your configuration.

hi,

1. webrtc resolution sample works smoothly 720p on canary - great!
2. however unfortunately something broke with canary webrtc video P2P streaming camera/mic permissions with regard of the RTCPeerConnection demos who need access to the camera/mic for permissions are currently not longer working at all with our canary testings. 
so sadly i can not test it with real-time p2p webrtc sessions till feature owner will fix this serious permission issue on canary.

many thanks

if you not able not run those RTCPeerConnection demos perhaps we should somehow report this permission bug to the feature owner ?

Thanks for testing. I filed https://bugs.chromium.org/p/chromium/issues/detail?id=755248 for the issues with accessing the video.

danny@: Assuming the issue with the permissions is fixed in the latest Canaries, did you have a chance to verify the fix is working for your use case?

chfremer@:

we have tested webrtc getUserMedia() in latest canary Version 62.0.3188.0 
with following constrains

width: {
  ideal: 1280,
  max: 1920
},
height: {
  ideal: 720,
  max: 1080
},
frameRate: {
  ideal: 60,
  max: 60
}

and found that webrtc doesn't respect those conditions of 60 fps despite the fact that camera (922) DOES offcourse 60 fps.

and also we have tried to use "exact" instead of "ideal" and we got the same result - which is very strange cause to our understanding, it should result with failed media stream if it can not provide exact same specified fps, but for some reason it returns the media with same 30 fps.

interestingly with

frameRate: {
  min: 60,
  max: 60
}

we manage to simulate the "exact" behavior of 60 fps and get required media stream.

dannymendelmn@: Can you provide some examples with the exact constraint strings you have given to getUserMedia and the result of invoking getSettings() on the video track contained in the MediaStream returned by getUserMedia?

dannymedelmn@: Also, please provide the output of the "Video Capture" section of chrome://media-internals so that we can manually compare constraints against the video modes reported to Chrome.

I have tried with a C920 and C930e, but neither of them reports 1280x720@60Hz (or any mode with 60Hz) as a supported mode on Linux, so I cannot reproduce dannymedlmn@'s problem.

chfremer@ on
Comment 15 you wrote you got the c922 and test it. do you still need my output?
if so attached 

Deleted: Media Internals.pdf 165 KB

Media Internals.pdf 165 KB Download

dannymendelmn@: thanks for the output.
Can you try with https://jsfiddle.net/guidou/q4mLuhbt/ and see what output do you get?
Feel free to update the script to replace exact with min, ideal or any other constraint strings that provide unexpected results.

test results in attached ideal.png and exact.png
i would expect with frameRate: {ideal: 60,max: 60} to have 60fps stream and not 30fps as resulted in the testing (as camera support 60fps as we know)

Deleted: ideal.png 91.0 KB

	ideal.png 91.0 KB View Download

Deleted: exact.png 101 KB

	exact.png 101 KB View Download

dannymedelmn@:

You are right that ideal:60 should give you 60fps if it's available.
I don't have a C922 available for testing, but will try to find out what the problem is.
If you can, please use the jsfiddle in #37 to try to report more unexpected results.

guidou@:

my testings reveals that using ideal:60 brings actual 24fps on c922 on following resolutions:
1280x720x24fps
640x360x24fps
320x180x24fps
(webrtc-internals: googFrameRateInput = 24)

instead of expected c922 following specs:
1280x720X60fps
640x360x30fps
320x180x30fps

guidou@: Any updates on your investigation?
Since I have a C922 available, I can take another look at this.

No updates, due to lack of hardware.
Please take another look with your C922.

I tested the constraints algorithm using fake device entries based on the modes provided by dannymendelmn@gmail.com and it returned the expected values, so something else might be going on.

1. chfremer@: can you verify that you as c922 owner like me gets same result?

using ideal:60 brings actual 24fps on c922 on following resolutions:
1280x720x24fps
640x360x24fps
320x180x24fps
(webrtc-internals: googFrameRateInput = 24)

instead of expected c922 following specs:
1280x720X60fps
640x360x30fps
320x180x30fps

2. i have a strong belief that this bug may be common to all latest/modern logitech cameras such as 
4K PRO WEBCAM, 
Pro Webcam,
BRIO,
C930E WEBCAM,
C925e WEBCAM

and might be also interesting to compare with 2years old webcam such as
HD Pro Webcam C920

so perhaps it will be nice to test more devices, as i suspect the bug effect much wider circles of usage not just the c922 owners.

thanks

re #44: I am on it. What do you use to get webrtc-internals to populate while being able to pass custom constraints to getUserMedia?

use
1. go with latest canary to https://webrtc.github.io/samples/src/content/peerconnection/constraints/
2. provide one of the following width/height for both min/max values
1280x720 or 640x360 or 320x180
3. use min/max framerate of 60fps
4. click "get media" + "connect"
5. open another chrome tab with chrome://webrtc-internals/
6. locate the capture streaming active tab (with highest number)
7. locate "ssrc_xxxxxxx_recv (ssrc)" (xxx will be dynamic identifier)
8. locate the googFrameRateDecoded / googFrameRateOutput / googFrameRateReceived	
in my c922 case it is ~23/24fps instead of expected 60fps

attached pics


test
chrome://webrtc-internals/

Deleted: 2017-09-16 01_11_27-.png 85.4 KB

	2017-09-16 01_11_27-.png 85.4 KB View Download

Deleted: 1.png 21.5 KB

	1.png 21.5 KB View Download

Thanks, that is a good way of testing.

I tried with my C922 on the latest canary and I get 30fps when requesting 60fps.
I confirmed that the frame_rate [1] that is requested from the DirectShow code is 60. It looks like all of the Chromium-side code "believes" that 60fps is being used, but for some reason DirectShow only delivers 30fps back to it.

Interesting that you are getting 24fps with the same settings. Not sure what the difference is here.