Color format / colorspace question

[hello_hello]

I've only got a fairly basic knowledge when it comes to color formats but I'm trying to work out why a certain video won't always display correctly when opened via AVIsynth using a basic DirectShowSource script. I've worked out it must relate to the width of the video being mod4 as if I resize to mod8 it always displays correctly. The video in question is Divx but I've experienced the same issue opening Xvid or x264 encoded video in the past.

The problem I'm having is sometimes when opening video with a mod4 or mod2 width via DirectShowSource it displays with the colors shifted... sort of like a black and white image with the colors overlayed incorrectly. I'm just curious why most of the time it displays correctly, but there's one particular playback combination where it doesn't.

The different ways I've tried opening the video:
Directly with MPC-HC, ffdshow decoding (output NV12): displays correctly.
Directly with MPC-HC, ffdshow decoding (forced output YV12): displays correctly.
Via a DirectShowSource script with MPC-HC, ffdshow decoding (output YV12): shifted colors.
Via a DirectShowSource script with MPC-HC, ffdshow decoding (forced output YUY2): displays correctly.
Via a DirectShowSource script with MPC-HC, ffdshow disabled (I assume Xvid is then decoding): displays correctly.
Opening the DirectShowSource script with MeGUI, ffdshow decoding (output YV12): displays correctly.

So basically using the DirectShowSource script, ffdshow and MPC-HC combination to open the video causes it to display incorrectly while any other way, including opening the same script using MeGUI with ffdshow outputting the same color format it's fine. Anyone with any ideas as to why?

Edit: I've found one more combination which causes the video to display incorrectly, and that's when opening it via a DirectShowSource script using VirtualDubMod with ffdshow decoding. Once again though, if I disable ffdshow it displays correctly and it only happens when using VirtualDubMod. If I open the same script using VirtualDub it displays properly whether ffdshow is decoding or not.

One other color format question while I'm at it.....
With ffdshow decoding and letting it choose the output color format automatically, it seems to always pick NV12 when opening a video directly using MPC-HC. However when I open a DirectShowSource script using MeGUI or VirtualDub, ffdshow automatically outputs YV12. So my second question is how does ffdshow decide which output format to use at any given time?

Thanks.

Edit 2: I thought I'd throw in a third question..... anyone know which video formats ffdshow's postprocessing filter will play with? When opening an Xvid/Divx encoded video the postprocessing filter works fine, but it doesn't seem to have any effect when ffdshow is decoding AVC or uncompressed video. Is that normal?

[jagabo]

The decoder and the program asking for the video negotiate the colorspace. Different programs will have different ask for different colorspaces.

It may be hard to tell if the post processing deblocking filters are working with AVC since h.264 decoding automatically performs deblocking.

[hello_hello]

I'm pretty sure the postprocessing filter wasn't working at all. If I enabled it's automatic luminance level fix, I could see it in action quite easily when ffdshow was decoding AVIs, but not when decoding anything containing AVC or uncompressed video.

[poisondeathray]

Looks like something wrong with your directshow filters

What happens when you render the file directly with graphstudio/graphedit ?

Are you using DXVA anywhere, or is this all software ffdshow decoding ?

How are you determining the output colorspace? Through the ffdshow osd or other method?

What if you add info() to the end of the avs script ? What does it report



What happens when you use FFVideoSource instead ? (add info() as well) a) through mpchc b) though megui preview

One difference between megui preview and mpchc is the renderer. mpchc will use whatever you have it set to. megui will use draw dib vfw

[jagabo]

I was able to duplicate the issue with ffdshow's post processor not working on h.264 and MPCHC. I made a very blocky Xvid AVI, then saved that blocky video as uncompressed YV12 AVI, uncompressed RGB24 AVI, x264 in AVI, and x264 in MKV. The post processing was very obvious (using the "only right half" setting) with everything except the two x264 files.

[hello_hello]

Looks like something wrong with your directshow filters

