[cedocida 0.2.0] weird vfw problem

[coordz]

This isn't really a question about cedocida but getting a vfw codec working and in particular cedocida. I grabbed cedocida, installed using the inf file and then used gspot (list all codecs) to check the install. Gspot marks cedocida as a problem codec with the error that the DLL cannot be found. I checked that the codec is in system32 and that the registry was setup correctly - all seems to be in order. BUT if I then try to render a DV file using gspot's renderer rather than the MS A/V render option I am told the file was successfully rendered through cedocida :confused::confused: what gives?

1) does gspot "render" just by checking that a codec exists rather than actually using the codec?
2) why is cedocida.dll reported as not found?
3) can I verify the cedocida install another way?

many TIA

[cedocida]

Hi,
I do observe the same on my PC (Windows XP) with Gspot v2.2.1. Affected Codecs here are Cedocida 0.2.0. and VMnc v2 Codec.
Reason: totally unknown
At least for Cedocida 0.2.0 I don't know about Bugs concerning Installation and System integration. I am using it for encoding and decoding within VirtualDub and Avisynth without any problems.
Maybe this answers your question No. 3.:
Start VirtualDub, goto Menu: Video->compression, it should appear in the selection box.

[stegre]

I can reproduce this, and am checking it now. As a preliminary guess I'd say it's more likely to be GSpot bug than a problem with anything in cedocida, so for now just ignore it as a spurious message and don't worry about anything. It's related to the interaction of cedocida .inf file and the registry entries it makes vs. some validity checks the GSpot is attempting to make by reading & cross referencing those entries; it doesn't have to do "codec itself", for what that's worth.

It is weird that the bug does not occur if the earlier version of the cedocida .inf installer is used, so I figured it'd be a snap to fix by setting a breakpoint on the line of code that generates the error message and just see what's different when I run one install versus the other, and I did just spend a few minutes doing just that.

But to my surprise, I found that when I run GSpot after using the older .inf installer, the GSpot code never even goes to part of the code that performs that check, so that's the only reason the old one "worked" - it wasn't even performing check.

It may be the case that newer .inf file, which is more comprehensive, adds appropriate extra info into the registry that allows GSpot to attempt to perform the check. So, ironically, it's quite possible that the new & improved .inf exhibits the error only because it's "better", and hence exposes some pre-existing GSpot bug.

Meanwhile, while checking into it, I noticed that GSpot reports errors with all codecs associated with Adobe's CS3 line of products, and those are all DirectShow codecs, not VFW; I'm pretty sure that's an unrelated problem. So I definitely have some work to do in this area; I haven't looked at this part of the code in quite some time; I think it needs a bit of a tune-up.

- Steve G (author, GSpot)

[stegre]

Andreas -

I finally got a chance to look at this in detail; I don't know what I was thinking that night I wrote the previous post :confused: , but almost everything I said in it is wrong.

The problem actually does reside in cedocida, and it's in the DLL, not the .inf. But the real culprit is Microsoft, with their ambiguous documentation. You programmed ICM_GETINFO handler the same way I would have, the "safe" way, assuming the worst - that they were giving you a pointer to a memory area which might be filled with garbage. So you cleared it all to zero, and then filled in every field except "szDriver", just as the documentation instructs.

But, apparently, when Microsoft said "The driver should fill all members of the ICINFO structure except szDriver" they really should have said "The driver should fill all members of the ICINFO structure and but not touch szDriver.

As you can see by the breakpoint I've set on your app, the pointer supplied points to a pre-initialized area structure where "szDriver" is already filled in correctly (as are two other fields, apparently, but I'd leave your code "as is" regarding those two; your code does fill them in "redundantly", but that's what is what the MS doc says you should do.)

But you should remove the memset(), as I did in the screen shot below. I tested this change and it does correct the problem. Although it seems like good programming practice to have that there, in this case


Apparently the structure is "pre-initialized", so there's no garbage to worry about, and...

It looks like you explicitly set every documented member except in ICINFO except szDriver, also making the memset() unnecessary (again, I realize it's normally good programming practice, because you never know when they might add to the structure in the future, but in this case it's a problem), and...
Most importantly, as I've described above - though they fail to mention it - szDriver is "pre-filled" in, and your memset destroys that szDriver information. Apparently your last version lacked the memset, which is why it worked

