ffdshow tryouts project: Discussion & Development

[fastplayer]

since x/h264 multiple core acceleration is about to come soon, would it also be possible to do the same for ffdshow using VC-1 via libavcodec?
Post your request here:
http://ffmpeg.mplayerhq.hu/mailinglists.html

[Thunderbolt8]

where exactly there? dont seem to find a kind of forum or email adress

[Leak]

where exactly there? dont seem to find a kind of forum or email adress
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[haruhiko_yamagata]

In DirectShow the color matrices are specified using VideoInfoHeader2 (http://msdn2.microsoft.com/en-us/library/ms787914.aspx) and DXVA_ExtendedFormat (http://msdn2.microsoft.com/en-us/library/ms796493.aspx). I wish I could tell you for sure whether the latter can be used even when DXVA decoding isn't used, but if you're interested in implementing it, you could try emailing askdshow@microsoft.com for exact information.
There was a patch to do this with VIH2, afaik, but renderers mostly ignored it, which is why it isn't presently used.Does EVR work with VIH2 color primaries information? If it works, it's worth implementing.

[Kado]

Bin:
http://rapidshare.com/files/60036197/ffdshow_rev1500_20071003_xxl.exe.html

This build only has the YCbCr <-> RGB conversion options patch and not the h264 multi-core patch right? Hope to see the multi-core patch integrated soon in the try-outs.

[Wilbert]

Could you post the values used in colormatrix and the ones i posted in this thread (a few posts back; quoted from avisynth.org)?

In Colormatrix is GBR order (file Colormatrix.h):
+0.7152, +0.0722, +0.2126, // Rec.709 (0)
-0.3850, +0.5000, -0.1150,
-0.4540, -0.0460, +0.5000,


Charles Poynton's ColorFAQ (the same in the avisynth link):
RGB ITU.BT-709 HDTV -> YUV
kr = 0.2125; kg = 0.7154; kb = 0.0721;
Matrix should be:
0.2125 0.7154 0.0721
-0.114506 -0.385494 0.5000
0.5000 -0.454222 -0.045778

no.

damn:
[1] reports kr = 0.2125, kg = 0.7154, kb = 0.0721
[2] and [3] report kr = 0.2126, kg = 0.7152, kb = 0.0722


[1] MPEG-2_13818-2.pdf (page 56)
[2] ITU-R_BT.709.pdf (page 3)
[3] Charles Poynton's ColorFAQ (http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html) (section 8)

Since the mpeg-2 specs (in [1]) are referring to Rec.709, i guess they are wrong.

So the correct values are "kr = 0.2126, kg = 0.7152, kb = 0.0722" and avisynth.org should be corrected.

[Wilbert]

@haruhiko_yamagata,

The correct formulas for YCbCr [16,235] <-> RGB [0,255] (Rec.709) are:
Code:

R=1.164*(Y-16)+1.792*(V-128)
G=1.164*(Y-16)-0.2129*(U-128)-0.5326*(V-128)
B=1.164*(Y-16)+2.113*(U-128)


Thus the corrected values are:

R = 1.1644*(Y-16) + 1.7927*(V-128)
G = 1.1644*(Y-16) - 0.2132*(U-128) - 0.5329*(V-128)
B = 1.1644*(Y-16) + 2.1124*(U-128)

[yesgrey]

Wilbert,

If you see Charles Poynton's ColorFAQ.pdf file, question 9, the coefficients are what I said. Now which Poynton's coefficients are correct?

Maybe he have saw [2] and corrected it only in the html version of his ColorFAQ...

[yesgrey]

haruhiko,
going a little back at the custom matrix request...
I have went through the other option of using avisynth for it. Right now, I have it working the way I described here (http://www.avsforum.com/avs-vb/showthread.php?t=912720).

I know the biggest issue was the rewriting of a big portion of code in ffdshow, due to the need of using all matrix coefficients.
So, why not using the code in avisynth 2.6 for the YUV<->RGB conversion? It already uses all matrix coefficients. You can see here (http://forum.doom9.org/showthread.php?t=127575) my discussion with IanB (one of avisynth developers) about it.

The work already done is great, and I believe it's almost all that most people need, but if the custom matrix could be added with a little extra work, it would be nice.:)

[iron2000]

The version number in the "About" screen(using clsid's build) has remained unchanged at 1471.

Not a major problem, just want to inform.

[morphx2]

Can anyone share with me some good hd-dvd settings to use with ffdshow tryout? I am totally lost on what options to pick

[Rash]

As a general rule of thumb, decoders should never be doing luma remapping but should instead pass untouched YUV video to the renderer along with correct metadata.
Well, either EVR ignores these metadata or absolutely no decoder supports them (and that includes Vista WMV DMO Decoder). I have never got 0-255 from videos using WMP11 or MPC with EVR. In fact, I am really disappointed with videos on Windows Vista. Fortunately we have Haali Renderer or EVR Custom to do the job. What is interesting, though, is that Windows Media Center plays the videos fine, with correct colors all time. Maybe it doesn't use EVR, I don't know.

[2ge]

Hello all,

FYI I just posted Download/Upload subtitles with OpenSubtitles.org using ffdshow (http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=524) (+poll question). Maybe it interests you and we can talk about it. I am not sure, where correct URL is for ffdshow talking, so I am trying here too - so we can have more oppinions.

Thank you.

[haruhiko_yamagata]

"16-235" RGB is typically referred to as "Studio RGB", whereas the "0-235" RGB is referred to as "PC" or "Computer RGB". These are the names used in Charles Poynton's "Digital Video and HDTV Algorithms and Interfaces" book (ch.25).OK, "Studio" would be more formal, but it's just a dialog. "Standard" is more familiar in my opinion.

[haruhiko_yamagata]

I know the biggest issue was the rewriting of a big portion of code in ffdshow, due to the need of using all matrix coefficients.
So, why not using the code in avisynth 2.6 for the YUV<->RGB conversion? It already uses all matrix coefficients. You can see here (http://forum.doom9.org/showthread.php?t=127575) my discussion with IanB (one of avisynth developers) about it.OK, it shouldn't be too hard. But I have something to do before it, maybe later if I have time.

[yesgrey]

OK, it shouldn't be too hard. But I have something to do before it, maybe later if I have time.

Ok, no hurry. It's just that would be great to have all the functionallity in ffdshow. If you decide to do it let me know so we can discuss some of the interface details about it.

Thanks.

[Dr Pizza]

Can anyone suggest a reason why DirectShow is preferentially using "AVI Decompressor" (VfW wrapper) to decode video using ffdshow, even though ffdshow has a higher merit?

If I add ffdshow to the filter graph manually, it works just fine... it's just the filter graph manager won't add it unless I disable VfW.

[Wilbert]

Wilbert,

If you see Charles Poynton's ColorFAQ.pdf file, question 9, the coefficients are what I said. Now which Poynton's coefficients are correct?

Maybe he have saw [2] and corrected it only in the html version of his ColorFAQ...
Yes, that's a good one. I assume those given in the Rec.709 standard are correct. Perhaps the best is to send him an e-mail.

It's also possible that the coefficients are changed in Rec.709 (you can find multiple revisions of the standard on the ITU site). I will try to get the first version and look up the coefficients. As a reference to those coefficients, it gives the following note: "The coefficients for the equations have been calculated following the rules laid down in SMPTE RP177-1993." Perhaps it's possible to get that document somewhere.

[yesgrey]

Well, the pdf version is from 1997 and the html and txt version are from 2006. Maybe are both correct. In 1997 those were the coefficients and since 2006 the coefficients have been slightly changed?... I will try mailing him about it.

Edit: mail sent.

[Kado]

Question regarding the new RGB conversion... I use haali renderer with bt.709, I should use the same spec in ffdshow right? Or that does only affect if the output is RGB? (I generally use YUV2 and not RGB32).

[yesgrey]

The bt.709 or bt.601 and the PC or TV levels options in haali renderer only affects the image when you input YUY2 to it, because it defines the coefficients used for the YUV->RGB selection.

When you convert YUV->RGB in ffdshow, haali renderer will not need to convert it to RGB, so does not matter what you select in bt or in the levels section.

Basically you will decide where in your PC you want to perform the YUV->RGB conversion. In your CPU (ffdshow) or in your GPU (haali renderer).

[haruhiko_yamagata]

Question regarding the new RGB conversion... I use haali renderer with bt.709, I should use the same spec in ffdshow right? Or that does only affect if the output is RGB? (I generally use YUV2 and not RGB32).As for ffdshow settings, please read the latest document (http://ffdshow-tryout.sourceforge.net/html/en/cspOptions.htm). I have added These settings are used only when ffdshow is doing YCbCr <-> RGB conversion. In other words, if you are playing mpeg video and the output color space is YV12 or YUY2, these settings won't be used.

[Kado]

Hum, guess I'll put my GPU to some use to save some CPU time, or maybe not! Thanks for the tips guys.

[Joniii]

I have some problems with subtitles in ffdshow tryouts. I would like to use ffdshow for 1080p .ts files, but haven't quite get it working.

I have CoreAVC decoding h.264 and MS VC-1 decoding VC-1.

When I install ffdshow, I only select divx, xvid and subtitles. Then from the ffdshow settings codec page I select Raw video -> all supported and enable in WMP11. Now ffdshow loads subtitles for H.264 and VC-1 movies but the picture is screwed, I don't really know how to describe it, it has lots of horizontal lines and it shows image three times side by side. When twiddling with process whole image check box in the subtitles page, everithing worked ok couple of times but when I start WMP again then picture is a mess again.

Is there anything I can do in the ffdshow settings to fix this or something you could fix in the code?

[Inventive Software]

I fancy a real challenge. How would people think about me adding *some* minimal DXVA support to ffdshow?

[haruhiko_yamagata]

I have some problems with subtitles in ffdshow tryouts. I would like to use ffdshow for 1080p .ts files, but haven't quite get it working.

I have CoreAVC decoding h.264 and MS VC-1 decoding VC-1.

When I install ffdshow, I only select divx, xvid and subtitles. Then from the ffdshow settings codec page I select Raw video -> all supported and enable in WMP11. Now ffdshow loads subtitles for H.264 and VC-1 movies but the picture is screwed, I don't really know how to describe it, it has lots of horizontal lines and it shows image three times side by side. When twiddling with process whole image check box in the subtitles page, everithing worked ok couple of times but when I start WMP again then picture is a mess again.

Is there anything I can do in the ffdshow settings to fix this or something you could fix in the code?It should be a bug but I cannot reproduce.
What is the subtitle (srt/ssa/ass/vobsub...)?
Is AviSynth checked?
What is the output color space?

[Joniii]

It should be a bug but I cannot reproduce.
What is the subtitle (srt/ssa/ass/vobsub...)?
Is AviSynth checked?
What is the output color space?
Avisynth is disabled, subtitle is .srt. As for color space I have no idea, whatever ffdshow uses by default. I'm using latest nightly build.

Other info I can think of:
OS is Vista Home Premium (clean install yesterday), I installed Only CoreAVC 1.5, Haali Media Splitter 1.7.189.11, AC3Filter 1.46 and ffdshow (Divx,Xvid,Mpeg2 and subtitles). Im using 1920x1080@60Hz with newest catalyst drivers into 55" telly (DVI->HDMI).

I just noticed that Media Player Classic is not affected by this, only WMP11 and Media Center (I ran MplayerC with all it's internal codecs/filters disabled so that it used ffdshow).

[LigH]

@ I.S.:

I often wondered if implementations need to be so GPU specific. Some DVD players (from my experience) only work well on ATI, others only on nVidia... If your "some" means a rather independent, generic level - sure, try it! And tell us up to which stage of the video playback your code would accellerate.

[Inventive Software]

It shouldn't have to be GPU specific. That's what DXVA was designed for; one API for all graphics solutions. The hardware has to be compatible, obviously, and is partly where I fall down at the first hurdle, but I'm gonna look at the specs for DXVA 1 and 2 and see what could be off-loaded to the GPU to speed things up. First target, I think, is post-processing and de-interlacing.

Ultimate target is MPEG-2, VC-1 and, wait for it, H.264 decoding on the GPU. But that is a LONG way off, think a couple thousand ffdshow-tryouts revisions away. ;)

[haruhiko_yamagata]

I just noticed that Media Player Classic is not affected by this, only WMP11 and Media Center (I ran MplayerC with all it's internal codecs/filters disabled so that it used ffdshow).Raw video processing in WMP11 and Media Center is experimental and not very stable. Currently it does not work for me. I hope albain can fix it.

[Dr Pizza]

It shouldn't have to be GPU specific. That's what DXVA was designed for; one API for all graphics solutions. The hardware has to be compatible, obviously, and is partly where I fall down at the first hurdle, but I'm gonna look at the specs for DXVA 1 and 2 and see what could be off-loaded to the GPU to speed things up. First target, I think, is post-processing and de-interlacing.

DXVA doesn't really work like that.

DXVA allows for a number of specific operations to be handled in hardware; bDXVA_Func can take 4 values, specifying one of { decompression, alpha blended data loading, alpha blended composition, resampling }. These values each have a number of sub-functions; for example, for decompression you can choose iDCT, deblocking, and macro block motion compensation, amongst other things.

This has two repercussions. One, DXVA must be integrated quite tightly into your MPEG-2 decoder; the operations it can accelerate are all low-level MPEG-2 operations, and the decoders must call the right accelerators at the right time. ffdshow's decoders don't appear to me to be readily amenable to that kind of modification; because ffdshow is essentially a DirectShow wrapper around a bunch of non-DirectShow codecs, the codecs themselves aren't really structured in such a way as to allow easy integration of DXVA support. If ffdshow had its own codecs designed from the ground up to be DirectShow filters then it might be in a slightly better position for this kind of work, but at the moment, it's really a bunch of pretty disparate C and C++ codebases, none of which are engineered for this kind of thing.

Two, DXVA isn't a mechanism for arbitrary programming of the video hardware to assist in video decoding. The available functions are all pre-defined (there's no (standard) way to provide extra decompression facilities, for example, which is why I believe things such as the PureVideo H.264 acceleration require special PureVideo-aware decoders--DXVA 1 doesn't have the right primitive functions), and I think for the most part optional (you can have DXVA hardware that can do some things but not others).

The only post-processing step that looks like it might fit reasonably nicely into DXVA is resizing; DXVA does have HW-accelerated resampling. I don't know, however, if it's appreciably faster than doing it on the CPU, nor do I know if it's widely supported. And it's quite possible that it's not sufficiently versatile to be a replacement for the post processing code anyway.

I think a more fruitful way to perform hardware-accelerated post-processing would be to use VMR9 renderless with a custom AP, and then use shaders to transform the video. I suspect that in practice even this would be quite limited, but it's still a more general mechanism than DXVA.

[SBeaver]

I would really like a new x64 build. The last one is from july and it lacks a lot of useful features.

[Dr Pizza]

Try http://rapidshare.com/files/61177074/ffdshow_rev1505_20071004_x64.exe.html

[SBeaver]

Try http://rapidshare.com/files/61177074/ffdshow_rev1505_20071004_x64.exe.html

thanks a lot :thanks:

There seems to be something that differs though, I'm not sure why but h264 decoding is somehow slowed down compared to the 32bit version I have.
On a particular video I get almost equal cpu usage, but the 64bit can't keep up at all and suffers from delays just as if there wasnt enough cpu power, but it stays around 60% for both builds (64 and 32)
Is this something to do with the new multicore enhancements?
Perhaps that patch was not applied to the build you gave me.
I have a dualcore opteron.
It's still nice to have the new color settings and all, great for all hd videos I watch.

[clsid]

The 64-bit version is slower because it doesn't use any of the fast handwritten assembly code that the 32-bit version has. That is due to the fact that there is no proper 64-bit version of mingw GCC yet. So MSVC is used which doesn't support the inline assembly stuff.

[akupenguin]

The only post-processing step that looks like it might fit reasonably nicely into DXVA is resizing; DXVA does have HW-accelerated resampling. I don't know, however, if it's appreciably faster than doing it on the CPU, nor do I know if it's widely supported. And it's quite possible that it's not sufficiently versatile to be a replacement for the post processing code anyway.
Who does scaling on the CPU? Hardware scaling is part of any good renderer, it's not specific to DXVA. The only potential reason to use software scaling is if you want lanczos or something instead of whatever algorithm your GPU supports.

[SBeaver]

The 64-bit version is slower because it doesn't use any of the fast handwritten assembly code that the 32-bit version has. That is due to the fact that there is no proper 64-bit version of mingw GCC yet. So MSVC is used which doesn't support the inline assembly stuff.

maybe generally, but in this case my cpu is not fully utilized so it's probably not using both cores.

[foxyshadis]

Who does scaling on the CPU? Hardware scaling is part of any good renderer, it's not specific to DXVA. The only potential reason to use software scaling is if you want lanczos or something instead of whatever algorithm your GPU supports.

Maybe the 6-tap qpel step? I think it's stretching shaders a bit too far though, since even 2-tap bicubic is pushing them and no one's done 3/4-tap lanczos yet.

If not then yes, entirely true.

[Inventive Software]

I have read some of the DXVA articles on MSDN, and it says that it can off-load the de-interlacing, alpha-blending, ProcAmp picture control, motion compensation (which seems rather important), encryption and content protection through the Certified Output Protection Protocol. I'll conveniently forget the last 2 for now. ;)

However, I have found that not all of the decoding process can be off-loaded, but it really does depend on display drivers supporting DXVA. So, when I get round to codecs, H.261 and MPEG-1 will be my first targets because they're simpler models, H.261 being even simpler than MPEG-1.

[akupenguin]

Maybe the 6-tap qpel step?
You can't do motion compensation on the GPU unless you do everything other than CABAC and IDCT on the GPU, because copying data back from GPU to main memory is slow.
This is no different from mpeg2/mpeg4asp. It's just that in mpeg2, "everything other than bitstream parsing and IDCT" leaves only motion compensation, whereas in h264 there's other stuff to be done.
I think it's stretching shaders a bit too far though, since even 2-tap bicubic is pushing them and no one's done 3/4-tap lanczos yet.
bilinear is 2-tap, bicubic is 4-tap, biquintic (h264) is 6-tap, lanczos-3 is 6-tap, lanczos-4 is 8-tap.
The reason linear/cubic/quintic are 2/4/6 taps is that it takes 2 points to specify a line, 4 points to specify an order 3 equation, 6 points to specify an order 5 equation, etc.
Nobody uses odd tap numbers (besides nearest-neighbor, which is 1-tap). When interpolating between x and x+1, which pixel would be the third, x+2 or x-1?

[Dr Pizza]

There seems to be something that differs though, I'm not sure why but h264 decoding is somehow slowed down compared to the 32bit version I have.
On a particular video I get almost equal cpu usage, but the 64bit can't keep up at all and suffers from delays just as if there wasnt enough cpu power, but it stays around 60% for both builds (64 and 32)
Is this something to do with the new multicore enhancements?
Perhaps that patch was not applied to the build you gave me.
I have a dualcore opteron.
It's still nice to have the new color settings and all, great for all hd videos I watch.
I didn't apply any patches specifically, it's just a recent SVN build, so I don't know what the state of play is on that front.

There's no inline asm support in MSVC++ for x64 builds (and no adequate Win64 gcc toolchain), so that would probably explain much of the slowdown. Any asm portions that are compiled externally (with yasm) should be included, however.

[Dr Pizza]

I have read some of the DXVA articles on MSDN, and it says that it can off-load the de-interlacing, alpha-blending, ProcAmp picture control, motion compensation (which seems rather important), encryption and content protection through the Certified Output Protection Protocol. I'll conveniently forget the last 2 for now. ;)
Deinterlacing and procamp are both handled by VMR already; ProcAmp doesn't even have a user API, I don't believe (there's a driver-side portion, of course, for VMR to talk to, but nothing exposed to use it). i.e. as long as you feed interlaced video into VMR, VMR will use HW deinterlace; as long as you feed YUV into VMR, VMR will use HW YUV->RGB; as long as you use VMR ProcAmp to resize video, VMR will use HW resizing.

If you want to incorporate them earlier into the process (i.e. if you want to colour space convert/deinterlace/resize by hand) then you'll have to restructure the code accordingly, and you can't do everything because there's no (proper) way to call the ProcAmp acceleration.

However, I have found that not all of the decoding process can be off-loaded, but it really does depend on display drivers supporting DXVA. So, when I get round to codecs, H.261 and MPEG-1 will be my first targets because they're simpler models, H.261 being even simpler than MPEG-1.
DXVA's primary target is MPEG-2. That's what I'd start with.

[Dr Pizza]

Who does scaling on the CPU?
libmplayer's swscale.c, which is used by the ffdshow resize postproc filter?

Hardware scaling is part of any good renderer, it's not specific to DXVA.
The way VMR and EVR do hardware scaling is through DXVA 1 and 2. I have no idea about third-party renderers, as I don't use any. I suppose they might use shaders and stuff instead of DXVA, though I don't see why they would; there's dedicated motion video hardware on (most) modern GPUs for a reason.

[foxyshadis]

bilinear is 2-tap, bicubic is 4-tap, biquintic (h264) is 6-tap, lanczos-3 is 6-tap, lanczos-4 is 8-tap.

Ah, if you mean it that way then yes. Some academic papers will count the taps in only one direction rather than both, and I might just always think of it that way because those are the ones I found first. Is it more common to count both positive and negative?

The way VMR and EVR do hardware scaling is through DXVA 1 and 2. I have no idea about third-party renderers, as I don't use any. I suppose they might use shaders and stuff instead of DXVA, though I don't see why they would; there's dedicated motion video hardware on (most) modern GPUs for a reason.
Overlay on a Matrox Mystique will give you hardware scaling too, and it'll probably be the same bilinear scaling as an 8800GTX. (It'd be pretty sad if a 10-year-old card used bicubic when modern ones won't, though.) DXVA has to use a different code path since the video isn't uploaded as a texture, but they're the same operation with the same near-zero cpu cost.

[Dr Pizza]

Overlay on a Matrox Mystique will give you hardware scaling too, and it'll probably be the same bilinear scaling as an 8800GTX. (It'd be pretty sad if a 10-year-old card used bicubic when modern ones won't, though.)
Wouldn't know; I haven't used overlay for many years.

DXVA has to use a different code path since the video isn't uploaded as a texture, but they're the same operation with the same near-zero cpu cost.
Yes, if you let the renderer do the resize and if the renderer HW accelerates (e.g. VMR/VMR 9 with DXVA, EVR with DXVA 2, and apparently overlay) then it's done with negligible CPU cost. But that's surely not the point of discussion, since that resizing is already HW accelerated, so there's no work to be done on that front.

I mean, the candidates are surely augmenting the decoders (especially MPEG-2, but also VC-1 and H.264, especially if DXVA 2 is targetted) with HW acceleration, and augmenting some of the postprocessors (especially deinterlace, resizing, and colour space conversion) with HW acceleration? The latter doesn't seem immediately beneficial for most scenarios, since it happens automatically when using a suitable renderer, and the former seems problematic due to the invasive nature of DXVA acceleration.

[akupenguin]

Some academic papers will count the taps in only one direction rather than both, and I might just always think of it that way because those are the ones I found first. Is it more common to count both positive and negative?
I've never heard it used as just one direction, other than in the names of lanczos-3 and lanczos-4. Counting all samples certainly seems more useful to me: While odd numbers aren't used for interpolation, they are used for other purposes. How would you call a 2nd derivative (-1 2 -1) filter? 1.5 tap?

[TheShadowRunner]

Hmm DXVA talk on a ffdshow thread... :D
I so wish someday i'll be able to use ffdshow for subs while offloading h264 decoding to the GPU..
Anyway, I would like to report a bug with 1080p/h264 for now ^^;

FFDshow builds 1508 and 1515 from CLSID are chocking quite heavily on this for some reason:
http://images.apple.com/movies/us/hd_gallery/gl1800/1080p/bbc-japan_1080p.mov

"Queue" is disabled. Not a CPU problem as it reaches 40% usage max on this clip. Cyberlink decoder in soft mode and coreavc play it perfectly.

Intel2180/Geforce8500

The chocking/slowdown is very apparent (frame freezes) when the first trees appear in the clip.
Later,

TSR

[oddball]

All the latest nightly builds have broken AC3 transcoding (6 channel AAC to 6 channel AC3 resampled and spat out at 48000 over SPDIF).

Going back to the stable build always fixes it as long as I set it to 'Any filter' at the output stage. If I set it to DirectSound ffdshow crashes. If I set to 'Any filter' in the nightly builds I get no AC3 output at all and still get the crash on DirectSound.

[Kado]

@TheShadowRunner

After some tests here's my conclusions:
with cyberlink's both the specified and achieved frame rates are 15fps and no shuttering (buffers totally used)
with coreavc v1.5 frame rates are at 30fps (buffers totally used)
with ffdshow the specified frame rate is 30fps but at some stages the video drops to 15 frames with some stuttering but not frozen frames (only 3 of 32 buffers are used probably because it does not have enough speed to keep them fully used)

cpu usage goes from 30 to 65% with ffdshow/cyberlink and 30 to 85% with coreavc.
I changed the file termination from mov to mp4 to use haali splitter.
you can see additional av info from the haali osd if you use the haali splitter and renderer.

used MPC HC 1.0.10.0, latest haali, ffdshow 1485(multi-core patched)/1515, coreavc1.5,cyberlink h264 decoder. Pentium D 3.6GHz/6800gs 163.71

[Rash]

Just a question. How do I enable the colorspace (YUV->RGB) conversion on ffdshow, so that the new color options are available?

I tried enabling the "High quality YV12 to RGB conversion" in the Output panel but I still get YV12 output.

Thank you.

ffdshow-tryouts rev 1515 clsid build (Oct 5th).