GNOME Bugzilla – Bug 626515
[windows] Cannot see the video on my computer, error 2289434884 (DDERR_NOOVERLAYHW)
Last modified: 2014-04-01 16:13:43 UTC
Hello, when I try to use webcam to see my image on Ekiga I got this error: "There was an error opening or initializing the video output. Please verify that no other application is using the accelerated video output." I have an integrated Creative webcam (seen as USB webcam from system, driver version is 1.3.2.919) on a Dell E6400 Laptop running Windows7. I can use the webcam with other software, also when I try to use it with Ekiga I can see the webcam state led lighted (that means that webcam is in use), and also the dimension of the Ekiga screen changing when I try to switch several resolutions from Preferences.
Please send us the -d 4 output (see http://wiki.ekiga.org/index.php/Debugging_Ekiga#Debugging_Ekiga_on_Windows) so that we can have more information. So you do not see the image from your camera, is that right?
Hello, yes, I can't see the image from the camera. I submitted ekiga-stderr as requested, you can check it at http://pastebin.ca/1915167
The error is at line: DirectX CreateSurface(Overlay) failed - 2289434884 and the error code 2289434884 means DDERR_NOOVERLAYHW (2289434884 in base 10 is 88760104 in base 16; you need to remove 8 and 876, cf. http://source.winehq.org/source/include/ddraw.h#L79, and you obtain 0x104, i.e. 260 in base 10, which is the code for DDERR_NOOVERLAYHW, cf. http://source.winehq.org/source/include/ddraw.h#L113). I do not have video card knowledge, but it seems the problem is that your video card does not have a hardware overlay, or it is not available. Maybe trying using software acceleration (in conf file, modify general->user_interface->video_display->disable_hw_accel)? Finally, note that your image goes to your party, it is that you cannot show the video on your own screen.
One user (Dave Koelmeyer) tried with: <applyto>/apps/ekiga/general/user_interface/video_display/disable_hw_accel</applyto> <type>bool</type> <default>true</default> and it still did not work. I wonder if upgrading win32/directx directory does not solve this issue, but I do not know where it should be grabbed from.
*** Bug 655029 has been marked as a duplicate of this bug. ***
Upgrading win32/directx has no effect.
Could you execute dxdiag and see if something interesting is shown in Display tab?
*** Bug 690517 has been marked as a duplicate of this bug. ***
*** Bug 689002 has been marked as a duplicate of this bug. ***
Created attachment 231992 [details] Same test as ekiga to investigate the failure I created a small program which makes the same test as ekiga, in the hope someone sees where the problem is. Compile it on GNU/Linux using mingw-w64 with: i686-w64-mingw32-g++ test-overlay.cpp -lddraw afterwards copy the .exe together with libgcc_s_sjlj-1.dll and libstdc++-6.dll in some directory on a Windows machine, execute it and see if it shows success or failure. I also put all these files at http://eugen.dedu.free.fr/winoverlay
*** Bug 695872 has been marked as a duplicate of this bug. ***
Someone pointed to me that this might be because your machine has an nvidia optimus video card. Can all people subscribed to this bug tell if this is the case for him?
No, I experience this problem on AMD Radeon card.
kje, are you sure that it is the same bug, i.e. error 2289434884 in the log?
@Eugen - yes, exactly the same error in the log. Graphics card is AMD Radeon(TM) HD 6630M.
hi , i am the "Someone" mention befor. Kje can you tell us : - if your pc is a laptop - the precise model of your graphical card, if it use a technology wich is the AMD equivalent of the nvidia optimus one it will make sense.
@martin - yes, I tested it on a laptop today. But earlier I experienced exactly the same defect on a desktop pc. Graphics card model is AMD Radeon(TM) HD 6630M.
Created attachment 240495 [details] DxDiag alienware M11x
Yes, on my laptop (alienware M11x) I have Optimus graphics. Added my DxDiag above.
J. Berta's idea was that some machines have two video adaptors: one with GPU and hw acceleration, and one without. Intel Optimus is such an example. The goal is to use the one without hw acceleration for each program in order to decrease energy used, except if the program specifies that it needs such acceleration through some mechanism. See http://en.wikipedia.org/wiki/Nvidia_Optimus#Method_of_function for ex. Needs more investigation.
Created attachment 245400 [details] DxDiag lof for Intel HD GFX
Created attachment 245401 [details] Debug log Intel HD GFX - no video preview
I'm seeing the same problem on a Dell Latitude E5410 laptop with inbuilt cam. Video preview window comes up blank. Logs attached. Tested with Ekiga 4.0.1, but older versions also show this behaviour
MS test tool here: http://msdn.microsoft.com/en-us/library/windows/hardware/hh998978.aspx
I was able to download the 'display compliance test' here: http://www.microsoft.com/en-eg/download/details.aspx?id=31874 Although the quoted command did not work, I ran the following and manually selected 'API Test Cases/API_CreateSurf' -- c:\DCT_II\Common\DDRAW\General>Fnddraw_dct -- Results attached, which all look OK. One thing I did not, my previous log shows that Ekiga is quoting a refresh rate, where the DCT is spec'ing 0. -- 2013/05/27 10:42:45.320 0:18.008 ekiga VidInputCore Starting preview 176x144/30 -- Perhaps this is related?
Created attachment 245404 [details] API_CreatSurf results
Created attachment 245407 [details] results from C:\DCT_II\Common\VMR\VMRSurfaceTest.exe This actually shows the majority for pixel formats failing (ie. not supported).
Just to be clear in my analysis of the problem. It would appear that Ekiga is initialising a colour space converter to drive the display/preview -- ekiga PColCnv PColourConverter constructed: YUY2:CIF@25/Scaled -> YUV420P:CIF@25/Scaled -- Apparently 'YUV420P' is 'YV12' in MS speak (http://msdn.microsoft.com/en-us/library/ms788178%28VS.85%29.aspx). From the VMRSurfaceTest we can see that this format is not supported by my video driver -- Create Surface checking DDraw Format: YV12 DDraw Format: YV12 is NOT Supported -- Therefore Ekiga should re-try/attempt to convert the incoming stream (from camera or other) to another format which is supported. In my particular situation 'YUY2' _is_ supported, so why would we need a conversion to be done at all?
Looks like the format for the video overlay is hard coded to be 'YV12': https://github.com/ceyusa/ekiga/blob/master/lib/gui/dxwindow.cpp#L285 I do not have the ability to compile Ekiga for windows, but if someone wants to switch this for another (supported) format I can confirm that this is the root of the problem on my laptop. Hopefully the code can be further enhanced to re-try different formats on failure.
Your analysis seems very useful. I can change the format and send you an .exe with the format you wish. As I am not specialist on video formats, could you tell me what is the difference between those formats? Does a card support only some of them? Do you have an idea on why in ekiga *that* format was used? Does changing the format have an incidence on other computers?
I'm no expert either.... I assume that Ekiga uses YV12 either because it used elsewhere in the system (what's RTP's native format?) or that it's just what worked for the original author. As noted in the logs above these are the overlay formats which work with my GFX driver (Intel HD) -- Create Surface checking DDraw Format: RGB 5:6:5 Successfully created DDraw surface with this format, Create Surface checking DDraw Format: YUY2 Successfully created DDraw surface with this format, Create Surface checking DDraw Format: UYVY Successfully created DDraw surface with this format, Create Surface checking DDraw Format: AYUV Successfully created DDraw surface with this format, -- This page (http://msdn.microsoft.com/en-us/library/ms788178%28VS.85%29.aspx) describes the format, ie how colour information is encoded. If the encoding is wrong/mis-matched it probably doesn't matter, test will be useful if I get any video preview. If you can build and stick the file somewhere (dropbox/etc) I'll give it a try. I think I only need the libekiga.dll (~2.2MByte).
Ok, I will provide you shortly a full exe with those formats.
I probably shouldn't be editing 'libekiga.dll' by hand, but if I change 'YV12' (59 56 31 32) to 'YUY2' (59 55 59 32) in a hex-editor I now get a nice green image (and no error) when starting the preview. :-) -- 2013/05/28 13:46:38.714 0:04.117 ekiga VidInputCoreConfBridge Updating preview 2013/05/28 13:46:40.627 0:06.031 GMVideoOut...nager:1984 GMVideoOutputManager_dx Opening :VO_MODE_LOCAL display with image of 176x144 2013/05/28 13:46:40.628 0:06.031 GMVideoOut...nager:1984 DirectX DXWindow Constructor called 2013/05/28 13:46:40.628 0:06.031 GMVideoOut...nager:1984 DirectX Configuring DirectX 2013/05/28 13:46:40.627 0:06.031 ekiga VidInputCore Starting preview 176x144/30 2013/05/28 13:46:40.673 0:06.076 GMVideoOut...nager:1984 DirectX Creating Primary Surface 2013/05/28 13:46:40.673 0:06.076 GMVideoOut...nager:1984 DirectX Creating Bacbuffer Surface 2013/05/28 13:46:40.673 0:06.076 GMVideoOut...nager:1984 DirectX Creating Overlay Surface 2013/05/28 13:46:40.675 0:06.078 GMVideoOut...nager:1984 DirectX Creating Clipper 2013/05/28 13:46:40.675 0:06.078 GMVideoOut...nager:1984 DirectX Showing Window 2013/05/28 13:46:40.675 0:06.078 GMVideoOut...nager:1984 DirectX SetWindow - 0,59 352x288 2013/05/28 13:46:40.675 0:06.078 GMVideoOut...nager:1984 DirectX Getting the window coordinates 2013/05/28 13:46:40.675 0:06.078 GMVideoOut...nager:1984 DirectX new Embedded Coordinates: -1224,138 - -872,426 -- So I think we're on the right track. A nice prebuilt binary would be great...
I put three .exe at http://eugen.dedu.free.fr/win. 1 is original, 2 is with yuy2, and 3 is with original, and if failure change to yuy2 (automatic change). We are on the right track indeed!! With 1 I have no image. With 2 and 3 I have a greenish image cut in half where I however see my face moving!! I will look into the code tomorrow, but do you have an idea why the image is not normal? It seems that function CopyFramceBackbuffer is related, https://git.gnome.org/browse/ekiga/tree/lib/gui/dxwindow.cpp#n686. (Sorry, I have not yet looked at all your comments, not enough time)
Created attachment 245502 [details] debug log using '-3' variant Thanks for those; they work as expected: '-1' no image shown, log reports error '-2' solid green image '-3' solid green image and notes in the debug log -- 2013/05/28 16:18:47.547 0:09.868 GMVideoOut...nager:6444 DirectX CreateSurface(Overlay) failed - trying YUY2 - 2289434884 -- The solid green image is most likely as the stream of data is not what we're claiming it to be. For some reason bad data tends to just display green. Further up the debug log it says the convertor is still set to outputting YUV420P, this must be somewhere else in the code base. If we're going to try mutliple video formats perhaps this stream needs to be set up after we know what the GFX driver can support. -- 2013/05/28 16:18:45.402 0:07.723 ekiga PColCnv PColourConverter constructed: YUY2:CIF@25/Scaled -> YUV420P:CIF@25/Scaled --
Just realised why it's 'solid green'; Laptop is closed in dock and Ekiga is using built in camera, using external web cam (on monitor) shows green and pink image of me... D'oh!
Are you still working on a solution? I can still reproduce this bug on my Dell Latitude E6430 with Windows 7 and ekiga 4.1.0. I affirm the results of Simon Wood with the 3 test-versions. Does one need this convertion?
Simon Wood's analysis is good. I will fix it as soon as I have some time. The file to be fixed is https://git.gnome.org/browse/ekiga/tree/lib/gui/dxwindow.cpp, line 285, and 681 and the following. I made a test using IMC4, but it seems that the copy was not good, because I had a distorted image. The change was the following: /* for (i = 0 ; i < height ; i += 2) { memcpy (dstY, srcY, width); dstY += ddSurfaceDesc.lPitch; srcY += width; memcpy (dstY, srcY, width); dstY += ddSurfaceDesc.lPitch; srcY += width; memcpy (dstV, srcV, width2); dstV += lPitch2; srcV += width2; dstU += lPitch2; srcU += width2; } */ // from IMC4 to YUY2 for (i=0 ; i<height*width ; i+=2) { if (i%width == 0 && (i/width)%2 == 1) { // si debut de colonne et 2eme, 4eme etc. ligne if (i%width == 0 && (i/width)%2 == 1) { // si debut de colonne et 2eme, 4eme etc. ligne srcU -= width/2; srcV -= width/2; } *dstY = *srcY; dstY++; srcY++; *dstY = *srcU; dstY++; srcU++; *dstY = *srcY; dstY++; srcY++; *dstY = *srcV; dstY++; srcV++; /* if (i%4) { srcU++; srcV++; } */ }
I will fix this bug next week.
Finally fixed with https://git.gnome.org/browse/ekiga/commit/?id=138930947. I plan to make a new stable release including also this fix in maximum one week. In the meantime, you can use http://eugen.dedu.free.fr/videook.exe, which I use for debugging. Special thanks to Simon Wood for finding out the issue.
Yep, that works for me... I'm now in glorious technicolour ;-) Regarding thanks, you're welcome. Thanks for fixing it, Simon.
(In reply to comment #40) > Finally fixed with https://git.gnome.org/browse/ekiga/commit/?id=138930947. I > plan to make a new stable release including also this fix in maximum one week. > In the meantime, you can use http://eugen.dedu.free.fr/videook.exe, which I use > for debugging. Thanks for the fix. However, please note that the link to the binary no longer works. There is also no new release available for download on main Ekiga site.
(In reply to comment #42) > Thanks for the fix. However, please note that the link to the binary no longer > works. There is also no new release available for download on main Ekiga site. There is! 4.0.1+ from http://wiki.ekiga.org/index.php/Installing_Ekiga_on_Windows was released mainly for this purpose (fix for this bug).
From Frédéric Jouault: "overlays seem to be deprecated in Windows 8, and disabled by default. A workaround to enable overlays is to create the following registry value: [HKEY_CURRENT_USER\Software\Microsoft\Direct3D\Shims\EnableOverlays] "C:\\Program Files (x86)\\Ekiga\\ekiga.exe"=dword:00000001 as seen on: http://forum.ventrilo.com/showthread.php?t=69659 http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/d3c684b0-37ac-4a52-ba08-464b8dae4433/overlay-mixer-seems-to-be-broken-in-windows-8?forum=windowsdirectshowdevelopment" Note that next release will not use overlays anymore, but clutter library.