how to create a codec pack?

[lol_123]

I tried to create my own video codec pack, just like what k-lite does.I simply put all codecs of k-lite collection together with using installshield. I installed it on a clean XP, but it did not work.
i meant i used MPC playback a rmvb, it said no proper decoder.
By the way, i had registed all ax files.

Does any one know how to create a codec pack?

Thanks, -L

[setarip_old]

Hi!

1) Why look for trouble? The wisest advice given regarding installation of codecs is: INSTALL ONLY THE CODECS YOU NEED!

2) If you (obviously) have the NEEDED individual codecs available, what will you gain by putting them in a "pack"?

3) If your intention is to distribute such a pack to others, make certain you don't include any commercial codecs, as doing so would be illegal

[lol_123]

setarip_old,

The reason is pretty simple that i just want to learn!
i am sure that it is a pretty easy job to put together a codec pack comparing with to develop a video processing filter! but now i just do not figure it out

By the way, there already have enough bulabula CODEC PACKS existed, what makes you think i gonna distribute another one.

[setarip_old]

what makes you think i gonna distribute another one.Nothing at all. That's why, as one of three items I listed, I said, "IF your intention is..."

[JohnnyMalaria]

By the way, i had registed all ax files.

Is your installer doing registration or are you doing manually?

Not all codecs are .ax files, many are .dll so you probably need to register those, too.

You can always just blindly register all .ax and .dll files - only those that are valid codecs/filters will actually register.

[check]

You can always just blindly register all .ax and .dll files - only those that are valid codecs/filters will actually register.Sounds like a good recipe for pain from here, relying on other people's DLLs and AXs to be sanely behaved, especially AV related ones ;)

[JohnnyMalaria]

Sounds like a good recipe for pain from here, relying on other people's DLLs and AXs to be sanely behaved, especially AV related ones ;)

No more insane than a codec pack!

Seriously, though, only modules that have the appropriate DllRegisterServer export will actually do anything. My assumption is that if you have deliberately put a file in the installer then you would (I hope) know whether it needs to be registered or not. Certainly, installing many codecs is asking for trouble if one codec screws up another at registration etc.

[stax76]

I think the problem is not only the codec packs but also the codecs and ultimately the nature of dshow. It's easy to blame the codec pack if the system strikes but the root of the problem is not always the codec pack, it's also often the codec or the ignorance of the codec pack user that is typically a clueless n00b that will damage the system with or without a codec pack rather sooner than later.

[lol_123]

Many thanks for all your replies. Does anyone give me a little more constructive suggestion.
thankssssssssssssssssssssssssssssssssssss. -L
PS:
I gave up installshield, i can not find out an appropriatie word to describe installshield(AWFUL!!!). Now i am using NSIS, it's pretty COOL!

[stax76]

You must be either naive or a passionate assembly programmer than.

[lol_123]

I had made it.
Let me summrize how to make a codec pack
1. Put all codecs together in a directory
2. most of codecs have to regsit in windows register,so you need find out all those information.
3. i recommend to use NSIS to build a pack

[JohnnyMalaria]

Many thanks for all your replies. Does anyone give me a little more constructive suggestion.
thankssssssssssssssssssssssssssssssssssss. -L


I did but you haven't replied to the questions (post #5)...

[lol_123]

I did but you haven't replied to the questions (post #5)...


Johnny, you are right, my first try i havent registed all DLLs and AXs as well as intialized some ax like ffdshow in windows register.

