increase in getUserMedia NotReadableError |
|||||||
Issue descriptionI am seeing quite an increase in getUserMedia NotReadableError on appear.in. The overall increase comparing M65 and M66 is ~28% -- see gum-total.png There is no (significant) increase in errors on non-windows. Lookin only at Windows only shows a 38% increase. Splitting this up further (gum-windows10) shows that the error rate does not increase on Windows 7 and Windows 8 but the increase on Windows 10 is around 55%. It is somewhat unclear what would cause this. There were no significant changes to appearins getUserMedia usage during that time. This might not be an issue in Chrome itself but maybe the new Windows 10 release changed something in a way that makes NotReadableError (which is a hardware error) more likely?
,
Jun 5 2018
,
Jun 5 2018
,
Jun 5 2018
+ossu, grunell - are you aware of anything there?
,
Jun 8 2018
oh... NotReadableError also happens when another application is using the webcam. I would expect that to happen with equal likehood on all operating systems though and the change to catch that happened quite a while back
,
Jun 12 2018
Re #1/4: no significant change I'm aware of. Re #5: Yes, NotReadableError can happen for different reasons, not only hw error. I'm looking into this.
,
Jun 25 2018
Assigning to grunell@ based on #6
,
Jun 25 2018
I see this in our Chrome metrics, and that the majority of the failures are from video. Assigning to chfremer@ who has confirmed a change for video.
,
Jul 3
Happens on Windows 10 and 8, not Win7. We get the error when trying to use several different directshow video cameras. Chrome appears to still be working properly with newer/UVC driver video cameras. We have confirmed this issue happens in the latest released Chrome and in both 32 and 64 bit versions. We have also confirmed if you uninstall and reinstall previous release version 67.0.3396.79 the issue goes away using same PC's, same cameras, no other changes other than uninstalling current version of Chrome and re-installing older version. Note, the directshow video cameras are mostly Empia based chipset if you wanted to find a camera that can show the problem or I could supply you one for testing and or help you test.
,
Jul 3
re #11: Thanks, that is very helpful information. Just to confirm, you are seeing this issue starting with 67.0.3396.79 and any earlier release does not show the issue? The reason I am asking is that the original report reported an increase in M66 compared to M65. I will take a look at code changes that went into 67.0.3396.79 to see what could have caused such an increase. Please also note that M67+ has recently been switched from DirectShow to MediaFoundation based video capture for Windows SKUs that support it. To check if the issue you are seeing is related to this, could you do me a favor and on an affected system start Chrome with command-line flag --disable-features=MediaFoundationVideoCapture ? Could you also give some examples of concrete camera makes/models that you have seen the issue with?
,
Jul 3
Sorry for the numbering mistake in my previous reply. I was replying to Comment #9, not #11 :-). So I checked the code logs for changes from 67.0.3396.62 to 67.0.3396.79 [1], but nothing video capture related seems to be in that range. Also in the range from 67.0.3396.79 to 67.0.3396.87 [2] there seems to be nothing video capture related. Please check if --disable-features=MediaFoundationVideoCapture or --enable-features=MediaFoundationVideoCapture makes a difference. To check at runtime if DirectShow or MediaFoundation is getting used, please navigate to chrome://media-internals and check the API in the VideoCapture tab (this requires visiting any website that accesses or enumerates cameras in order to populate). [1] https://chromium.googlesource.com/chromium/src/+log/67.0.3396.62..67.0.3396.79?n=10000 [2] https://chromium.googlesource.com/chromium/src/+log/67.0.3396.79..67.0.3396.87?n=10000
,
Jul 4
Good Night. Issue happens with Pinnacle video Capture ( Dazzle ) and GetuserMedia getting video resolutions ( or setting resolutions values) in Firefox works correctly. With MediaFoundation Video through DOMException. Using DirectShow, video resolutions is obtained, and it works again. Is there some way to change it definitively? Best regards, same issue, same "code fight" from Colombia.
,
Jul 4
re #12: Thanks for confirming that the issue can be mitigated using command-line flag --disable-features=MediaFoundationVideoCapture. Unfortunately, there is no client-side configuration other than the command-line flag to disable the MediaFoundation. I'll have to make a server-side configuration change, and that may take a few days to roll out and propagate.
,
Jul 4
Regarding comment 10 and 11. This is Not an issue in version 67.0.3396.79 that is the version we rolled back to that works. The version after that is the one with issue.
,
Jul 4
The version that we were using that doesn't work is 67.0.3396.99. The version that does work is 67.0.3396.79. I will try the flags and report back
,
Jul 5
I can confirm that --disable-features=MediaFoundationVideoCapture fixes the issue on the legacy directshow/wdm cameras we tested. Also a correction to my post above, I'm not positive the non-working version was 67.0.3396.99 and will try to confirm 100% and post back. We also saw this issue when testing the Beta channel (68.something) and I will confirm that also.
,
Jul 5
Ok, more news... 3396.99 is broken by default... But as soon as you enter the --disable-features=MediaFoundationVideoCapture it then works. What is interesting is then even if you REMOVE the disable line it STILL continues to work with no issue. So, guessing something must be saved/updated in registry/settings when disable is entered that fixes it and even when the disable-feature is removed from the command line it continues to work... I can break it again if I specifically re-enable using the enable-feature switch but after I do a disable once then it doesn't matter if Chrome runs without the disable switch and it continues to work without issue
,
Jul 6
Thanks, Doug, for confirming and doing the extra testing. The reason you have seen inconsistent default behavior is most likely because I have already changed a server-side configuration flag to disable MediaFoundationVideoCapture on the stable channel. The --disable-features and --enable-features command-line just forces it manually and overrides whatever the server-side config says. Note, that on the Beta channel the flag is currently still enabled for 50% of users, so you may still see the issue there when not using any command-line flag. Could you provide me with a list of legacy directshow/wdm cameras you have tested? I will need to get my hands on one of those to diagnose the cause and work on a fix.
,
Jul 6
Ahh, makes sense. Also, glad to help - we have about 5000 customers that use video cameras so kind of important to us :) I tested several legacy cameras that use Empia DSP's. Most of these are dental intraoral cameras and dentistry moves slow so they are 5-10 year old usb cameras that are still standard definition... The empia chips (which is a camera ISP and USB 2.0 controller in a single chip is used in all of these cameras) and the Empia model number is 2860 with a few 2820. Note, empia has many newer chips/model numbers as well. As another note, these dental cameras typically have analog front ends because they implment a CCD with analog output that then goes into a A/D convertor which then ouputs the digital video to the digivial video input port of the empia ISP. And in directshow this means these cameras also have have a crossbar component if it matters. As far as getting a camera I could provide you a camera for testing if needed. Or if you jump on ebay and search for intraoral cameras they are many that are $50 or less and many of those use empia as well and I could help you identify one using an Empia if desired. My gut tells me its probably not "empia itself" but rather something to do with analog front end/procamp legacy directshow devices and for some reason Chrome was falling thru to try and use them with AVFoundation which doesn't support all the features directshow does - but that's a guess...
,
Jul 6
correction - MediaFoundation not AVFounddation - too much OSX programming this week...
,
Jul 9
re #19: Thanks for the additional infos. Yes, I would like to buy one of these cameras to reproduce and investigate. If you could point out one or two concrete models that can be found on ebay or amazon that would be greatly appreciated. I also think this is probably not specific to empia, but could be something like the driver enumerating the device via MediaFoundation but not fully supporting it. We have a fall-back path for devices that only support DirectShow to still use DirectShow, but for some reason this does not seem to work as expected for these devices.
,
Jul 9
Oh, and one more question: Do the devices you tests with run on Windows 10 or is this an older version of Windows?
,
Jul 9
Both, W8.1 and w10. Best regards, Oscar.
,
Jul 10
Please note that, because the issue reported in the original report of this issue tracker entry is different from the MediaFoundation issue reported in posts #9 and below. I have created a new issue tracker entry for the MediaFoundation issue. Please post any further discussion of the MediaFoundation issue over there at https://bugs.chromium.org/p/chromium/issues/detail?id=862395.
,
Jul 12
Regarding comment 21. I will send a list of ebay cameras this weekend when I return from traveling. Also as an update, yesterday (Wednesday) we had three offices call that were using 67.0.3396.99 (64 bit) and were still failing until we entered the command line switch to disable. You mentioned you had changed the server side for the Release channel but on these users PC's we had to enter the command line to get the cameras to work. It fixed all three customers by entering the command line.
,
Jul 12
So sorry to hear your clients are still affected by this. My understanding is that the server side configuration change should get picked up when the Browser is restarted. If the Browser has not been restarted since the configuration was rolled back, it will continue to use the problematic one until the next restart. I recommend trying restarting the Browser without adding any command-line flag first. If you come across any client where that does not fix the issue, please let me know.
,
Jul 18
Since not everyone is following bug 862395 , I'll post here as well. We have landed a fix for the MediaFoundation issue and merged it to M68. It is included in the latest Beta 68.0.3440.68. Doug, Oscar, could you do me a favor and check on the Beta with command-line flag --enable-features=MediaFoundationVideoCapture if everything now works as expected?
,
Jul 27
Sorry for the delayed response. We checked Beta 68.0.3440.75 and with no command line options it works properly with the older legacy directshow cameras. If I add the enable MediafoundationVideoCapture switch it doesn't work and we get error/no video. Hope that helps.
,
Jul 27
Thanks, Doug. Yes this feedback helps a lot. Sounds like the devices you are testing with still behave differently than the Pinnacle Dazzle that alaoui.rda@ tested on, and the fix we landed in 68.0.3440.68 does not seem to help with those devices. Could you provide me with the exact model/make of the device, and maybe also what it reports when navigating to the video tab in chrome://media-internals?
,
Jul 28
Hello Doug, A full screenshot of the tab described by chfremer@ in comment #29 would be tremendously helpful to us.
,
Jul 28
Comment 29 - the cameras are using an Empia 2860 USB camera controller and are using the drivers available on Windows Update. Comment 30 - Sure will do on Monday.
,
Jul 30
Checked the Empia 2860 camera on this website https://www.html5rocks.com/en/tutorials/getusermedia/intro/ The Release version of Chrome (no switches) works/displays live video using the Basic Demo. The Beta version of chrome with the switch doesn't display live video (black) but there are no errors in console.
,
Jul 31
Doug, don't forget the screenshot please :)
,
Jul 31
Screencap attached of testing Beta release with the command line switch and Empia 2860 based USB video camera- There were no errors - the warning was prior to clicking the button that starts the live stream from the camera so presumably is unrelated. This same website works with the Release version of Chrome (no command line switch)
,
Jul 31
p.s. If I wasn't clear the Release version streams video properly from the camera, the Beta version has a black image and no errors in console when using the command line switch.
,
Jul 31
,
Jul 31
Also, for comparison it might be useful to get a second version of that screenshot but with the flag disabled, just to see the difference between what DirectShow sees and what MediaFoundation sees.
,
Jul 31
Ok, will do.
,
Jul 31
Here ya go - screenshot of with and without the command line
,
Aug 1
Thank you Doug. Unlike the Dazzle, all video formats are listed in both implementations (DS and MF). According to https://www.linuxtv.org/wiki/index.php/Em28xx_devices, the Pinnacle Dazzle uses an EM2820 chip while intra oral cameras use EM2860. It could explain the difference of behaviour. There is already a camera blacklist [1]. chfremer@, could we blacklist Empia devices from MediaFoundation? [1] https://chromium.googlesource.com/chromium/src.git/+/master/media/capture/video/win/video_capture_device_factory_win.cc#54
,
Aug 1
re #40, Yes I thought about blacklisting as well, but there are a number of concerns with this approach: 1. We probably don't want to blacklist all Empia devices, since there are also newer devices, for which we probably do want MediaFoundation. 2. How can we identify the devices we want to blacklist? Are all devices using affected Empia chips guaranteed to use "Empia" as part of their display name or "2860" as part of their USB id? 3. Unless we understand how the affected devices behavior under MediaFoundation and why it causes the symptoms that Doug is reporting, there is a good chance that other types of devices could run into the same issue. I still think the best solution is to get an EM2860 and analyze the behavior. Are there still any devices with that chip being sold?
,
Aug 1
Re #41: Yes indeed. I didn't find an affordable intraoral camera with EM2860. So I ordered an EZCAP.TV 116 [1] which is equipped with an EM2860. I will receive it on Saturday. [1] https://www.amazon.fr/gp/product/B006QZ97DY/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
,
Aug 4
Just received the EZCAPT.TV 116. The device works perfectly with MF enabled without falling back to DirectShow. But it is named 2861, not 2860. So I guess it is not exactly the same chip ... So looks like we have to test the exact model that Doug is using to reproduce or we are going to hunt this bug forever. Doug, can you please tell us how to procure the device you are using?
,
Aug 4
EM2861 is an example of Empia MediaFoundation compatible chip. So we should not blacklist all Empia chips. Looks like the vendor id is always eb1a and product id 28xx [1]. I guess that 2860 is a deprecated chip, replaced with more recent ones. So to answer the point 2 in #41 about device identification, the token to blacklist would be eb1a:2860. [1] https://www.kernel.org/doc/html/v4.16/media/v4l-drivers/em28xx-cardlist.html
,
Aug 7
Sorry to bother you Doug. Can you please tell us how to acquire the device you are using? Can you give us the exact model to find it? We are a little stuck :)
,
Aug 10
We are testing a camera named DEXcam3 which has an Empia EM2860 in it. We have another named a Gendex GXC-300 which is same camera in different plastic, and there are many other dental cameras (Sota Claris i4d, Digital Doc Iris, etc...) that also use that chip. However, if you like I can arrange to loan you a camera with 2860 for testing.
,
Aug 13
Quick update. I ordered a ezcap156 which according to the description at the seller website was supposed to have a EM2860 chip. On Windows 10 the device would not show up in Chrome (neither DirectShow nor MediaFoundation) without installing a driver. After installing the driver downloaded from the ezcap website, the device shows up as eb1a:2861. So probably this also ends up being a newer model with a newer chip. The device shows up and lists resolutions using both MediaFoundation and DirectShow. Without having anything connected to the analog inputs (I don't currently have an analog video source for testing), on DirectShow I get some black and white stripes while on MediaFoundation I only get black. On Firefox, the device is selectable as well, but does not seem to work either. When switching to it from a previously selected built-in laptop camera using https://webrtc.github.io/samples/src/content/devices/input-output/, the last frame from the built-in camera stays frozen on the display.
,
Aug 13
re #46: Thanks, Doug, for offering to loan us a camera for testing. I am currently not sure anymore whether or not this would be worth your troubles. From your reports and tests we have learned that the devices do show up in MediaFoundation and do list supported formats, but fail when trying to open. If we wanted to add logic that detects this and then falls back to DirectShow, this would require us to open every single device in advance to test if they work, which is not an acceptable solution. Also, always retrying with DirectShow when opening with MediaFoundation fails seems like an unacceptably broad mitigation. At this point I am leaning towards blacklisting MediaFoundation use for devices reporting themselves as eb1a:2860 and eb1a:2820, and have these forcably fall back to DirectShow. Once we have that code in and if you could help us confirm that things work with all the cameras relevant to your use cases and customers, we can re-ramp the rollout of MediaFoundation and hope that we don't run into any other cameras/chips that need to be blacklisted in this way. How does that sound?
,
Aug 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0ba070fd460e84e89cabb8af7396f1e28b9ba513 commit 0ba070fd460e84e89cabb8af7396f1e28b9ba513 Author: Christian Fremerey <chfremer@chromium.org> Date: Tue Aug 14 23:04:29 2018 [VideoCapture, Windows] Blacklist certain legacy Empia chips for MediaFoundation Devices using certain legacy Empia chips appear to get listed and report valid formats in both DirectShow and MediaFoundation but only work in DirectShow when actually trying to open them. This CL adds a blacklisting mechanism that forces device models known to exhibit this issue to always get opened with DirectShow instead of MediaFoundation. Test: capture_unittests.exe --gtest_filter=VideoCaptureDeviceFactoryMFWinTest* Bug: 792640, 849636, 862395 Change-Id: Ia70d13a45eb49ed185f27630d0e544f3a484b6f2 Reviewed-on: https://chromium-review.googlesource.com/1174902 Reviewed-by: Emircan Uysaler <emircan@chromium.org> Commit-Queue: Christian Fremerey <chfremer@chromium.org> Cr-Commit-Position: refs/heads/master@{#583068} [modify] https://crrev.com/0ba070fd460e84e89cabb8af7396f1e28b9ba513/media/capture/video/win/video_capture_device_factory_win.cc [modify] https://crrev.com/0ba070fd460e84e89cabb8af7396f1e28b9ba513/media/capture/video/win/video_capture_device_factory_win_unittest.cc
,
Aug 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1abb14e34927da38b26ba3087dcb443847c641ac commit 1abb14e34927da38b26ba3087dcb443847c641ac Author: Christian Fremerey <chfremer@chromium.org> Date: Thu Aug 16 23:22:33 2018 [VideoCapture, Windows] Blacklist certain legacy Empia chips for MediaFoundation Devices using certain legacy Empia chips appear to get listed and report valid formats in both DirectShow and MediaFoundation but only work in DirectShow when actually trying to open them. This CL adds a blacklisting mechanism that forces device models known to exhibit this issue to always get opened with DirectShow instead of MediaFoundation. Test: capture_unittests.exe --gtest_filter=VideoCaptureDeviceFactoryMFWinTest* Bug: 792640, 849636, 862395 Change-Id: Ia70d13a45eb49ed185f27630d0e544f3a484b6f2 Reviewed-on: https://chromium-review.googlesource.com/1174902 Reviewed-by: Emircan Uysaler <emircan@chromium.org> Commit-Queue: Christian Fremerey <chfremer@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#583068}(cherry picked from commit 0ba070fd460e84e89cabb8af7396f1e28b9ba513) Reviewed-on: https://chromium-review.googlesource.com/1179241 Reviewed-by: Christian Fremerey <chfremer@chromium.org> Cr-Commit-Position: refs/branch-heads/3497@{#679} Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753} [modify] https://crrev.com/1abb14e34927da38b26ba3087dcb443847c641ac/media/capture/video/win/video_capture_device_factory_win.cc [modify] https://crrev.com/1abb14e34927da38b26ba3087dcb443847c641ac/media/capture/video/win/video_capture_device_factory_win_unittest.cc
,
Aug 21
Hello Doug, Thank you very much for your help. Christian committed a fix to beta channel that forces the Empia 2860 and 2820 to be used through DirectShow. Could you please verify that your devices work correctly with the latest Chrome Beta even when MediaFoundation is enabled?
,
Aug 23
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91 commit bd9bf68829a9392e3cb76960ae26d52cb1ccfd91 Author: Christian Fremerey <chfremer@chromium.org> Date: Thu Aug 23 00:38:14 2018 [Video Capture] Distinguish and log error cases Adds an enum for distinguishing which call sites trigger video capture errors. The goal of this work is to improve the UMA logging by differentiating various possible sources of error events. Doing so will help us better understand what error events contribute most to the high error counts and will help us better pinpoint causes for future changes in error counts. Design Doc: https://docs.google.com/document/d/1chso0ntOMecY7SfcrQzkHLuBAxO_oUwSpOhy1MrXAhc/edit?usp=sharing Bug: 849636, 876002 Change-Id: I02fcc8930ff7e66a15c91c4393bf9a280383902b Reviewed-on: https://chromium-review.googlesource.com/1180412 Commit-Queue: Christian Fremerey <chfremer@chromium.org> Reviewed-by: Robert Sesek <rsesek@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Reviewed-by: Mark Pearson <mpearson@chromium.org> Reviewed-by: Emircan Uysaler <emircan@chromium.org> Cr-Commit-Position: refs/heads/master@{#585336} [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/components/mirroring/browser/single_client_video_capture_host.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/components/mirroring/browser/single_client_video_capture_host.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/media/capture/desktop_capture_device.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/media/capture/desktop_capture_device_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/media/capture/fake_video_capture_stack.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/media/capture/frame_sink_video_capture_device.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/media/capture/frame_sink_video_capture_device_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/media/capture/screen_capture_device_android.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/media/capture/screen_capture_device_android_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/in_process_video_capture_device_launcher.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/service_video_capture_device_launcher.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/service_video_capture_device_launcher_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/service_video_capture_provider_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_browsertest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_controller.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_controller.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_controller_event_handler.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_controller_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_device_launch_observer.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_host.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_host.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_manager.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_manager.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_manager_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/browser/renderer_host/media/video_capture_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/content/public/browser/video_capture_device_launcher.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/content/android/screen_capture_machine_android.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/content/android/thread_safe_capture_oracle.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/content/android/thread_safe_capture_oracle.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/mojom/video_capture_types.mojom [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/mojom/video_capture_types.typemap [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/mojom/video_capture_types_mojom_traits.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/mojom/video_capture_types_mojom_traits.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/android/java/src/org/chromium/media/VideoCapture.java [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/android/java/src/org/chromium/media/VideoCaptureCamera.java [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/android/java/src/org/chromium/media/VideoCaptureCamera2.java [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/android/video_capture_device_android.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/android/video_capture_device_android.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/chromeos/camera_device_context.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/chromeos/camera_device_context.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/chromeos/camera_device_delegate.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/chromeos/camera_device_delegate_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/chromeos/mock_video_capture_client.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/chromeos/mock_video_capture_client.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/chromeos/stream_buffer_manager.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/chromeos/stream_buffer_manager_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/chromeos/video_capture_device_chromeos_halv3.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/fake_video_capture_device_factory.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/fake_video_capture_device_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/file_video_capture_device.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/file_video_capture_device_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/linux/v4l2_capture_delegate.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/linux/v4l2_capture_delegate.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/linux/video_capture_device_linux.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/mac/video_capture_device_avfoundation_mac.mm [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/mac/video_capture_device_decklink_mac.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/mac/video_capture_device_decklink_mac.mm [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/mac/video_capture_device_mac.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/mac/video_capture_device_mac.mm [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/mock_video_capture_device_client.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/mock_video_frame_receiver.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/video_capture_device.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/video_capture_device_client.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/video_capture_device_client.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/video_capture_device_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/video_frame_receiver.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/video_frame_receiver_on_task_runner.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/video_frame_receiver_on_task_runner.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/win/video_capture_device_mf_win.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/win/video_capture_device_mf_win.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/win/video_capture_device_mf_win_unittest.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/win/video_capture_device_win.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video/win/video_capture_device_win.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/media/capture/video_capture_types.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/services/video_capture/device_media_to_mojo_adapter.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/services/video_capture/public/cpp/receiver_media_to_mojo_adapter.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/services/video_capture/public/cpp/receiver_media_to_mojo_adapter.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/services/video_capture/public/mojom/receiver.mojom [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/services/video_capture/receiver_mojo_to_media_adapter.cc [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/services/video_capture/receiver_mojo_to_media_adapter.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/services/video_capture/test/mock_receiver.h [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/tools/metrics/histograms/enums.xml [modify] https://crrev.com/bd9bf68829a9392e3cb76960ae26d52cb1ccfd91/tools/metrics/histograms/histograms.xml
,
Aug 28
Reply to Comment 51 - Yes, both 2820 and 2860 cameras now work in the Beta version without the command line switch. regards, Doug
,
Aug 29
Thank you Doug. Could you test with the command line switch please?
,
Sep 5
The cameras work on Beta channel with no command line switch, they work with disable (disable-features=MediaFoundationVideoCapture) and they also with enable (enable-features=MediaFoundationVideoCapture) command line switche. regards, Doug
,
Sep 11
I am getting "NotReadableError: Could not start audio source" if audio sample rate is set below 22050 Hz in Canary Version 71.0.3548.0.
Chorme version 69.0.3497.81 works fine.
chrome://media-internals/ output...
[
{},
{
"29:1": {
"channel_layout": "STEREO",
"channels": 2,
"component_id": 1,
"component_type": 1,
"device_id": "default",
"device_type": "pcm_low_latency",
"effects": "NO_EFFECTS",
"frames_per_buffer": 256,
"owner_id": 29,
"sample_rate": 22050,
"status": "started",
"render_process_id": 8,
"web_contents_title": "Facility One"
},
"30:2": {
"channel_layout": "STEREO",
"channels": 2,
"component_id": 2,
"component_type": 1,
"device_id": "default",
"device_type": "pcm_low_latency",
"effects": "NO_EFFECTS",
"frames_per_buffer": 256,
"owner_id": 30,
"sample_rate": 22050,
"status": "started",
"render_process_id": 8,
"web_contents_title": "Facility One"
}
},
{
"29:7": {
"channel_layout": "STEREO",
"channels": 2,
"component_id": 7,
"component_type": 2,
"device_id": "AppleUSBAudioEngine:Dictaphone Corporation:PowerMicII-NS:14523100:2,1",
"device_type": "pcm_low_latency",
"effects": "NO_EFFECTS",
"frames_per_buffer": 256,
"owner_id": 29,
"sample_rate": 22050,
"status": "started",
"volume": 1
},
"30:8": {
"channel_layout": "STEREO",
"channels": 2,
"component_id": 8,
"component_type": 2,
"device_id": "AppleUSBAudioEngine:Dictaphone Corporation:PowerMicII-NS:14523100:2,1",
"device_type": "pcm_low_latency",
"effects": "NO_EFFECTS",
"frames_per_buffer": 256,
"owner_id": 30,
"sample_rate": 22050,
"status": "started",
"volume": 1
}
}
]
,
Sep 11
Thanks for the report, vela1606. Can you please file a new bug for this, as this bug is video related? Den tis 11 sep. 2018 05:20vela1606 via monorail < monorail+v2.4221089365@chromium.org> skrev:
,
Sep 15
Sure!
,
Oct 9
We had a user call today that is on Windows 10 and was previously working until they updated to Chrome Version 69.0.3497.100 (64-bit) and the empia based camera stopped working with errors (same issue above in this thread with Empia ISP) - had tech support add the Disable Media Foundation switch and it works again - so looks like something has changed in 69.0.3497.100 build of Chrome that was just released versus previous stable/release channel build.
,
Oct 9
re #59: Thanks, Doug for the report. The timing coincides with us re-activating the Media Foundation switch by default on M69 yesterday. It is not related to the version, but a restart of Chromium, which also happens when updating to a new version. Any chance you could have your customer check the output of the video tab in chrome://media-internals? Probably, there is another Empia ID that was not yet covered by our blacklist. We need that information in order to update the blacklist for the devices the show problems.
,
Oct 10
reply to comment 60 - yes we got the VID/PID of that camera yesterday - it is an Empia 2820 device but uses their own VID/PID. The VID/PID that should be added/blacklisted (in addition to the Empia default you alredy added) is VID ICE6 and PID 2820. See attached screencap. Thanks! Doug
,
Oct 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6854025abb6278daaa3258117cf8c796ec46bba8 commit 6854025abb6278daaa3258117cf8c796ec46bba8 Author: Christian Fremerey <chfremer@chromium.org> Date: Thu Oct 11 20:46:32 2018 [Video Capture, Win] Update blacklist for MediaFoundation This CL adds a new entry to the blacklist as per new report from https://bugs.chromium.org/p/chromium/issues/detail?id=849636#c61 TBR=emircan@chromium.org Bug: 792640, 849636, 862395 Change-Id: I47a36dce54993f93059fd833f0ca5ea074037339 Reviewed-on: https://chromium-review.googlesource.com/c/1277589 Commit-Queue: Christian Fremerey <chfremer@chromium.org> Reviewed-by: Christian Fremerey <chfremer@chromium.org> Cr-Commit-Position: refs/heads/master@{#598921} [modify] https://crrev.com/6854025abb6278daaa3258117cf8c796ec46bba8/media/capture/video/win/video_capture_device_factory_win.cc
,
Oct 17
Hi, God bless I've found this bug report, I was going mad because of my Elgato HD60 Pro not working anymore on my web app! Using the flag disable-features=MediaFoundationVideoCapture on latest Chrome Beta makes it work again. I've attached a screenshot with device ids and the Media Internals log. Thanks!
,
Jan 3
re #63: Thanks for the report and the model info. I am going to update the blacklist accordingly.
,
Jan 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/95410acf37c2f3cea4b47833bb7c2ed3ebfe519a commit 95410acf37c2f3cea4b47833bb7c2ed3ebfe519a Author: Christian Fremerey <chfremer@chromium.org> Date: Thu Jan 03 17:19:49 2019 [Media Foundation Video Capture] Add Elgato HD60 Pro to Blacklist As per new report on crbug.com/849636, this device seems to be another instance of drivers reporting the device as available in MediaFoundation but not actually working with it. Bug: 849636 Change-Id: I21764713826e4f86cf600e6e30b75a3d9c3fb087 Reviewed-on: https://chromium-review.googlesource.com/c/1393804 Reviewed-by: Weiyong Yao <braveyao@chromium.org> Commit-Queue: Christian Fremerey <chfremer@chromium.org> Cr-Commit-Position: refs/heads/master@{#619667} [modify] https://crrev.com/95410acf37c2f3cea4b47833bb7c2ed3ebfe519a/media/capture/video/win/video_capture_device_factory_win.cc |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by guidou@chromium.org
, Jun 5 2018