Specialized codec pack for high quality and 10-bit solutions? (Remake)

[nand chan]

I've been thinking of starting development on a new codec pack, the aim of which would be to target some of the issues I see with the currently available codec packs:


The proposed solution I had to fix the version problem would be to grab the latest builds of each component via HTTP during the installation process, that way I wouldn't have to keep updating the pack manually and it would always be up to date.
I intend to include an automatic update facility which would repeat the process described above to update the versions of each component.
High-quality playback: The pack would include components such as madVR as default renderer, LAV Video for the decoder and ReClock configured in bit-perfect WASAPI exclusive mode.
Compatibility with, in particular, Hi10P H.264 inside Matroska, with ASS/SSA softsubs; using a full 10-bit pipeline and emphasis on proper levels conversion - this would be the main developmental focus.
I would probably tie in my existing CMS middle-ware library in order to automatically profile and calibrate the user's monitor (should a colorimeter be present)
Customization: I would present multiple different, easy-to-understand and well-described configuration “profiles”, to make it easy to tailor the pack to your needs using a wizard.
Minimalism/file-size: Since the pack itself would include none of the components, I would only download what the user actually needs - thus avoiding the large overheard of certain “bloated” packs like K-Lite


Does anybody think this would be a good idea? Would anybody show interest in the project? Constructive feedback?

Note: The original thread was deleted because I included a politically suggestive joke. I have removed the offending joke.

[Hypernova]

Sounds good to me. My suggestion would be making those components interchangeable. For example, I personally not comfortable with using ReClock, so I would like to be able to pick something else for that part.

[mindbomb]

until lav audio has a mixer, idk if including wasapi will be worth it, since it can cause a lot of problems.

[Chetwood]

