FFDShow with H.264 10bit support

[patrick_]

I searched the web, but had a hard time finding a FFDShow build that supports H.264 10-bit. Finally I found one included in CCCP. I hate codec packs so I decided to replace the files of the default FFDShow Installer with the ones from CCCP. I've only tested it with a single 10-bit file using MPC-HC*, but it worked :D

Download FFDShow rev 3925 with H.264 10-bit support (BETA)
http://www.filesonic.com/file/1444561154/ffdshow_rev3925_20110711-10bit.exe

*if you use MPC-HC, don't forget to deactivate the internal filters.

[Hypernova]

Thanks. I was looking for that also. I don't mind CCCP in comparison to bigger codec pack like k-lite, but still this is nice.

[clsid]

Those builds are alpha quality and are not stable. They should be used with caution. For example 9-bit H.264 will just crash.

Btw, K-Lite has small variants as well. Its latest beta version even has Blu-ray playback capability.

[JanWillem32]

I know for a fact that quite a few people are working on this. I absolutely can't recommend usage of the 10-bit system yet with MPC-HC, until:
1.- A real ffdshow beta comes out that can output at least one of the recommended 10- or 16-bit formats for DirectShow to the player: http://msdn.microsoft.com/en-us/library/bb970578%28v=VS.85%29.aspx .
(Currently all output is rounded to 8-bit formats, so there's no gain by the 10-bit precision yet.)
2.- At least one of the internal renderers has been updated to become able to take in and mix the 10- or 16-bit formats.
3.- At least some quality and reliability testing has been done.

[Dark Shikari]

I know for a fact that quite a few people are working on this. I absolutely can't recommend usage of the 10-bit system yet with MPC-HC, until:
1.- A real ffdshow beta comes out that can output at least one of the recommended 10- or 16-bit formats for DirectShow to the player: http://msdn.microsoft.com/en-us/library/bb970578%28v=VS.85%29.aspx .
(Currently all output is rounded to 8-bit formats, so there's no gain by the 10-bit precision yet.)This is completely false. 10-bit display support isn't merely unnecessary; it's beyond useless.

[patrick_]

JanWillem32, using 10bits in compression doesn't have anything to do with 10bit output. If it worked that way, you would need a 10bit display as well.

clsid, I updated the installer primary to allow x264 users to test/compare 8bit and 10bit outputs.

[JanWillem32]

10-bit display support is something entirely different than 10-bit input to the mixer.
A 10-bit bt.601 or bt.709 encode has a limited ranges [64, 940] [64, 960], [64, 960] Y'CbCr encoding, usually with chroma sub-sampling.
A 10-bit display has a full range [0, 1023] RGB display matrix.

In the link I gave, there's a list with the recommended replacement formats for the regular 8-bit YV12, I420/IYUV, NV12 and AYUV formats that do support more than 8-bit to feed to the mixer.

There's a lot going on in between to get the input format mixed and rendered to the output display. Even if the output of the display is just 8-bit RGB, there's no doubt that quality during mixing and rendering suffers if the input Y'CbCr format is rounded from 10- to 8-bit before even the mixer and renderer can receive the image.

By the way, there's plenty of scientific basis to why the Digital Cinema Initiative set 12-bit as a minimum requirement for both the encoding format and display capability for licensing.
There's also plenty of reasons why the studio formats store XYZ color data in a 32-bit floating-point format.

[Dark Shikari]

10-bit display support is something entirely different than 10-bit input to the mixer.
A 10-bit bt.601 or bt.709 encode has a limited ranges [64, 940] [64, 960], [64, 960] Y'CbCr encoding, usually with chroma sub-sampling.
A 10-bit display has a full range [0, 1023] RGB display matrix.

In the link I gave, there's a list with the recommended replacement formats for the regular 8-bit YV12, I420/IYUV, NV12 and AYUV formats that do support more than 8-bit to feed to the mixer.

There's a lot going on in between to get the input format mixed and rendered to the output display. Even if the output of the display is just 8-bit RGB, there's no doubt that quality during mixing and rendering suffers if the input Y'CbCr format is rounded from 10- to 8-bit before even the mixer and renderer can receive the image.It isn't rounded, it's dithered. There's a slight, but critical difference.

The effect of your display on the effectiveness of 10-bit is negligible. A 6-bit $50 LCD benefits from 10-bit just as much as the world's most expensive IPS monitor because 10-bit is about internal codec precision, not output precision.

[JanWillem32]

How awful to use the dithering compromise right at the start of a rendering instance. I'm having enough trouble with performing convolutions and other filter passes on the inputs full of synthetic noise as it is.
I guess the dithering is less than a structured 128×128 dithering map lookup for every channel, too?
If it's about internal codec precision, please make the decoder 32-bit floating point or better on output, so I don't have to static cast every element of the mixer input to 32-bit floating-point anymore. I can handle pretty much any input quantization, only the double precision for the color management section can be a bit intense to process.
What comes out of the renderer takes at least 7 conversion passes from the decoder's output to the back buffer of the allocator-presenter. What goes on screen can hardly be called raw from what the decoder outputs. Depending on settings, things can look very bad. For instance, a low gamma setting of 2.0 to 2.2 is murder on darker scenes with most consumer-grade video.

[LoRd_MuldeR]

If it's about internal codec precision, please make the decoder 32-bit floating point or better on output, so I don't have to static cast every element of the mixer input to 32-bit floating-point anymore. I can handle pretty much any input quantization, only the double precision for the color management section can be a bit intense to process.

As far as I know, h.264 (and probably most video formats) internally use integer math only. So floating point output doesn't make much sense. You can as well do the conversion yourself, if you need FP math for your post-processing. Also: Even if the original input source only used 8-Bit precision (per color channel) and the final output is going to be 8-Bit again, using 10-bit (12-bit) internal codec precision improves compression efficiency. Whether the decoder outputs 8-Bit or 10-Bit (12-Bit) is up to the decoder's choice, i.e. we don't necessarily need "true" 10-bit (12-bit) output to benefit from "high bit-depth" h.264 video...

[Dark Shikari]

If it's about internal codec precision, please make the decoder 32-bit floating point or better on output, so I don't have to static cast every element of the mixer input to 32-bit floating-point anymore.
a) The H.264 spec only supports up to 14-bit.
b) Floating point math is incredibly slow relative to integer math. A decoder written in 32-bit float would probably not be able to decode 1080p on an overclocked 6-core Core i7.

