Microsoft DV codec: new version

[Brian Ellis]

Joachim Vollmar sent me a copy of the qdv.dll codec included in the beta DirectX 9.

I unzipped it, checked it was v. 6.5.1.80, and renamed my DirectX v 8 codec v. 6.3.1.881 to qdv.dl8. I then copied in the new qdv.dll to ...\system 32.

I captured a 4 min clip of a theme park by night which I shot in Brunei a couple of years back (lots of contrast and movement). No drops, perfect synch. I added a rolling test title using Times New Roman (some letters have their serifs coming to a point and will artifact like hell in some circumstances). I then rendered it to a new file and recorded it back onto a DV tape. Everything worked fine but I quite frankly could see no improvement. Just to check, I was going to do the same by reverting to 6.3.1.881, when I saw the codec had 224 kb and not the 303 kb it should have had.

Bugger me if DirectX 8 hadn't reinstalled its own codec! Just to check, I actually tried to deleted the old one and it didn't delete: it appeared to, but lurked in the background until I tried to install the new one, when it reappeared, despite that I have Full Control Permissions allowed. Mystery.

Anyway, nothing to report

[Rob100]

Sounds like WFP (SFC) kicking in. Not sure what OS you use, but this may be useful info... Now I remember there being a problem with Win2K SP2 and WinXP, but there are workrounds which I have done and worked, but that was about 1 yr ago and I can't recall...


Addendum 7:37pm 6/24/00 At End

6:13am 6/24/00

Summary: Undocumented registry setting allows for
Windows File Protection (aka System File Checker)
to be fully disabled.

HowTo: Set the SFCDisable value (see Q222473) to
0xffffff9d.

Ok, after spending 6 hours in the guts of sfc.dll, sfcfiles.dll,
and winlogon.exe I have *finally* discovered how to permanently
disable windows file protection. The more I dug into the internals
of SFC, the more I began to think that it would not be as easy as
I first thought it would be - and indeed Microsoft does not want it
to be easy. Windows File Protection, while annoying, does provide
a good degree of system stability and even some level of virus/trojan
protection by preventing system files from being modified without
at least notifying the user. Therefore, I was *very* shocked when
I was looking through a disassembly of sfc.dll and came to the code
that checks the value of the SfcDisable in the WinLogon key.
I see in the code of ordinal 1 (which is the initialization function
that winlogon calls), sticking out like a sore thumb, this:

76986A89 push 1
76986A8B cmp eax, ebx
76986A8D pop esi
76986A8E jz loc_76986B97
76986A94 cmp eax, esi
76986A96 jz loc_76986B7A
76986A9C cmp eax, 2
76986A9F jz loc_76986B69
76986AA5 cmp eax, 3
76986AA8 jz short loc_76986AE0
76986AAA cmp eax, 4
76986AAD jz short loc_76986ACF
76986AAF cmp eax, 0FFFFFF9Dh
76986AB2 push ebx
76986AB3 jz loc_76986B86
76986AB9 push offset byte_76981898
76986ABE push edi
76986ABF call sub_7698877D
76986AC4 mov dword_769901D4, ebx
76986ACA jmp loc_76986B97

Ok, values 0, 1, 2, 3, and 4 are documented at
http://support.microsoft.com/support.../Q222/4/73.ASP , but
what the heck is this 0ffffff9dh value that it accepts?! As you can
see, any value other than 0,1,2,3,4 and 0ffffff9dh are assumed to be
zero, which is the default of SFC enabled with popups enabled. So,
without further delay, I went and plugged 0ffffff9dh into the SfcDisable
value to see what was up. Rebooted. I'll be darned, Microsoft provided
a very,very simple way to fully disable WFP!

When booting with this value in the SFCDisable value in the WinLogon
key (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon), an
event is written to the system log, ID 64032 from Windows File
Protection, with the description:
"Windows File Protection is not active on this system. ".

All attempts to replace/delete protected system files succeeded,
just as if I were in safe mode . I rebooted a few more times and
verified that it is the one value (other than 4=popus disabled) that
is not reset to 0 after the first boot.

Needless to say, this is not what Microsoft intended.

Well, it's now 6am, hopefully I haven't mucked this up too much in
my delerium.

Jeremy Collake
collake@charter.net

http://www.collakesoftware.com