Concerning 10bit, anyone read this (http://community.wdc.com/t5/Live-Live-Plus-Ideas/H-264-10-bit-support/idc-p/242806#M5164), especially the last paragraph?

[sneaker_ger]

Concerning 10bit, anyone read this (http://community.wdc.com/t5/Live-Live-Plus-Ideas/H-264-10-bit-support/idc-p/242806#M5164), especially the last paragraph?

It's wrong and has been explained several times:
http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

[nand chan]

Sounds good to me. My suggestion would be making those components interchangeable. For example, I personally not comfortable with using ReClock, so I would like to be able to pick something else for that part.

That was part of the plan. If possible, I would try and make everything flexible, eg. you'd get a large screen with two options that would allow you to choose between either “exclusive mode” output (which would use ReClock) or “normal mode” output (which would use DirectShow, unless you choose to fix the framerates using ReClock later on). The screen would explain things such as exclusive mode meaning nothing else can play sound at the same time as you watch videos.

At the very least, I will offer a choice between “Express”, “Intermediate” and “Expert” modes, so those who don't really know what to configure can go with what I deem good as default. (Will be what's most compatible, eg. baseline DirectSound, madVR in non-exclusive mode, etc)

until lav audio has a mixer, idk if including wasapi will be worth it, since it can cause a lot of problems.

What exactly do you mean by this? Are you worried about 5.1 -> 2.0 downmixing? If so, I would do this using the ffdshow raw audio processor.

Concerning 10bit, anyone read this (http://community.wdc.com/t5/Live-Live-Plus-Ideas/H-264-10-bit-support/idc-p/242806#M5164), especially the last paragraph?

Encoding with 10 bit depth will reduce the filesize at the same quality - I don't know the details, but I'm guessing it's because patterns that would require a lot of noise/dither in 8-bit would be a linear gradient in 10-bit which can be more easily predicted. At the very minimum, 10-bit encoding allows the encode to reduce the banding present on the Blu-ray, in short, you can create artificial 10 bits of depth using debanding filters. And that, you can dither at runtime using high quality dithering algorithms eg. the one in madVR, while saving a lot of bandwidth that would be needed to save the dithering in the actual file.

And finally, storing 10-bit video means you can keep the 10 bits of precision during the entire pipeline up to the very last step, where it would get dithered back down to 8 bits - the overall precision increases this way, and things like eg. upscaling/downscaling can be done with greater accuracy due to the increased information content.

It's wrong and has been explained several times:
http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

In addition to this, if you still have questions about 10-bit video, you could have a look here (http://haruhichan.com/wpblog/?p=205).

[nand chan]

I've done some further planning now. My first decision was to decide on the degree of flexibility - do I offer some sort of advanced, dynamic, interface-based, modular environment for defining installation rules and configuration models, or do I take a pragmatic approach and simply use a set, manually defined list of choices?

I opted for the pragmatic approach since it's the only way to get things done in a reasonable timeframe, and the other is too theoretical / enterprise to be of much practical value.

Given this decision, I have made a preliminary list of decisions which would be made:

= Source =
Choices: Latest / bleeding edge, Old / stable
Mode: Novice
Note: This would determine the download source: For latest, each component would be downloaded from its site.
For stable, they would be downloaded from a special repository which I would be updating manually with
program versions that I know don't break compatibility.

= Performance =
Choices: High-quality, High-performance
Mode: Novice
Note: This would affect the default choice of decoder/renderer.

= Front-end =
Choices: Currently just MPC-HC, maybe potplayer or Zoom Player in the future
Mode: Intermediate
Default: MPC-HC

= Splitter =
Choices: Haali Media Splitter, LAV Splitters
Mode: Expert
Default: Haali

= Video Decoder Type =
Choices: Hardware decoding (w/ soft backup), Software decoding
Mode: Intermediate
Default: If high-quality mode, software always, if high-performance, hardware decoding

= Software Video Decoder =
Choices: LAV Video, ffdshow video, madVR internal, MPC-HC internal
Mode: Expert
Default: LAV Video

= Hardware Video Decoder =
Choices: LAV CUVID, DXVA [I might have to figure out how to work CoreAVC in seeing as it's non-free software]
Mode: Expert
Default: LAV CUVID if available, DXVA otherwise

= Audio Decoder =
Choices: LAV Audio, ffdshow audio, MPC-HC internal [+additional madFlac]
Mode: Expert
Default: ffdshow audio (greatest support for formats) + madFlac

= Subtitles =
Choices: MPC-HC ISR, VSfilter, VSfilter (threaded)
Mode: Expert
Default: MPC-HC ISR if quality, VSfilter (threaded) if performance

= Video Renderer =
Choices: madVR, Haali's Renderer, EVR CP, VMR-9, Overlay Mixer
Mode: Expert
Default: madVR if quality, EVR CP if performance (or DXVA)

= madVR mode =
Choices: Normal, Exclusive
Mode: Expert
Default: Normal
Note: Only available when madVR is selected as renderer.

= Audio Renderer =
Choices: DirectShow, ReClock (time stretching mode), ReClock (bit exact mode)
Mode: Intermediate
Default: DirectShow

= Audio Mixing =
This would use ffdshow audio processor.
Choices: 7.1 setup, 5.1 setup, 2.1 setup, 2.0 setup
Mode: Novice

= Compatibility / collision checking =
Mode: Expert
Collision: Anything but EVR CP <-> DXVA
Collision: VSfilter <-> madVR internal renderers
Note: Each detected collision would allow to change either option on the spot to resolve it
Note: This is only possible in expert mode, since intermediate mode doesn't allow any collisions

Some further thoughts:

The codec pack would be split into an online mode and an offline mode. The online mode would download everything from an online repository (either the latest versions of each component from their respective websites, or a special repository which would be ran by me and updated, say, once a week).

The offline mode would be an archive of my own repository at a given time, the only reason for the offline mode is so you can install it on machines without an internet connection.

The online installer would be very small, the offline installer would be rather large.

[mindbomb]

heads up, if you are going to be downmixing with ffdshow audio processor, I believe you should force 32 bit float processing and 32 bit float output for best results.
so, what I do, is create a profile where I need downmixing, and make it use 32 float, and a profile where I don't need downmixing, where I just disable the mixer altogether.

[nand chan]

heads up, if you are going to be downmixing with ffdshow audio processor, I believe you should force 32 bit float processing and 32 bit float output for best results.
so, what I do, is create a profile where I need downmixing, and make it use 32 float, and a profile where I don't need downmixing, where I just disable the mixer altogether.

That's what I do. I have thee profiles.

One for mono -> stereo upmixing, one for stereo -> stereo throughput (wouldn't touch the signal) and a third for anything -> stereo downmixing (using a custom matrix).

Why would I need 32 bit float output necessarily if I'm going to be using WASAPI either way? I have to down-scale it to 24 bit integer for my DAC to handle it.

[mindbomb]

because reclock's 32 float -> 24 bit output is better than ffdshow's, which isn't completely correct.

[nand chan]

because reclock's 32 float -> 24 bit output is better than ffdshow's, which isn't completely correct.

Okay, good to know. I've enabled it for my down-mixing modes.

[nevcairiel]

There is also a bug which breaks ffdshows abilitiy to switch output formats on the fly depending on the input format. Forcing it to be one format all the time avoids that problem. :)

[CruNcher]

It's wrong and has been explained several times:
http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

No he is right in that that it makes no sense Physicaly you cant take a pair amount of energy and expect that to be less energy if you put more energy into it you wont save energy the end result will have more energy except you reduce that energy again to under the level of the base energy ;)
Though visualy the result can look better no doub't but why do this @ Encoding and why not entirely @ Decoding and PP stage ;) why you must have to Encode/Decode it in 10 bit with a faked 10 bit input ;) if you're anime looks banded @ playback then fix that @ playback not @ encoding :) Simple as that if you have true 10 bit input it looks different but for consumer it makes not much sense, without an entirely 10 bit workflow including 10 bit input and output devices. So you should rather want from companies like Sigma and others to first invest into better Realtime PP for your special usage that might have more success then to try force them into 10 bit ;)
Ateme is not trying to push this consumer related but Broadcast (exactly saving Bandwith) and Broadcasters these days have 10 bit source and there it would make perfectly sense already to save costs by reducing Bandwith even when the output is still on 8 Bit Devices in the end. :)