[JanWillem32]

When looking at the specifications, I really don't see any reason to round any output to integer, and most certainly not 8-bit. The decoded structures are only guaranteed to be 8-bit on the 8-bit lossless profile. All lossy modes will generate in-between values, even on encoding integer input.
I've had absolutely no issues with floating-point performance, as long as you don't rely on the FPU to do the work. A nice example on how to use packed SSE (readable for non-programmers, too): http://software.intel.com/en-us/blogs/2010/12/20/visual-studio-2010-built-in-cpu-acceleration/ . It's also convenient to blend in GPU power when heavy floating-point operations are wanted, but the programming for that is very specific, and the GPU has only very little integer math power.

A bit of information why consumer formats are frustrating for studio workers:
You start off with a big, raw camera image format.
You take the camera color calibration scheme and project the input images to a nice studio format with the full XYZ color palette and plenty of quantization.
You edit in that studio format, towards the cinema format 2048×1080 or with less height on 1:2.40 movies. (The 4k profile of 4096×2160 is still very rare.)
You make the cinema screener: the XYZ color space remains intact in the encode, only when encoding the JPEG2000 video, colors are quantized to 12- or 14-bit and the gamma is set to 2.6. The encoding profile is lossless up to 250 Mbit/s. There's no visible change from the studio master to the encode at all. Features are generally some 300 GB in size.
On approval, the final version is encoded for distribution to cinemas with the same type of encoding.
When it's time to do the blu-ray and DVD release, things get nasty.
The image is clipped to 1920 wide for blu-ray, and usually the same amount for DVD, too.
The XYZ color space is converted to the HD, PAL and NTSC color spaces, losing about 2/3 of all possible colors in the space.
The input is limited on maximum lightness (a lowpass filter), because of limitations in the HDTV and SDTV standards.
The gamma is typically set to 2.4.
With DVD, the image is scaled down.
Chroma (2 color channels, relative to grayscale) is sub-sampled to half-resolution in height and width (4:2:0).
On the encoding step, the images are heavily dithered to mask the rounding to 8-bit+limited ranges.

