[cedocida 0.2.0] weird vfw problem

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

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.

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.

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!")

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.

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.