I have another question,
today i downloaded a mediaplayer , called StormII (i think it is a revised MPC, just like KMP. One thing is really strange.
I unregisted all codecs from Windows,but it still works well.
I looked into its installatioin dirctory, it put all codecs there. But for my understanding, most codecs are COM, so you have to register it before using it.

Does anyone know how it works?

[JohnnyMalaria]

most codecs are COM, so you have to register it before using it.

Does anyone know how it works?

They might be Video for Windows. Or the media player may simply be loading the codecs directly and bypassing the usual registry-based filter enumeration. It isn't necessary to register a DirectShow filter if the software that uses it knows where it is.

[lol_123]

It isn't necessary to register a DirectShow filter if the software that uses it knows where it is.[/QUOTE]

Can you give me more detail about it?
how to bypass it?


thanks L

[LoRd_MuldeR]

It isn't necessary to register a DirectShow filter if the software that uses it knows where it is.

Can you give me more detail about it?
how to bypass it?


thanks L

DirectShow filters are registered on a system-wide scope.

If some DirectShow player wants to play a specific file, it simply asks the DirectShow framework to build the filter chain.
Then DirectShow will search all installed filters for suitable filters. If it finds suitable filters to connect the Source with the Renderer, the file can play.
So the host-application (player software) doesn't need to know about the involved filters...

[lol_123]

DirectShow filters are registered on a system-wide scope.

If some DirectShow player wants to play a specific file, it simply asks the DirectShow framework to build the filter chain.
Then DirectShow will search all installed filters for suitable filters. If it finds suitable filters to connect the Source with the Renderer, the file can play.
So the host-application (player software) doesn't need to know about the involved filters...

That's the reason why i bring up the question.
As i said before, i unregisted all codecs, it means there is no any codec information in window register, if you are using MPC, you can NOT play any video clips at all.

[check]

It's possible for programs to register their own filters into the DShow framework dynamically (and privately). This is Level III Magic and you shouldn't worry about it.

[JohnnyMalaria]

To use a DirectShow filter that is registered in the way LoRd_MuldeR describes, the application uses the CoCreateInstance(..) COM API method. You specify a unique identifier for the filter (UUID) and COM trawls through the registry and, if found, loads the module and returns a reference to the IUnknown COM interface.

To use a filter that isn't registered, you simple load the module as like any other Windows module and then call the necessary methods to get a reference to the IUnknown COM interface.

[stax76]

To summarize, you can:

let dshow build the graph
build the graph manually using registered filters
build the graph manually using not registered filters

[lol_123]

Thanks for all your replies, but i did not get your point.

Let me describe my question cleanlier

The following is the sequence of MPC
1. Open a video clip,
2. MPC looks up in Windows registry to get all available source filters, then loads all available source filters
3. Try to connect until get connected
.
.
.
If there is no DS filters CLSID in the registry at all, how can I get the IUnknown COM interface under current MPC architecture. i mean minimal change.

What is the necessary methods,

[LoRd_MuldeR]

Well, MPC doesn't do that manually. It simply asks the DirectShow framework to find, load and connect the appropriate filters for the given file.
Of course MPC can enforce some filter to be preferred over others or to not be used at all. See the "External Filters" menu.

If there is no DirectShow filter registered on your system, no file can be played. It's that simple.
Well, expect the host-application manually loads all the required filters or only uses it's "built-in" filters.

[JohnnyMalaria]

Thanks for all your replies, but i did not get your point.

Let me describe my question cleanlier

The following is the sequence of MPC
1. Open a video clip,
2. MPC looks up in Windows registry to get all available source filters, then loads all available source filters
3. Try to connect until get connected
.
.
.
If there is no DS filters CLSID in the registry at all, how can I get the IUnknown COM interface under current MPC architecture. i mean minimal change.

What is the necessary methods,

If you have access to the application's source code and can recompile it, then you can use a filter privately.

Have a search on http://www.gdcl.co.uk/ (this is the website for the guy who designed DirectShow).

[lol_123]

If you have access to the application's source code and can recompile it, then you can use a filter privately.

Have a search on http://www.gdcl.co.uk/ (this is the website for the guy who designed DirectShow).

Thanks John, i downloaded a source code (appfilter.zip) from gscl,
it may help, _L

[zachdms]

The reason is pretty simple that i just want to learn!
i am sure that it is a pretty easy job to put together a codec pack comparing with to develop a video processing filter! but now i just do not figure it outA: And what exactly are you trying to learn... ?
B: That's an apples to oranges comparison. Thankfully most install packages can be pieced together via NSIS, InstallShield, MSI, etc, so your work is "easier".

I had made it.
Let me summrize how to make a codec pack
1. Put all codecs together in a directory
2. most of codecs have to regsit in windows register,so you need find out all those information.
3. i recommend to use NSIS to build a packThis is a horrible and flawed plan.

How does your package deal with conflicts with a later or earlier version of one of your codecs? Clearly you don't handle that given that install rule set. Thus you are back in the days of DLL Hell, a name given because multiple versions of DLLs floating around were causing hell for users... which is pretty much where we are now with codecs and codec packs.

A well designed codec pack would use *known* (not random or personal) locations for any included codec and, due to the stupid nature of most codec packs, would preemptively verify the existence or non-existence of any codec to be installed (probably through a registry look-up). Thus you would be able to have some level of guarantee that your own version is newer or older than that which is installed and avoid one level of problems.

Still, codec packs are a pretty horrible plan. =\

[stax76]

It's common to install COM components in private locations, no problem with that.

[rica]

A: And what exactly are you trying to learn... ?
B: That's an apples to oranges comparison. Thankfully most install packages can be pieced together via NSIS, InstallShield, MSI, etc, so your work is "easier".

This is a horrible and flawed plan.

How does your package deal with conflicts with a later or earlier version of one of your codecs? Clearly you don't handle that given that install rule set. Thus you are back in the days of DLL Hell, a name given because multiple versions of DLLs floating around were causing hell for users... which is pretty much where we are now with codecs and codec packs.

A well designed codec pack would use *known* (not random or personal) locations for any included codec and, due to the stupid nature of most codec packs, would preemptively verify the existence or non-existence of any codec to be installed (probably through a registry look-up). Thus you would be able to have some level of guarantee that your own version is newer or older than that which is installed and avoid one level of problems.

Still, codec packs are a pretty horrible plan. =\

This is what i think as well.
Lol_123, if you want to make a codec pack directory, lets say lol codec pack, what i would advise is you to make some sub-directories like Cyberlink, Arcsoft and adjust merits of the decoders.

[clsid]

It's common to install COM components in private locations, no problem with that.
I agree. Dumping everything in system32 (which is the only suitable common location) is a very bad idea imho. People with DS filter problems often have a whole bunch of crap in system32 and don't know who or what placed them there. Version issues are not really much of a problem, unlike there is with commonly used dlls, since few programs install commonly used DS filters.

And there are codec packs that check for the existence of certain codecs, prompting a user to uninstall them, or disallow replacing them.

Microsoft also has a few codecs pack for their WM stuff. Is MS a bad company now for making such evil things? :P

[zachdms]

It's common to install COM components in private locations, no problem with that.No, you fairly completely missed my point, which is very understandable. It is common to install private COM components to private locations. It is uncommon to install public COM components to private locations. That bad practice is called DLL Hell (http://en.wikipedia.org/wiki/DLL_hell). I would strongly encourage anyone truly interested in this subject to read up on that and try to take to heart the painful lessons learned.

I agree. Dumping everything in system32 (which is the only suitable common location) is a very bad idea imho.I agree that dumping everything to system32 is bad. On the other hand, why does each "codec pack" need to install AC3filter or FilterX to a random directory? Wouldn't it be more efficient/wiser overall to have a common shared directory for at least that filter?
- c:\program files\common files\codecs\filterx\filterx.dll
for example would seem like a remarkable step forward over what's going on in this space now.

It is uncommon to install codecs to system32. That'd be a bad practice too. Installing to system32 would be stupid but would still be better than 6 versions of ac3filter or filterx floating around the system. I like my "common files" solution. ;)

People with DS filter problems often have a whole bunch of crap in system32 and don't know who or what placed them there. Version issues are not really much of a problem, unlike there is with commonly used dlls, since few programs install commonly used DS filters.Disclaimer: I work at MS (no great secret) and I pay a lot of attention to codec issues. Most of the overwhelming number of codec *crashes* are in codecs installed to private paths ( 'c:\...\k-lite\...' being a directory path I've seen in the debugger way way too often).