[nand chan]

No he is right in that that it makes no sense Physicaly you cant take a pair amount of energy and expect that to be less energy if you put more energy into it you wont save energy the end result will have more energy except you reduce that energy again to under the level of the base energy ;)
Though visualy the result can look better no doub't but why do this @ Encoding and why not entirely @ Decoding and PP stage ;) why you must have to Encode/Decode it in 10 bit with a faked 10 bit input ;) if you're anime looks banded @ playback then fix that @ playback not @ encoding :) Simple as that if you have true 10 bit input it looks different but for consumer it makes not much sense, without an entirely 10 bit workflow including 10 bit input and output devices. So you should rather want from companies like Sigma and others to first invest into better Realtime PP for your special usage that might have more success then to try force them into 10 bit ;)

I only read about the first 30% because the rest gave me a headache, but the benefit is bandwidth.

You save bandwidth. You can also do more complex filtering than is possible during real-time playback. (eg. warpsharp)

We wouldn't need Hi10P if bandwidth and processing power was unlimited. But then, we wouldn't need H.264 either.

[naoan]

"Reduce Banding" here, as I understand it in layman term, refer to 10 bit result vs 8 bit result (at the same bitrate), where we assume that the original has no banding at all. I dunnno, I thought it's easy to understand concept...

[nevcairiel]

I only read about the first 30% because the rest gave me a headache

Thats normal for his posts. But my respect for making 30%, i didnt get that far. :p

[mindbomb]

btw, when choosing a name, take a page from the nevcairiel playbook and make it descriptive and professional.

I heard you were going to choose a joke name like cccp. I hope that isn't the case.

[Hera]

btw, when choosing a name, take a page from the nevcairiel playbook and make it descriptive and professional.

I heard you were going to choose a joke name like cccp. I hope that isn't the case.

The joke was naming after the Nazi Party or something like that...

[nand chan]

btw, when choosing a name, take a page from the nevcairiel playbook and make it descriptive and professional.

I heard you were going to choose a joke name like cccp. I hope that isn't the case.

But aren't “descriptive” and “professional” mutually exclusive? :P

Of course, I could go with “Advanced Modern Synergy Solutions” or something.

In all honesty, I'm going to leave the name open for now.

[nand chan]

I've put some more thought into it and started work on the implementation.