There are plenty of "magic" filters in use by studios when doing the encodes, but you simply can't overcome the limitations set by the encoded format. Studio or cinema video and consumer video don't look nearly the same.
If there are no consumer products that can actually decode anything better than 8-bit, 4:2:0 Y'CbCr, studios hardly have a reason to use anything better. If the rare decoder found that can decode more than 8-bit, but rounds/dithers it again afterwards, studios don't have a reason either. They can take care of a much better set of filters for dithering to 8-bit themselves.
Considering the relative ages of the JPEG2000 and h.264 codecs, I do believe better results can be achieved with the 50 or 100 GB of space on a blu-ray.

On the other side: what I'm working on now. The mixer and renderer have to deal with images that have starvation in input precision, by the quantization level, by the image quality loss trough lossy encoding, by horizontal/vertical resolution and by the limitations in color space.
When writing filters for mixing and rendering stages, I've seen poor quality results with simple filters on even a lossless 8-bit RGB input from a BMP file. (The still image filter in Windows supports it.)
Quantization is one of the things that can be become better than what it is now. The recommended list of formats to transport 10- or 16-bit has been around for a while. Using those formats to for at least the 9-bit and better images is only logical.

[Dark Shikari]

When looking at the specifications, I really don't see any reason to round any output to integer, and most certainly not 8-bit. The decoded structures are only guaranteed to be 8-bit on the 8-bit lossless profile. All lossy modes will generate in-between values, even on encoding integer input.Incorrect. The specification requires bit-exact decoding or decoder/encoder desync will occur, resulting in artifacts.

I've had absolutely no issues with floating-point performance, as long as you don't rely on the FPU to do the work.SSE is part of the FPU. It shares the same execution units.

A nice example on how to use packed SSE (readable for non-programmers, too): http://software.intel.com/en-us/blogs/2010/12/20/visual-studio-2010-built-in-cpu-acceleration/ . It's also convenient to blend in GPU power when heavy floating-point operations are wanted, but the programming for that is very specific, and the GPU has only very little integer math power.I've written thousands of lines of assembly code. I think I know how SIMD works.

Floating point addition in SSE is typically 3/1 (latency/invthroughput). By comparison, integer addition is typically 1/0.5, and with 16-bit integers you get twice as many per register (and four times as many with 8-bit). In the end this means the typical throughput from integer math is 4-8 times higher than floating point.

This isn't even considering the fact that integer math allows all sorts of useful shortcuts, like shifting instead of multiplication, bitmasking, and other performance tricks which are often impossible with floating point math.

[JanWillem32]

Incorrect. The specification requires bit-exact decoding or decoder/encoder desync will occur, resulting in artifacts.Okay, so it's a "cleanup" cycle in decoding. Too bad, I had hoped for sine-wave-like transformations and convolution like with lossy audio that does benefit from floating-points.
SSE is part of the FPU. It shares the same execution units.I mostly meant relying on the classical 1-level approach, instead of 2 or more SIMD instructions at a time.This isn't even considering the fact that integer math allows all sorts of useful shortcuts, like shifting instead of multiplication, bitmasking, and other performance tricks which are often impossible with floating point math.Bitmasking and such is indeed tricky on floating-points. I've done some on GPU work, and I can say that the bit field in floating-point mode is too variable to pull it off correctly usually. Only sign and some exponent tricks work well bit-wise.
The fact that I need to rely more and more on doubles and some floats for various things, does decrease my usage of bitmasking and such. The SSE example shows how to get at least some decent performance on doubles and floats on a CPU. (And give at least some impression to what it is for the regular people here.)

[Dark Shikari]

Okay, so it's a "cleanup" cycle in decoding. Too bad, I had hoped for sine-wave-like transformations and convolution like with lossy audio that does benefit from floating-points.That's because audio codecs are, in terms of prediction, stuck in the 1980s: they still generally have no inter prediction. CELT and AAC Main (LTP) are the only audio codecs with inter prediction, and both do require nearly-bit-exact decoding as a result. IIRC, Long Term Prediction actually requires an implementation of 16-bit floats in order to work correctly.

[JanWillem32]