And there are codec packs that check for the existence of certain codecs, prompting a user to uninstall them, or disallow replacing them.

Microsoft also has a few codecs pack for their WM stuff. Is MS a bad company now for making such evil things? :PIf we weren't talking about random haphazard distribution of beta / alpha level filters/codecs, you'd have a great point. But since the WM codec packs are non-beta codecs and have a team that would actually service those issues behind them, it's rather an apples-to-oranges comparison. Those packs definitely aren't perfect, but their flaws are masked by shipping well-tested components.

ACE and Nimo and others did a "wonderful" job of dumping trash into the multimedia ecosystem and then walking away and letting that garbage fester. I just don't see the need for more people to make those same stupid mistakes. When I have to help tweak the OS to simply not load a particularly boneheaded broken codec that ACE installs because it's breaking ... any application that uses sound, we've got some serious issues going on.

I have the utmost respect for you and all the other members on this forum who are helping to make multimedia better. I'm trying to do my part too. The single biggest challenge I face in trying to help re-stabilize Win32 multimedia is broken codec packs. It's stupid to me that two of the biggest sources of crashes for WMP in Vista SP1 are due to MMSwitch.

I think we're at the point now where all active codec packs being maintained by non-tools are actually fairly bug free (relative to the last year, at least), but it's troubling to think where we could two years from now. I don't ~think~ anyone expected MMSwitch to morbidly fester as it has done, and I'm leery of what next fiasco might come. If you at least standardize the installer designs (shared installation locations, for example), you set yourself up so much better for future recovery/salvage work in the field.