The design concept has shifted slightly, and I've narrowed it down to three goals:


Being up to date (live downloads)
Being flexible (high performance, low performance, hardware, software, etc.) - the user can, if desired, choose which component to use for everything
Being accessible - the process has been split into three modes: Novice, Intermediate and Expert. Each mode builds on the previous, adding more detailed options. In Novice mode, the installer should require as little technological knowledge as possible, and all configuration should be automatic to the point where it will work fine out of the box.


The front-end has been successfully abstracted away from the back-end. As such, once this project completes its first stable release, I will be offering alternative interfaces - for example a visual novel-style installer, or a CLI installer.

A screenshot of what my current working version looks like:

http://img813.imageshack.us/img813/3325/nandpack.png

This is just a hacked together command line front-end for the installation system, the final product will *look* nothing like this (but essentially function the same).

The picture shown here is using Intermediate Mode, which is why it allows me to choose whether, for example, I want to use hardware decoding or software decoding, or whether I want to download from a backup repository. The novice mode will just include two questions: “High quality or High performance?” and the choice of which speaker setup the user uses (7.1, 5.1, 2.1, 2.0 etc).

[nand chan]

If anybody's still interested I have not abandoned this project (I get a lot of personal questions about this), and it's capable of setting up MPC-HC already - to do is just the ffdshow/LAV configuration and then I have to find out some way to install Haali automatically, but apart from that it's basically ready for alpha.

[Boltron]

I need a clarification please. Your "Hi10P guide (using madVR+MPC-HC)" states that "you’ll need something like an AMD FirePro card...", I have a standard HD5670. So am I to understand my card won't work for sure? If I check my Denon Receiver HDMI input, it reads 10 bit supported.

[nand chan]

I need a clarification please. Your "Hi10P guide (using madVR+MPC-HC)" states that "you’ll need something like an AMD FirePro card...", I have a standard HD5670. So am I to understand my card won't work for sure? If I check my Denon Receiver HDMI input, it reads 10 bit supported.

I don't think you can get 10-bit output using a 5670. Note: don't confuse 10 bit output with playing back 10 bit files. Playing back 10 bit files works fine on 8-bit cards and monitors.

But if you want true 10-bit output you'll have to ditch madVR as well and use EVR-CP.

[Boltron]

Ah, I see the distinction. So for now, I could in fact play back a file encoded in 10 bit with MPC-HC/LAV/madVR and my 5670. The video out will still however be 8 bit however I should get the benefit of smaller file sizes and possibly improved picture. Is this correct?

One more question. Can I then assume that it is possible to re-encode my blu-rays (which are 8 bit) to 10 bit x264?

[golagoda]

Ah, I see the distinction. So for now, I could in fact play back a file encoded in 10 bit with MPC-HC/LAV/madVR and my 5670. The video out will still however be 8 bit however I should get the benefit of smaller file sizes and possibly improved picture. Is this correct?

One more question. Can I then assume that it is possible to re-encode my blu-rays (which are 8 bit) to 10 bit x264?

Encoding is basically exactly the same, you just need to get the 10-bit version of x264.

[JEEB]

I'm not going to discuss it any further in this thread (https://forum.doom9.org/showthread.php?t=162570) but I disagree with some of CCCP's decisions and choices. I also want to provide users with more flexibility.
Can I get a more comprehensive answer on this? Also, I do not remember you coming to comment on anything at any point of time to our IRC channel (or the forum for that matter).

Personally I am rather open to ideas, keeping in mind the realities that make up the wide array of setups that we are trying to support. Lord can make you cringe, but he does in fact usually end up on the side that is right (he has an immerse amount of knowledge, and has been a major factor to why the CCCP has been able to roll forwards).

tl;dr I would like to hear your ideas and problems (with us), and I believe that we might be a helpful asset as you advance further in your project. The least I want is that there ends up being some problem that could've been avoided if there was some talk, and at the very least I want to show that whatever idea you are having of the CCCP might be incorrect.

And more on the topic, I'll pour here some of the thoughts that have been on my mind about this idea:

If you want to make a package for the "video hifists", make sure that you specifically concentrate on that, and only that. Make it work right out-of-the-box. We at CCCP are just trying to make stuff Just Work on most systems, and that already is a job of its own -- that works in 95% of all cases. 5% will still need some special care (Bad video drivers for hardware that never got better that for some reason only play well with Haali's renderer, etc. etc.). And that is a number that we want to go down, every day of doing support-related activities.

Knowing that madVR doesn't have single defaults that work on all machines and setups (that can overall support it), not to mention that you'd have to check if the machine actually can take it, making this setup most probably won't be easy. But concentrating and trying to make it work will most probably make it all much easier than if you have multiple Points Of Concentration from the very beginning. madVR, being the most "limited" of your components, makes it a perfect'ish choice to concentrate at first. Thinking that the user will know what to select and to completely depend on this is foolish, a surprising amount of people will just select the most fancy thing or keep all on the defaults no matter how much Lorem Ipsum you put on the help (a bright warning does help at times though, just make sure in cases where it's possible reversing that selection is relatively easy).

Do not take this as a take against user's freedom of selection, or that I want to limit what people can do. It is just that I want people to be making logical selections, and that unfortunately is a trait that not many computer users can do, esp. related to things that need information on specific areas of interest, such as DirectShow. Just like x264 got a lot easier to use overall after the introduction of the new defaults, presets and tunes -- instead of having the user pick out every setting around manually, leading to some random black magic rulesets of "what is good", a package should have working defaults. Now, (un)fortunately, x264 by itself is much more simple, and contains much less variables that you have to fill in. And yet, alas, there still are people who follow their ancient rites.

Esp. now that we yet again have clear'ish components that the user can use, and that installing them in a sane'ish way is not that hard, those who actually know their thing can just proceed to set up their playback system. Those who don't(, or are too lazy to do it manually) are then those who I think are the main audience for playback packages. They do not know, thus the defaults must be made to Just Work in most cases, and the user must not be burdened with too many points of selection, esp. such that would not work on his/her system. Which is why I recommend that if you are going to make a package that caters to the so-called video hifist, you limit your concentration there, and make sure all those things you are thinking of (madVR, reclock and whatever else you wanted) work correctly after the installation has finished. Telling the user that he cannot install this package for reason X is not a Bad Thing, it is a Good Thing (of course, leaving a backdoor for testing is recommended when dealing with new pieces of hardware/software combinations).

Also, a note on builds and such. I either recommend you to build all the things you can yourself, or with someone who has the tools/knowledge/time. Although looking at the sources does help by itself by the means of learning things about a given piece of software, I have found out that editing applications' defaults in the source makes settings resets easier to accomplish (as you do not have to keep up-to-date defaults in your registry-touching code installer-side, and thus can just remove the current settings from the registry instead of writing the new ones in before letting things load).

I hope you won't take these words the wrong way :) .

[nand chan]

Ah, I see the distinction. So for now, I could in fact play back a file encoded in 10 bit with MPC-HC/LAV/madVR and my 5670. The video out will still however be 8 bit however I should get the benefit of smaller file sizes and possibly improved picture. Is this correct?

One more question. Can I then assume that it is possible to re-encode my blu-rays (which are 8 bit) to 10 bit x264?

Of course, to both questions. Note: Don't confuse x264 (one specific program) with H.264 (the codec itself). You're using x264 to encode H.264.

Can I get a more comprehensive answer on this? Also, I do not remember you coming to comment on anything at any point of time to our IRC channel (or the forum for that matter).

Personally I am rather open to ideas, keeping in mind the realities that make up the wide array of setups that we are trying to support. Lord can make you cringe, but he does in fact usually end up on the side that is right (he has an immerse amount of knowledge, and has been a major factor to why the CCCP has been able to roll forwards).

There are several problems that come into play here from an ideology perspective: First of all, I don't really want to interfere with CCCP - I want to create my own, personal alternative because I feel that a fresh start is what would be needed to implement the ideas I've been having. Second, I want to bypass the existing “stigma” that CCCP has to its name, especially on elitist communities (“lol he uses CCCP”). Third, and most importantly, the goal of this project is not the same as the goal of CCCP, at least not in its implementation - I'm trying to create a script/tool which will automatically download and install other components for you, I'm not wanting to release any single “pack” like CCCP and K-Lite do it. I suppose this thread is a misnomer, but I haven't come round to changing it.

tl;dr I would like to hear your ideas and problems (with us), and I believe that we might be a helpful asset as you advance further in your project. The least I want is that there ends up being some problem that could've been avoided if there was some talk, and at the very least I want to show that whatever idea you are having of the CCCP might be incorrect.

I don't have any problems with you personally - it's just that I don't like some of the (software) choices CCCP makes, for example defaulting to ffdshow video which I believe is not acceptable for modern video, and the lack of flexibility (eg. no support for madVR, reclock and so forth, depending on the user's requirements).

And more on the topic, I'll pour here some of the thoughts that have been on my mind about this idea:

If you want to make a package for the "video hifists", make sure that you specifically concentrate on that, and only that. Make it work right out-of-the-box. We at CCCP are just trying to make stuff Just Work on most systems, and that already is a job of its own -- that works in 95% of all cases. 5% will still need some special care (Bad video drivers for hardware that never got better that for some reason only play well with Haali's renderer, etc. etc.). And that is a number that we want to go down, every day of doing support-related activities.

That's actually a risk I'm willing to take. I'm just trying to make life easier for those who want greater flexibility, as well as making it easier for tinkerers to get pointers in the right direction. What I've been doing up to now is writing often lengthy “guides”, but these are set back by gradually becoming far too long not to mention somewhat complex to follow along. I'm hoping for this program to basically become an automated version of my guides which would remove most of the hassle, strain and trolling (“lol 10 pages of guide just to use MPC-HC, meanwhile VLC just wurkz”).

If things ever break unnecessarily and I can't think up an easy way to fix it, my default reply will be to “install CCCP” or “use mplayer”.

Knowing that madVR doesn't have single defaults that work on all machines and setups (that can overall support it), not to mention that you'd have to check if the machine actually can take it, making this setup most probably won't be easy. But concentrating and trying to make it work will most probably make it all much easier than if you have multiple Points Of Concentration from the very beginning. madVR, being the most "limited" of your components, makes it a perfect'ish choice to concentrate at first. Thinking that the user will know what to select and to completely depend on this is foolish, a surprising amount of people will just select the most fancy thing or keep all on the defaults no matter how much Lorem Ipsum you put on the help (a bright warning does help at times though, just make sure in cases where it's possible reversing that selection is relatively easy).

The approach I have taken to solving this problem is by splitting choices into different “levels of expertise”. My goal for the “novice” difficulty setting is to provide as few dialog options as possible. It will not be possible to “next, next, next” through my installation platform, you have to make a choice for each question presented. Currently, in “novice mode” all you have to do is set a slider to the right position between “high performance” and “high quality”. If a user knows his CPU/GPU are not particularly powerful, he can choose the “high performance” mode. So if somebody complains about D3D memory errors, laggy rendering etc. I can just say “re-install in high performance mode” (I aim to make my installer capable of updating existing installations with newer components and/or settings).

Do not take this as a take against user's freedom of selection, or that I want to limit what people can do. It is just that I want people to be making logical selections, and that unfortunately is a trait that not many computer users can do, esp. related to things that need information on specific areas of interest, such as DirectShow. Just like x264 got a lot easier to use overall after the introduction of the new defaults, presets and tunes -- instead of having the user pick out every setting around manually, leading to some random black magic rulesets of "what is good", a package should have working defaults. Now, (un)fortunately, x264 by itself is much more simple, and contains much less variables that you have to fill in. And yet, alas, there still are people who follow their ancient rites.

Once the system is in place, changing the defaults / settings is a trivial matter of editing a few lines of code. (Hell, I could even serialize this information from an online database). In my baseline “high performance / compatibility” mode, the configuration will largely mimic that of CCCP (except that LAV Video is preferred over ffdshow video where possible due to in my experience increased performance).

The difference is that instead of being limited to a single “configuration” or “pack”, I can generate these choices during runtime, for example by automatically scanning the system for CUDA/DXVA support. I also have quite a few “collision detection” / sanity checks in place which would run a bunch of logic tests to make sure a configuration will be working (at least, working on my machine - once this project hits alpha and eventually beta I'll be able to make more informed choices / corrections on others' systems as well), to prevent you from, for example, expecting VSfilter to work with madVR's internal decoders - a mistake many may not even realize. (However, blunders like this will certainly only be possible in “expert mode”, as everything below it (intermediate, novice) is designed in a way to make impossible configurations, well, impossible)

Basically, the advantage of what I'm aiming to do is flexibility in the literal sense - if somebody knows that he, say, wants a certain front-end over another, or wants to apply avisynth post processing or use reclock to correct framerates, he can simply tell my installer this information and it will generate the best configuration for him.

Finally, I have another few tricks up my sleeve planned for this - in full-blown expert mode, I'm thinking of providing a user with (possibly real-time) samples of what each eg. upscaler looks like, so you can actually choose while seeing it in front of your eyes - instead of having to do these tests manually.

Esp. now that we yet again have clear'ish components that the user can use, and that installing them in a sane'ish way is not that hard, those who actually know their thing can just proceed to set up their playback system. Those who don't(, or are too lazy to do it manually) are then those who I think are the main audience for playback packages. They do not know, thus the defaults must be made to Just Work in most cases, and the user must not be burdened with too many points of selection, esp. such that would not work on his/her system. Which is why I recommend that if you are going to make a package that caters to the so-called video hifist, you limit your concentration there, and make sure all those things you are thinking of (madVR, reclock and whatever else you wanted) work correctly after the installation has finished. Telling the user that he cannot install this package for reason X is not a Bad Thing, it is a Good Thing (of course, leaving a backdoor for testing is recommended when dealing with new pieces of hardware/software combinations).

As I've mentioned before, my current system only requires two choices when run in novice mode: 1. the choice between high performance and high quality, and 2. what your audio system looks like (headphones, 2 speakers, 4 speakers, 5.1, 7.1) - I'm not sure whether I should auto-detect this as well based on the default Windows audio device but the possibility is open. In fact, the possibility is open to detect the user's CPU/GPU as well and make a guess on how powerful they are (eg. by consulting the WEI).

It is important to note at this point that the way I've designed my engine is that the installation (downloading components, setting up filters/registry) is completely separated from the configuration by a thick abstraction layer. I can easily make configuration changes on the fly, I can even provide a bunch of different interfaces to do so (the interface is itself heavily abstracted from the configuration, which is mainly logical/virtual). So, basically - I don't have to worry too much about changing my installation code if I change defaults.

Also, a note on builds and such. I either recommend you to build all the things you can yourself, or with someone who has the tools/knowledge/time. Although looking at the sources does help by itself by the means of learning things about a given piece of software, I have found out that editing applications' defaults in the source makes settings resets easier to accomplish (as you do not have to keep up-to-date defaults in your registry-touching code installer-side, and thus can just remove the current settings from the registry instead of writing the new ones in before letting things load).

I won't be building anything myself. I don't want to reference any self-built components. Once this system is complete, I should not have to manually update it (except to change stuff like new settings, etc.) for each new version. I will be referencing pre-built repositories.

I have not thought much about how to handle the registry all that well, especially not when things change. This will be one of the problems I will be tackling throughout the following time.

I hope you won't take these words the wrong way :) .

Not at all. I hope you understand my intentions a bit better now.

[JEEB]

First of all, I don't really want to interfere with CCCP - I want to create my own, personal alternative because I feel that a fresh start is what would be needed to implement the ideas I've been having.
And I first of all like to have communication with people who might happen to influence things that we have to deal with. I like to talk with nevcairiel, general MPC-HC developers, x264 developers, libav/ffmpeg developers etc. etc. on the IRC, it is usually the quickest way of getting a hold of someone when needed. You will seemingly be making a package, and I'd most likely would want to make sure that no dumb mistakes are done, and that the technical expertise that I happened to have around ever since Lord came back online could be available to people who might have it useful.

Unfortunately you seem to have completely missed this point of the first part of my text.
Second, I want to bypass the existing “stigma” that CCCP has to its name, especially on elitist communities (“lol he uses CCCP”).
Given that IIRC the CCCP made the overall range of playback package solutions better in the 2000s, I'd say anyone who expresses this kind of behavior is a jerk and has no idea of anything.

And I am deeply disappointed in you bringing up such herp derp, I thought you were more mature than that.
I don't have any problems with you personally - it's just that I don't like some of the (software) choices CCCP makes, for example defaulting to ffdshow video which I believe is not acceptable for modern video,
These are not set in stone, and the reason for us using -tryouts is because it was the only solution at the time. Nevcairiel had talked about his video decoding filter on #mpc-hc-dev, but it was not real and out yet back then. Not to mention that the quality-wise problems that people are seemingly having with 420P10 being downconverted to 420P8 is massively over-exaggerated. Oh, and that underflown timestamp problem with H.264 in matroska that Lord fixed still seemed to be there in the beginning of LAV Video's lifeline, although I would guess by now it should have been fixed already.

I'm a newcomer to the CCCP development side of things and I didn't have Nicholi's holding hand to guide me around. LAV Splitter went through Lord's source code check-ups and got integrated after a few days of codemonkey'ism scattered around a month or so. The next thing around the corner would be LAV Video, not like I don't want proper'ish 4:4:4 support if possible :V (although EVR-CP IIRC still breaks with AYUV) -- LAV Audio will have to wait until there's a mixer for it.
and the lack of flexibility (eg. no support for madVR, reclock and so forth, depending on the user's requirements).
The thing is with these things that they happen to be very, very hard to make sure that they work, and if we are sure if the user actually does want them. madVR is still relatively easy, you just have to have a whitelist of GPUs that can take it, as well as driver etc. versions + all the defaults known to work on this software/hardware. Reclock? What exactly does the user want from it? Is it really needed? Etc. etc. Personally I have so far never had the need to use reclock, and most people during the years have had more problems from reclock (and/or ac3filter) than they have actually gained.

But we don't stop people from using those components if they want them. It's not like we make it harder for them to set it all up. Thus, I don't really think this in any way is less flexible than anything else.

That's actually a risk I'm willing to take.
Then, I plead of you, do make the checks -- seriously. Do not leave them away in case this thing becomes real. I can't possibly stress the importance of not letting the person set something that won't work on his/her setup.

Currently, in “novice mode” all you have to do is set a slider to the right position between “high performance” and “high quality”. If a user knows his CPU/GPU are not particularly powerful, he can choose the “high performance” mode. So if somebody complains about D3D memory errors, laggy rendering etc. I can just say “re-install in high performance mode”.
Remember the thing I wrote about users being dumb? Now guess how many people come around with just because they didn't heed the DirectX runtimes warning in the beginning of the installation?

You will want that hardware checking around :P
Once the system is in place, changing the defaults / settings is a trivial matter of editing a few lines of code. (Hell, I could even serialize this information from an online database).
Now this sounds not-so-bad finally.

Basically, the advantage of what I'm aiming to do is flexibility in the literal sense - if somebody knows that he, say, wants a certain front-end over another, or wants to apply avisynth post processing or use reclock to correct framerates, he can simply tell my installer this information and it will generate the best configuration for him.
Re: General user's level

I'm thinking of providing a user with (possibly real-time) samples of what each eg. upscaler looks like, so you can actually choose while seeing it in front of your eyes - instead of having to do these tests manually.
This doesn't sound too bad.

I won't be building anything myself. I don't want to reference any self-built components. Once this system is complete, I should not have to manually update it (except to change stuff like new settings, etc.) for each new version. I will be referencing pre-built repositories.

I have not thought much about how to handle the registry all that well, especially not when things change. This will be one of the problems I will be tackling throughout the following time.
Just noting that it really should be one of the things you should be tackling quite soon AKA now AKA you should've already :P

And sure, whatever floats your boat on the builds, just note that almost any component will try to bulge its own defaults into the registry when registered/run. LAV filters for example enable everything and the amount of stuff in registry IIRC depends on how much stuff there was enabled in the ffmpeg build used for the given component.
Not at all. I hope you understand my intentions a bit better now.
Unfortunately, not... really >_> But at least I could stress the overall importance of making system checks, as you are dealing with things that are much less overall usable than most of the DirectShow filters around.

And of course, good luck on your project overall.