Interesting material. It seems that many lossless image formats also use a strict step rounding mechanism of the lossy internal structure, just before error correction to lossless.
I know the half float format very well. We currently use the D3DXFloat32To16Array function to write out to D3DFMT_A16B16G16R16F (can also carry non-ABGR data). It's not very fast, so I'd love to replace that one with something better. The structure it outputs is an unsigned __int16*, so the CPU can't really do anything useful with it, either. Once a D3DFMT_A16B16G16R16F texture is created, it goes straight into the GPU with a DMA transfer. Most GPU's nowadays don't have a half float calculation mode (anymore). It's just a supported format to save memory bandwidth. With every texture transfer, all vertices and subpixels are converted to 32-bit float for calculation. Other types are allowed in DirectX 10 for some calculation stages, DirectX 11 allows even doubles on the GPU. The performance is low with anything else but 32-bit float. That's one of the reasons why DXVA parts are separate on the silicon of a GPU.

Anyway, a bit more on topic. I very much hope that this advancement to leads a proper ffdshow beta soon. I'm more than willing to help writing and testing code for a video mixer part, so it's able to receive 10-bit or zero-padded 16-bit Y'CbCr formats. I'm looking at this from the perspective of the regular consumer and professional, too. Once a complete system has been proven to be able to maintain more measurable significant quality than what there was before, it becomes advertisable to the public and professionals in general.

[TheRyuu]

For example 9-bit H.264 will just crash.

That's not going to get fixed until tryouts gets unborked.

No one uses 9bit h264 so I don't really think it matters that much.

[clsid]

That's not going to get fixed until tryouts gets unborked.

No one uses 9bit h264 so I don't really think it matters that much.That part of the code is a huge mess and the people who wrote it are not around anymore. So any help is welcome. I have already done some major cleanup in Swscale, so that the difference with vanilla FFmpeg is now minimal.

As long as x264 supports 9-bit, such files will be made. If ffdshow can not be fixed to support it, then it should reject decoding such files. Crashing is unacceptable.

[aegisofrime]

I searched the web, but had a hard time finding a FFDShow build that supports H.264 10-bit. Finally I found one included in CCCP. I hate codec packs so I decided to replace the files of the default FFDShow Installer with the ones from CCCP. I've only tested it with a single 10-bit file using MPC-HC*, but it worked :D

Download FFDShow rev 3925 with H.264 10-bit support (BETA)
http://www.filesonic.com/file/1444561154/ffdshow_rev3925_20110711-10bit.exe

*if you use MPC-HC, don't forget to deactivate the internal filters.

Thanks so much for this, plays my 10-bit x264 encodes perfectly :)

BTW, is there a link or repository where I can keep up with future revisions?

[SamKook]

BTW, is there a link or repository where I can keep up with future revisions?

You can get beta for ffdshow anywhere, just do a search on google.

Or try here: http://www.afterdawn.com/software/audio_video/codecs/ffdshow.cfm#all_versions

Not sure if they all have 10-bit support enabled though, I don't have anything to test them with.

[ForceX]

Thanks so much for this, plays my 10-bit x264 encodes perfectly :)

BTW, is there a link or repository where I can keep up with future revisions?
Not for FFDshow separately, but you can get the latest CCCP packs from here http://www.cccp-project.net/beta/ which have the version with 10-bit support.

[aegisofrime]

Not for FFDshow separately, but you can get the latest CCCP packs from here http://www.cccp-project.net/beta/ which have the version with 10-bit support.

Hmmm I'm currently on K-Lite and would prefer to keep it that way. Nothing against CCCP, I have just been using K-Lite without a problem so I see no reason to uninstall it. I would prefer a FFDShow installer, that way it's more convenient than uninstalling and installing whole codec packs.

You can get beta for ffdshow anywhere, just do a search on google.

Or try here: http://www.afterdawn.com/software/audio_video/codecs/ffdshow.cfm#all_versions

Not sure if they all have 10-bit support enabled though, I don't have anything to test them with.

I tried a version of FFDShow from here:

http://www.codecs.com/download/FFDShow.htm

Rev. 3943. 10-bit didn't work with it. Seeing as 3943 is newer than the rev. 3925 that the topic creator provided seemed to indicate to me that 10-bit support might not be integrated into the usual builds.

[JEEB]