So I'd just comment out that memset() and that will fix the problem at hand, the problem where GSpot reports the codec as misconfigured and that the file is "missing".

Of course, GSpot has its own issues, the most obvious is that it categorizes your encoder as a decoder :rolleyes: . It just assumes VFW codecs do both and puts it in that category for historic reasons). I'll have to see if I can fix that up in the next version.

http://www.ftyps.com/unrelated/cedocida1.png

http://www.ftyps.com/unrelated/cedocida2.png

[squid_80]

A couple of weeks back I read all those pages in MSDN (ICGetInfo, ICINFO, ICM_GETINFO etc.) looking for a way to get the dll name of a codec from the handle returned by ICOpen. szDriver looked good but I gave up after reading that the codec is not required to fill it out upon receiving ICM_GETINFO. Now it seems like there's a good reason for this that wasn't mentioned anywhere - Stegre, based on what you've seen are you saying ICGetInfo reliably fills in the szDriver member correctly (ignoring cases where the driver wipes it out :))?
If so I think I just found a solution to avisynth's "avisource fails after too many avisource calls" problem.

Also what system did you do your testing on? XP? I can test XP-64 myself but I'd like to know what vista does (they obviously rewrote the vfw library - AVIFile didn't break itself!)

(and what kind of dumb stuff up by MS is this? Why not fill out the driver name AFTER the struct comes back from being filled out by the driver? It's like giving a remote control to a little kid and saying "Push anything you want, but NOT THE BIG RED BUTTON!")

[stegre]

Ha, that's funny, I once saw an old "Candid Camera" episode where they would leave patients waiting in a Doctor's waiting room, alone, with a table with like one magazine on it -- and also lying around was a small hand-held box with one big red button, labeled "Do not Press". Invariably, after a while, people would pick it up, examine it, and eventually press it, at which point it started beeping loudly (and couldn't be shut off!) The person would then look around frantically, often trying to hide it under pillows and stuff - it was hysterical...

But yes, that's exactly what I'm saying. From Gspot's perespective, I basically use around 3 or 4 lines of code, in this case something like:

ICINFO icinfo;
HIC handle = ICOpen("VIDC", "DVSD", ICMODE_QUERY);
ICGetInfo(handle, &icinfo, sizeof(icinfo));
ICClose(handle);

Apparently, the ICGetInfo() causes a call to the driver's ICM_GETINFO callback handler, and the end result is I get all the exact info the driver put in the structure, plus the szDriver member as well (assuming the driver didn't wipe it out ;) )

And you're 100% right, MS should have just added that szDriver info while it was "on the way back" to the app that called ICGetInfo(), i.e. GSpot, rather than before calling the driver's callback handler. Then this whole issue would never have occurred.

BTW, I'm glad you made me look at this again; seems the docs imply if I replace ICMODE_QUERY parameter in the ICOpen() call with either ICMODE_COMPRESS or ICMODE_DECOMPRESS, I'll theoretically get either a valid handle or a null handle depending on whether driver has the respective capability. So I could use that technique to differentiate codecs that encode, decode, or do both. Seems a bit unwieldy to have to "open" a driver multiple times to just to find out if it's a compressor or decompresser (jeez, you'd think one of the members of ICINFO would tell me that, if nothing else!). But at least that's a plan I can use to allow GSpot to distinguish the two and thus report cedocida as an encoder, not a decoder - fixing the GSpot issue I mentioned at the end of my previous post.

And yes, as a matter of fact I happened to do all the above testing on Vista [ultimate] (32-bit, not 64 though), so I can vouch for the fact that this all works on that platform.

I'm sure Andreas will pop in here shortly, and hopefully he'll be able to provide further confirmation from his perspective.

[Guest]

But at least that's a plan I can use to allow GSpot to distinguish the two and thus report cedocida as an encoder, not a decoder Forgive me if I'm slow or brain damaged here, but isn't it an encoder AND a decoder? You know, a codec?

[stegre]

Oh, sorry... looking at the original thread now, quite clearly that's correct... I've only used cedocida a few times and for some odd reason I was under the mistaken impression it was an "encode only" device. I stand corrected.

[cedocida]

Steve, many thanks for your findings.
I do fully agree to all your comments and the proposed fix for cedocida. I will release an update soon.