Missing codecs, but videos play anyways.

[benedict]

I'm looking at two short video clips, one an AVI file and the other an ASF file: The FourCC code on the AVI file is "mpg4", and on the ASF file it's "mp43". I have neither of these codecs installed on my computer. Here is what is happening:

1) Neither file will open in VirtualDub (AVI in 1.4.10, ASF in 1.3c). Both generate error messages specifying the missing codecs.

2) DivX Player (2.0 Alpha) will not open the AVI file and gives no message specifying why. (It of course does not handle ASF at all.)

3) Both Windows Media Player (6.4.07.1112) and the RadLight (3.03 [R5]) player will play both videos (although RadLight renders both the video and audio with far better quality).

4) In AutoPlay Menu Studio (which only supports AVI directly), the AVI file will play audio but not video, but does identify the missing codec.

Question: Why the vast differences in the way these files are handled by these programs? In other words,

a) If the codecs are not there, how can any of them play these files, and, if some of them can, why can't all?

b) Given the same input video, how does RadLight produce such superior quality? Both MUST be using SOME codec; is it that they are using different ones, or is it that their programming is that different? [Note: My installed codecs are VDOM, CVID, IV31 and IV32 (same DLL), MSVC, MRLE, M263, M261, IV50, and DIVX (5.0.1).] And if it is the latter, how would that effect my encoding if my videos were primarily going to people with only the Windows Media Player?

[zoli]

hey, your footer kicks ass

[Batman]

You do have that codec (asf is part WMP). The error you probably recieve is because of legal reasons Virtualdub can't open them.

[khp]

The reason you can play the avi file in wmp is that it automatically downloads the codec from microsoft on playback, this of course only work with microsoft codecs. The codec is not installed on your system and therefore it won't open in virtualdub.

[benedict]

Agree totally (now), as I have recently seen (for the first time in the 24 months that I have owned this box), when WMP did indeed download a codec for me.

Even asked me first if I wanted it installed. Quite white of it.

Trouble being, it did indeed download it, but did not in fact install it. It did indeed place it where WMP (and several of my players) could find it, but not any other programs that depend on the SYSTEM.INI pointer update (like VDub).

Directly after the MS "supposed install", I checked my SYSTEM.INI. Unchanged. Sure, WMP and RadLight could play that file, but no one else could.

MS does this to convince the average person who tries to play a video that WMP is "the only" player that can really "handle it all". A simple "market share" move by them and quite similar to what ended them up in federal court last time.

In fact, there is a very good reason why a SYSTEM.INI is required for a complete install, and I am sure whoever wrote VDub was quite well aware of this fact:

The pointer in SYSTEM.INI allows the user the option to substitute one video DLL for another while he or she attempts to get a better output. This is why RadLight played that very same video back with much greater quality than my much older version of WMP. RadLight, like WMP, knew where to look, but because it was newer, it also knew some DLL names to look for there that my old WMP did not. It then promptly selected a codec more capable of rendering that video.

But this is not for the chicken-hearted user, for sure. But it allows the more sophisticated user another level of options for video processing. Namely, go in to SYSTEM.INI and change the DLL that the FourCC code there points to.

Am I that "sophisticated" video person? I have tampered with those pointers successfully to resolve problems, but no, I am not.

What I am, however, is someone who is pretty damned good at figuring out the glue that holds operating systems together, including those parts of it relating to video.

Sometimes (like this), it just takes me a while.