The 10bit playback support is not yet in mainline -tryouts. Lord is working hard with trying to get things to work on even some kind of a level (filters etc.), and we will be pushing the patches towards clsid when it reaches a level where not only playback works, but even other features could be usable to a level (basically the patches have been more or less alpha'ish level where Lord has been trying fixing various parts with various ways -- the way -tryouts works isn't always straightforward).

You can check overall looks of the patches from my github repo's blitzkrieg branch. I don't push every version of the patch that gets built in there, but if it looks like something that's going towards a more working setup, it usually gets pushed.

[patrick_]

There's a newer 10-bit build up on CCCP, but it's unstable (crashes MPC-HC on closing). I'll update the FFDShow installer when the next more-or-less stable (doesn't crash on the first video) version becomes available. There isn't much difference betweer r3925 and r3943 anyways.

[JEEB]

There's a newer 10-bit build up on CCCP, but it's unstable (crashes MPC-HC on closing). I'll update the FFDShow installer when the next more-or-less stable (doesn't crash on the first video) version becomes available. There isn't much difference betweer r3925 and r3943 anyways.
That's old already, and wasn't really related to 10bit at all. That was a -tryouts bug. I recommend the 2011-07-20_03 build, has filters mostly if not fully working.

edit: read: tested most filters quickly, except for dscaler and bitmap overlay with hi10p 4:2:0, only awarpsharp's output looked odd, but that might've as well been the settings :) Of course, since the amount of filters is humongous, this wasn't a partial rewrite of each and every filter, but an edit that basically made those filters get 8bit 4:2:0 :)

[TheElix]

I tried this file BBB444p10.mkv from: http://x264.nl/developers/Dark_Shikari/ in JanWillem32's build with 10-bit output option and Pixel Format on my PDP set to YCbCr 4:2:2. Does this stats mean that it's ouputting 10 bit? http://rghost.ru/15421901/image.png I wasn't able to get full 24 fps =\

[cyberbeing]

The BBB444p10.mkv is 10bit 4:4:4 as the filename implies. Why are you having FFDShow downsample the chroma to 8bit 4:2:0 NV12? Since the source is 4:4:4, you should output 8bit 4:4:4 RGB32 instead.

[clsid]

It does not output 10bit. The 10bit you see in the MPC stats related to the internal renderer, not the video input that MPC gets.

[TheElix]

The BBB444p10.mkv is 10bit 4:4:4 as the filename implies. Why are you having FFDShow downsample the chroma to 8bit 4:2:0 NV12? Since the source is 4:4:4, you should output 8bit 4:4:4 RGB32 instead.Hmm, good point. But I tried RGB32 and didn't find any difference with NV12 when comparing screenshots. And I looked really hard.

@clsid, I see. Thanks.

[JEEB]

Hmm, good point. But I tried RGB32 and didn't find any difference with NV12 when comparing screenshots. And I looked really hard.

@clsid, I see. Thanks.
Which build is that with (date-wise)? NV12|YV12 output should be quite different from RGB32.

[TheElix]