Addendum 7:37pm 6/24/00:
SFCDisable value 3 was not documented like I thought it was. This
value performs some check for setup.exe or sfctest.exe. WFP does
appear to end up enabled. Have not had a chance to look into it further.

[Brian Ellis]

Thanks, Rob. Looks like you've put your finger on the nail you've hit on the head . Looking in Q222473, it is clear that a kernel debugger is needed to do anything and a) it is not worth the candle to go to those lengths just to try a codec; b) although I've done a lot of high level language programming, I'm totally incompetent at low level messing around with codes; c) I don't wish to bugger up the system completely

Notwithstanding, I feel that a simple registry value would have been sufficient to provide the file protection and, as I well understand the utility of this for real system files, it seems a stretch to call a codec a system file, even if it is in the \system 32 directory.

[Michel Carleer]

Brian,
If I remember correctly the W2K WFP system compares files in the system32 folder to the copies in system32\dllcache (hidden folder) at bootup. If a difference is found for a file, it is simply copied back from system32\dllcache.
The solution to circonvent the problem is of course to first copy the new version of the codec to system32\dllcache before overwriting (or replacing) it in system32.
I believe WXP works the same way.

[Brian Ellis]

Bonjour, Michel

T'es un génie!

Yup! Michel's advice worked, so I got the new codec installed.

I captured with the new codec exactly the same footage as yesterday with the old codec and added an identical title (no problems). I wasn't exactly impressed with a great visual difference. I therefore took both the new and the old files into MSP 6.5. I put the old one into Va and the new one into Vb and synchronised them exactly (no problem, to a millisecond over the 243 second clip). I then chopped 10 second slices out of Vb, so that it alternated between the two with 12 slices of each. I created a new file from this. On playback, I could detect absolutely zero visual difference at the changeovers (identical artifacts), but there was a distinct audible difference. I'm not able to say whether the old or the new was better than the other, but they were distinctly different. As I said yesterday, I chose a theme park clip for the trial and you know what the sound quality is like at these places, especially as it was recorded by the on-camera mikes. Unfortunately, I don't have any DV originals with good enough quality sound, for an objective appreciation as to whether the new one is better than the old.

Now we know it's possible and the new codec does work with DirectX 8.1, someone else with some superb sound on DV tape can judge it better. I know you guys with all your Turtle Beaches must be rarin' to go to try it out with their super Hi-Fi surround systems

Summary: I don't think with a single very difficult trial that anything has changed video-wise, but audio-wise something has to justify the extra 75 kb of dll!

[Michel Carleer]

Brian,
Thank you so much.
The solution to this problem was rather simple. If the file is overwritten regularly, then a safeguard copy must reside somewhere else on the HD. Just find where.
Which means either of two things:
- Either you are very literate (is this correct? I mean you know quite a lot of things in the PC science and technology) and then you need to be a real genius to discover the simple and easy solutions.
- Or you are simply too dumb to think about anything else than simple solutions, and then your job is quite easy.
Guess in what category I think I am?

[Brian Ellis]

Michel

I agree that some form of backup must have been there, but not necessarily under the same name. If you do Search, it won't come up with the answer, because the backup is in a hidden directory.

BTW, it does not do the comparison just at boot-up but apparently at any time that the dll is called for. I should imagine it could be a real bugger if the dllcache file of any dll became corrupt: you could spend a long time tracing it.

I'm category really thick and dumb

[Jerry Jones]

Thanks for your information! Very interesting indeed.

Of course, the jury will still be out until the final DirectX 9.0 is available for download.


Jerry Jones

http://www.jonesgroup.net

[Michel Carleer]

Brian, are you sure about the hidden folders?
I don't have W2K here at home, but can't you ask to also scan hidden files and folders? In WXP it is an option under "More advanced options".
It could also have been compacted in a cab file somewhere (like in Driver Cache for example).
I did not know about file checking at every dll call, but it indeed makes sense.

[Indiana]

In Win2k this option is missing but it does find the files in dllcache even though it's a hidden folder (I just checked here, Win2k SP2).

Windows really does check those files at runtime, I remember I had to do this trick once (first copy the replacement file in the dllcache, then into system32) when DX8 final came out and some people found out that the Radeons T&L performance was much higher after overwriting one of the DX8.0 final files with a version from the last Beta.

[Michel Carleer]

Thanks for the info, Indiana.