What happens when you render the file directly with graphstudio/graphedit ?

With ffdshow enabled: Test.avi -> AVI Splitter -> ffdshow Video Decoder -> WMR Video Renderer.

With ffdshow disabled: Test.avi -> AVI Splitter -> AVI Decompressor -> Color Space Converter -> WMR Video Renderer.

Either way, when using GraphEdit to display the video it displays correctly.
This video was originally an MKV. I had to remux it as an AVI for GraphEdit, so I assume that eliminates the Haali splitter.

Are you using DXVA anywhere, or is this all software ffdshow decoding ?

All software ffdshow decoding, given the video is DivX. My video card only decodes AVC.

How are you determining the output colorspace? Through the ffdshow osd or other method?
What if you add info() to the end of the avs script ? What does it report

I'm just hovering the mouse over the ffdshow icon in the system tray and looking at the tooltip. Adding info() to the avs script doesn't seem to reveal anything odd. It reports YV12 as does the ffdshow tooltip. I just tried opening the same script using both VirtualDub and VirtualDubMod and while the video displays correctly using the former and the colors are shifted using the latter, the info AVIsynth reports each time is identical.

What happens when you use FFVideoSource instead ? (add info() as well) a) through mpchc b) though megui preview

As it turns out, exactly the same thing happens but only when opening the script using MPC-HC or VirtualDubMod. MeGUI's preview and VirtualDub both display it correctly. I even tried two different FFMS2 versions given it's had a few bugs of late. Colorspace always reported as being YV12 by AVIsynth.
If I add mod8 resizing for the width to the script or crop to mod8 (same thing when using DirectShowSource) the video always displays correctly.

None of this is really any big deal, it's just that it's happened on the odd occasion.... enough now to make me curious as to why. So far it only seems to effect MPC-HC and VirtualDubMod. Given AutoGK uses VirtualDubMod to do the work I guess that's why I've come across this a few times.

Maybe someone could try opening a video via an AVS script with MPC-HC while adding mod4 resizing to see if the same thing happens? I just tried it using a mod16 avi and it does for me. Maybe it's something unique to XP for some reason? I tried WMR9, Overlay mixer and EVR and nothing changed.
And now I've tried the same thing using 2 different PCs running XP and the result was the same. The video only displayed incorrectly when opening the script using MPC-HC or VirtualDubMod.

Cheers.

[hello_hello]

I was able to duplicate the issue with ffdshow's post processor not working on h.264 and MPCHC. I made a very blocky Xvid AVI, then saved that blocky video as uncompressed YV12 AVI, uncompressed RGB24 AVI, x264 in AVI, and x264 in MKV. The post processing was very obvious (using the "only right half" setting) with everything except the two x264 files.

Thanks for testing. I thought it wasn't working when decoding uncompressed video either, but maybe I should check it again.

[jagabo]

Maybe they think h.264 doesn't need post processing deblocking because deblocking is a normal part of h.264 decompression.

[hello_hello]

The only reason it's an issue is because I'm re-encoding a couple of TV captures which I'm sure were somehow broadcast using the wrong levels, or the video was converted to TV levels twice before being broadcast.... or something.... only I didn't notice it at the time. TV -> PC stops the video from looking washed out, and using my DVD encodes of previous seasons as a reference, converting the levels definitely looks "correct".

But once I convert the levels there's blocking in a few places (probably due to the compression used for the original broadcast) which would normally not be noticed or not very offensive, which now is. I just realized though, my "uncompressed video" was actually compressed using HuffYUV, which no doubt makes me an idiot, so I'll try uncompressed now to see how I go.

Edit: I got it working but I give up. I tried all of ffdshow's deblocking methods but none of them agree with me as to what actually needs to be deblocked. By the time I've cranked the deblocking up enough to fix the problem areas the rest of the video is a blur, so given it's only happening in a few places I'll just live with it.

mplayer's deblocking.... anyone know why when "accurate deblocking" is disabled it messes with the colors so much?