The link to that build is in the first post. Yeah, I thought so too, but I saw no difference. I made screenshots in D3DFS mode with grab screen software which works like Fraps. It usually works when you want to capture what you really see (which isn't the case with alt+i/F5)

[JEEB]

The link to that build is in the first post. Yeah, I thought so too, but I saw no difference. I made screenshots in D3DFS mode with grab screen software which works like Fraps. It usually works when you want to capture what you really see (which isn't the case with alt+i/F5)
Ugh, so a build from ~11 days ago >_>

Do try the 2011-07-22_01 installer from the CCCP's beta folder and check off everything else but the -tryouts build if you don't need anything else.

[TheElix]

Please, make it clear to me. Does these ffdshow tryout versions included in CCCP pack any different from tryout versions here (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/)? I only downloaded the old version in the first post because someone said that regular tryouts don't have 10-bit support.

[cyberbeing]

Correct, the CCCP BETA includes additional FFDShow patches for high bit-depth h264 support which do not exist in FFDShow-Tryouts. Which is why you should uninstall FFDShow-Tryouts and install FFDShow from the latest CCCP BETA (http://www.cccp-project.net/beta/) when available, if you want up-to-date support for 10-bit playback. They will get committed to FFDShow-Tryouts when they are considered stable, finalized, and/or don't break things.

[ForceX]

Please, make it clear to me. Does these ffdshow tryout versions included in CCCP pack any different from tryout versions here (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/)? I only downloaded the old version in the first post because someone said that regular tryouts don't have 10-bit support.

Yes, they are different. Only the ffdshow-tryout in CCCP supports 10-bit H.264. Although you can play 10-bit H.264 files with current 8-bit decoders (CoreAVC/DivX/non-CCCP ffdshow), the colors will be all messed up and there will be blocking/banding etc. You can get the latest version of CCCP with the special 10-bit decoding build from here: http://www.cccp-project.net/beta/

[madshi]

I absolutely can't recommend usage of the 10-bit system yet with MPC-HC, until:
1.- A real ffdshow beta comes out that can output at least one of the recommended 10- or 16-bit formats for DirectShow to the player: http://msdn.microsoft.com/en-us/library/bb970578%28v=VS.85%29.aspx .
(Currently all output is rounded to 8-bit formats, so there's no gain by the 10-bit precision yet.)
2.- At least one of the internal renderers has been updated to become able to take in and mix the 10- or 16-bit formats.
3.- At least some quality and reliability testing has been done.
FWIW, both the LAV Video and madVR internal decoders are already able to fully decode 9bit and 10bit h264 and pass it on in full quality to madVR. Works perfectly fine here with all the 9bit, 10bit and 4:4:4 h264 samples I have tried.

[JanWillem32]

Once you pass step 3, then it's fine, of course. I was mostly warning about the "still untested with this" part. I've seen too many jumping on this item too soon.
To point at my later posts; I don't know what's worse, dithering to 8-bit or rounding to 8-bit and something about getting getting studios finally interested in encoding better consumer-level video than 8-bit 4:2:0 stuff (as in: don't disappoint them).
In the mean time, progress is coming along fine on more than one side, I'm only a bit unlucky to be stuck with the EVR and VMR-9 mixers that apparently call the video card driver for support of every DirectShow format (which is pretty limited, for what I've seen).

[madshi]

I don't know what's worse, dithering to 8-bit or rounding to 8-bit
Rounding to 8bit is a lot worse, IMHO. If the original 10bit encoding actually contains smooth 10bit content (which is probably very rare, though), dithering it down to 8bit will preserve the smoothness and avoid banding. Rounding down to 8bit will introduce banding artifacts. Of course, it the original source was 8bit and was just encoded as 10bit, the difference between rounding and dithering will be much lower. I'd still prefer dithering, though. In any case, the combination of LAV Video + madVR, or madVR alone, won't either dither down nor round down the decoded 10bit data. Instead it's passed in full bitdepth to the processing chain. Dithering is then only done at the very last step of the madVR rendering chain.

I'm only a bit unlucky to be stuck with the EVR and VMR-9 mixers that apparently call the video card driver for support of every DirectShow format (which is pretty limited, for what I've seen).
Yeah, I know, trying to make this all work with EVR and VMR9 is probably a major pain in the ***. There's a reason I decided to stay away from anything EVR/VMR9 when starting to write madVR. Of course you could try writing your own mixers, but if you do that, which part of EVR/VMR9 are you still using at all? Not much, I guess...

[nevcairiel]

In any case, the combination of LAV Video + madVR, or madVR alone, won't either dither down nor round down the decoded 10bit data. Instead it's passed in full bitdepth to the processing chain. Dithering is then only done at the very last step of the madVR rendering chain.

And if using LAV Video with EVR or any other renderer that only supports 8-bit input, dithering is applied, its not rounded. :)

Speaking of the whole topic, is there a way to indicate 9-bit in a media type, like using P010 and somehow indicating that only 9 bit are valid? Every value will be left-shifted to fit 10-bit anyway, but would it be useful to indicate that only 9-bit are actual data?

[madshi]

Speaking of the whole topic, is there a way to indicate 9-bit in a media type, like using P010 and somehow indicating that only 9 bit are valid? Every value will be left-shifted to fit 10-bit anyway, but would it be useful to indicate that only 9-bit are actual data?
Yes, it might be useful. Not right now, but maybe in the future. With VIDEOINFOHEADER2 I believe you can't transport this information. But we added this information capability to the "Open Media Format":

http://forum.doom9.org/showthread.php?t=156051

[JanWillem32]

Yeah, I know, trying to make this all work with EVR and VMR9 is probably a major pain in the ***. There's a reason I decided to stay away from anything EVR/VMR9 when starting to write madVR. Of course you could try writing your own mixers, but if you do that, which part of EVR/VMR9 are you still using at all? Not much, I guess...The function-specific library's loaded for the 3 main custom renderers in MPC-HC are: mfplat.dll (Media Foundation enumeration), Quartz.dll (DirectShow parts), DXVA2.dll (to interface the virtual DXVA2 driver), avrt.dll (thread scheduler) and dwmapi.dll (desktop composition).
EVR Sync may use some more functions for its special sync clock, but otherwise, the 3 main custom renderers are normal DirectX 9 renderers (although the 3D part of it is pre-multiplied to become mostly 2D).
I can indeed live without evr.dll and the VMR-9 parts of Quartz.dll. Having to rely so heavily on semi-hardcoded mixing by the video card's drivers is annoying to say the least. I've written plenty of filters for the mixing parts already (deinterlacing, chroma resizing, color controls, color matrixing and such). It's just that I'm still very new at this. I've started programming for DirectX 10 less than 2 years ago (with a very controlled renderer environment and plenty of templates to use). The DirectX 9 downgrade isn't a big problem, but the DirectShow and Media Foundation parts still confuse me a lot. The fact that the code for handling the mixer parts is pretty much the same as the reference Microsoft code samples doesn't help much either. Next, I'm also scheduled to merge the 3 renderers into 2 (a light one and a heavy one)...
I must say, you're in a pretty lucky position in these aspects.

[madshi]

I can indeed live without evr.dll and the VMR-9 parts of Quartz.dll. Having to rely so heavily on semi-hardcoded mixing by the video card's drivers is annoying to say the least. I've written plenty of filters for the mixing parts already (deinterlacing, chroma resizing, color controls, color matrixing and such). It's just that I'm still very new at this. I've started programming for DirectX 10 less than 2 years ago (with a very controlled renderer environment and plenty of templates to use). The DirectX 9 downgrade isn't a big problem, but the DirectShow and Media Foundation parts still confuse me a lot. The fact that the code for handling the mixer parts is pretty much the same as the reference Microsoft code samples doesn't help much either. Next, I'm also scheduled to merge the 3 renderers into 2 (a light one and a heavy one)...
I must say, you're in a pretty lucky position in these aspects.
Yeah, not having to deal with any VMR/EVR stuff makes rendering related things easier for me. However, the DirectShow framework complexity is quite problematic for me, too.

[Fadeout]

Is there a version of these codecs that can work on MPC-HC 64bit?

[ForceX]

No. If you need a 64 bit decoder for H.264 Hi10P, you can use LAVVideo decoder.

[JEEB]

Is there a version of these codecs that can work on MPC-HC 64bit?
Should be buildable in all theory for win64 as well, but I will not be compiling this. Pushed the sources for the 2011-07-30 CCCP release FFDShow-tryouts to the github (https://github.com/jeeb/ffdshow-tryouts/commits/blitzkrieg). The widening of the colorspace list from 32bit to 64bit was deemed too big of a change by Lord for not to have possible problems in it, so that was reverted for this patchwork.

9bit H.264 and related shouldn't crash -tryouts with this patch, and most (if not all) filters should work.

[ForceX]

10bit H.264 support has been included in the main ffdshow-tryouts batch, so x64 builds are now available.

[madshi]

Does ffdshow-tryouts output it as 10bit, or is it forcefully dithered down to 8bit output?

[ForceX]

Dithered. It's just the patch from CCCP's version.

[cyberbeing]

The only difference should be swscale scaling. FFDShow-Tryouts uses Bilinear and CCCP FFDShow uses Bicubic.

FFDShow's swscale dithering is a bit unique though, and can result in a different color hue than MPlayer2 swscale, ffmpegsource2 ordered(?) dithering, and madVR dithering (all three which are very close).

[clsid]

The custom stuff in ffdshow's swscale is for threaded resizing. The colorspace handling stuff is pretty much vanilla FFmpeg code.