http://bugs.winehq.org/show_bug.cgi?id=13194
Summary: Gordian Knot unable to open codec settings dialog Product: Wine Version: 1.0-rc1 Platform: PC-x86-64 URL: http://sourceforge.net/projects/gordianknot OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvfw32 AssignedTo: wine-bugs@winehq.org ReportedBy: emwine@earthlink.net
Created an attachment (id=13019) --> (http://bugs.winehq.org/attachment.cgi?id=13019) testcase source and exe
Install Codec Pack (for XviD), and rippack for GK. Run, go to options tab, click "First Pass" under XviD default codec settings. Nothing. Same with other codecs and "Codec settings" when trying a compressibility test.
GK is open source, but in pascal. So I created a small testcase in VC++ 6.0 using the same technique. Testcase relies on XviD as opposed to other codecs.
I'm not 100% sure that XviD (and other codecs) are properly registered so that the technique ought to work. But I think the problem is not codec registration. Also, I guessed at the component.
http://bugs.winehq.org/show_bug.cgi?id=13194
Eric Mullins emwine@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
http://bugs.winehq.org/show_bug.cgi?id=13194
--- Comment #1 from Eric Mullins emwine@earthlink.net 2008-05-13 12:40:58 --- The GK codec pack is a lot of baggage when all you need is XviD for the tests. The latest winetricks supports XviD installation. I'd recommend that or just: http://download.videohelp.com/download/Xvid-1.1.3-12042008.exe rather than the whole codec pack.
http://bugs.winehq.org/show_bug.cgi?id=13194
--- Comment #2 from Juan Lang juan_lang@yahoo.com 2008-05-13 16:35:11 --- First off, does your test app work in Windows?
I downloaded your test app and used winetricks to install xvid.
I then ran WINEDEBUG=msvideo,driver wine codec.exe, and this is a partial log of what I see:
trace:msvideo:ICOpen (VIDC,XVID,0x00000000) trace:driver:OpenDriver (L"VIDC.XVID", L"drivers32", 0x0033fe08); trace:driver:DRIVER_GetLibName registry: L"VIDC.XVID", L"drivers32", 0x33fbb6, 522 trace:driver:DRIVER_TryOpenDriver32 (L"xvidvfw.dll", 0033FE08); (snip) trace:driver:DRIVER_TryOpenDriver32 (L"xvidvfw.dll", 0033FE08); trace:driver:DRIVER_SendMessage Before call32 proc=0x10006d20 drvrID=00000000 hDrv=0x1287d8 wMsg=0003 p1=00000000 p2=0033fe08 trace:driver:DRIVER_SendMessage After call32 proc=0x10006d20 drvrID=00000000 hDrv=0x1287d8 wMsg=0003 p1=00000000 p2=0033fe08 => 00000000 trace:driver:DRIVER_AddToList DRV_OPEN failed on driver 0x1287d8
The After line (the next to the last line) indicates that the return value from this DRIVER_SendMessage call is NULL, which winmm thinks is a failure:
233 lpNewDrv->d.d32.dwDriverID = DRIVER_SendMessage(lpNewDrv, DRV_OPEN, lParam1, lParam2); 234 235 if (lpNewDrv->d.d32.dwDriverID == 0) 236 { 237 TRACE("DRV_OPEN failed on driver %p\n", lpNewDrv); 238 return FALSE; 239 }
So either this is a xvid bug, or this initialization process in Wine is flawed.
http://bugs.winehq.org/show_bug.cgi?id=13194
--- Comment #3 from Eric Mullins emwine@earthlink.net 2008-05-13 17:50:30 --- (In reply to comment #2)
First off, does your test app work in Windows?
Yes. I tested it on both a Virtual XP, and a real win2000 machine.
Also, I didn't discover until after my report that using native msvfw32.dll solves the issue within wine. (both the testcase and GK work proplerly with native msvfw32.dll)
http://bugs.winehq.org/show_bug.cgi?id=13194
--- Comment #4 from Austin English austinenglish@gmail.com 2008-11-12 14:28:49 --- Is this still an issue in current (1.1.8 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=13194
--- Comment #5 from Eric Mullins emwine@earthlink.net 2008-11-14 18:57:58 --- (In reply to comment #4)
Is this still an issue in current (1.1.8 or newer) wine?
Yes, the bug persists. It's easy to duplicate and show it's a wine bug using the attached exe.
Was there reason to believe it magically got fixed?
http://bugs.winehq.org/show_bug.cgi?id=13194
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords| |download
--- Comment #6 from Austin English austinenglish@gmail.com 2008-11-15 04:03:22 --- Confirming.
http://bugs.winehq.org/show_bug.cgi?id=13194
Luke Benstead kazade@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kazade@gmail.com
--- Comment #7 from Luke Benstead kazade@gmail.com 2009-08-16 13:37:20 --- Still present in 1.1.27
http://bugs.winehq.org/show_bug.cgi?id=13194
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #8 from Jörg Höhle hoehle@users.sourceforge.net 2011-04-16 03:55:12 CDT --- There are reasons to believe this is (again) a case-sensitivity issue. I did not try out the mentioned apps, but looked at the xvid.org source DRV_OPEN : if (icopen != NULL && icopen->fccType != ICTYPE_VIDEO) // 'vidc', not 'VIDC' return DRVCNF_CANCEL; // NULL Juan Lang's trace snippet in comment #2 shows that VIDC (upper case) is being used to attempt to open the driver, but it wants a lower case "vidc".
dlls/msvfw/tests/mvfw.c demonstrates that ICOpen is case-insensitive (at least with msvideo now, iccvid originally). Back then we changed both ICOpen and the lower-level Wine drivers to be case-insensitive. However, I since found out that at a lower-level, there's case-sensitivity involved. IIRC, ICLocate is case-sensitive, oddly I find no mention of my test in my copious notes. So there's still work to be done to exactly mimic native behaviour.
Meanwhile, you can check whether c:/windows/system.ini and [HKLM\Software\Microsoft\Windows NT\CurrentVersion\Drivers32] contain lower-case mention of vidc only, i.e. is this an installation issue? I suspect the codec will open if you manage to see lower-case 'vidc' in msvideo:ICOpen and driver:OpenDriver, driver:DRIVER_GetLibName traces.
You may wish to hack msvideo_main.c:ICOpen to force VIDC to vidc to verify my hypothesis. if (fccType == mmioFOURCC('V', 'I', 'D', 'C')) fccType=ICTYPE_VIDEO;
BTW, I'm thankful for any pointers to open source MCI or audio drivers (msacm or VFW drivers are not in my focus yet).
http://bugs.winehq.org/show_bug.cgi?id=13194
--- Comment #9 from Jörg Höhle hoehle@users.sourceforge.net 2011-04-21 15:58:36 CDT --- Created an attachment (id=34273) --> (http://bugs.winehq.org/attachment.cgi?id=34273) ICOpen case-insensitivity, revisited
Please try out this patch to ICOpen and report back.
http://bugs.winehq.org/show_bug.cgi?id=13194
--- Comment #10 from Jörg Höhle hoehle@users.sourceforge.net 2011-09-07 03:08:00 CDT --- The case-sensitivity issue is fixed by commit 0e566c5b645572d6ce17cc05a1e815a93838a7f3 since wine-1.3.21. Sombody please check, report back or mark as fixed if appropriate.
http://bugs.winehq.org/show_bug.cgi?id=13194
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |0e566c5b645572d6ce17cc05a1e | |815a93838a7f3 Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #11 from Jörg Höhle hoehle@users.sourceforge.net 2013-03-02 17:12:39 CST --- I assume my patch fixed the FCC case-sensitivity issue in 2011. If the symptoms persist with the original app, please reopen.
http://bugs.winehq.org/show_bug.cgi?id=13194
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org 2013-03-15 14:46:11 CDT --- Closing bugs fixed in 1.5.26.
-
wine-bugs＠winehq.org