[check]

I agree that dumping everything to system32 is bad. On the other hand, why does each "codec pack" need to install AC3filter or FilterX to a random directory? Wouldn't it be more efficient/wiser overall to have a common shared directory for at least that filter?
- c:\program files\common files\codecs\filterx\filterx.dllWouldn't you get exactly the same effect by just making your installer smart enough to detect and unregister already installed copies of filters you'll be installing? Add in a blacklist of evil filters to unregister on sight and I don't really understand how a not-very-standard standard folder hierarchy would be any better.

The best thing codec pack manufacturers can do imo is simply to detect other codec packs / filters on install. We sort-of do the former via the Insurgent, and the latter is done with an albeit small and incomplete blacklist.

[zachdms]

If you're coding your knowledge of the ecosystem now, what happens when you apply that knowledge (installer) one or two years from now? I agree it's a thorny problem, but that's why loose binary distribution is just not a good plan at all ever. If you're really getting common dlls (ac3filter, ffdshow tryouts, filterx) that don't have a common place on the system to call home, that's a problem for the source vendor that you kind of need them to sort out.

One interesting scenario is two different packs containing different versions of the same codecs - the easiest way around that long term is if both shared the same install paths for each "loose" binary. That'd let you use that whole "file version" thing for goodness. =\

[check]

If you're coding your knowledge of the ecosystem now, what happens when you apply that knowledge (installer) one or two years from now?I can only say that IMO having imperfect blacklists is better than attempting to use a system which requires 100% compliance to be useful.

I agree it's a thorny problem, but that's why loose binary distribution is just not a good plan at all ever.I agree, but there is no way these semi-legal codec packs will ever be ditributed in a more official manner.

[zachdms]

Absolutely, I just think you might want to band your blacklists if you don't already, as in this hypothetical table:
* <mmswitch.ax>:0-0.9.9.1:unregister,delete
After all, maybe 0.9.9.1 fixes stuff magically. =\

[check]

I can't think of any evil filter that there exists a situation in which it's not evil. As the prime example so far in this thread, mmswitch should Never Be Used nowdays, and other examples like Intervideo MPEG-4 decoder, ancient vobsub, etc, should also never be left alive no matter what the version.
We do ask people before installing them however..

[clsid]

I agree that installing filters to some standardized location would be good. But that's only useful if everyone does it. So its really just idealism. Another problem would be that the filters should be properly marked as shared files, so that if two applications install the same filter, it remains installed until both applications are uninstalled.
The advantage of having a private location however is that it is easier to identify the source of the filter. Which, in case of a problem, makes it easier for the average user to remove the item in question.
But how many applications do actually install commonly used filters? Codec packs do of course, but they generally allow users to see what they install, and there are usually plenty of warnings about installing multiple packs. Other apps are mostly video conversion tools. But imho it is fairly unlikely that a user has dozens of copies of the same filters installed. And even then there would only be a real problem if the active one is some ancient broken version.
The best solution to prevent most common problems is to detect and (optionally) remove bad filters or lower their merit. But people need to know what is bad, so sharing knowledge about that subject is important.

[smok3]

so basically there is no way to sandbox a codec-pack install and allow user to merit the entire package vs the old situation globally, or codec by codec?

example:
a. i bring my 2 files from machine A to machine B, A is for example huff, B is xvid
b. i bring in my sci-fi sandboxed codec pack + my portable virtualdub
c. i click Enable for my codec pack
d. i decode my A and B to unc.avi
e. i click Disable for my codec pack
f. machine B now starts using its 3 years old xvid decoder again

[clsid]

Sure that would be possible. You just need some specialized tool to run the installer in a sandbox. There are tools (even free ones) that can do that, I can't remember a name though. Those allow you to undo/redo the changes to your system with the click of a button.

Edit: an example is Altiris SVS
http://www.svsdownloads.com/

[betaking]

The creation of a codec package after! you must build a Codec Setting tool to Change and configuration codecs Splitter and Parser!
http://img122.imageshack.us/img122/8863/16zn5.png

[clsid]

The most popular packages (K-Lite, CCCP) have such configuration options available in the installer and/or include some kind of settings tool.

A proper pack should generally restrict itself to installing only one item for each format.