madTestPatternSource - DirectShow YCbCr test pattern generator

[madshi]

Hey guys,

in order to test quality of YCbCr -> RGB conversion I developed a little source filter which creates 3 different native YCbCr 4:2:0 test patterns. Here's the download:

http://madshi.net/madTestPatternSource.zip

The following 3 source files are contained in the zip:

(1) colors.ytp

http://madshi.net/ytp-colors.png

This one shows an X/Y color gradiant. The colors vary with runtime. Brightness is constant.

(2) grayramp.ytp

http://madshi.net/ytp-grayramp.png

Shows a gray ramp. Each gray color is shown in 16 pixel columns. The brightness of the ramp varies with runtime.

(3) smallramp.ytp

http://madshi.net/ytp-smallramp.png

Shows a static small black/white ramp from YCbCr 0 to 255. Each gray value is only shown in one column. Consequently the width of this test pattern is exactly 256 pixels. The purpose of this pattern is to enlarge it to fullscreen to check whether scaling and YCbCr -> RGB conversion work well together to produce a smooth final result.

----------------------

The screenshots are taken from ffdshow's high quality YCbCr -> RGB conversion (video input levels -> PC output levels). As you can see in screenshots (1) and (2), the results are not pretty. This is caused by ffdshow rounding down its internal 10bit processing results to 8bit. Good results can only be achieved with these test patterns, if higher than 8bit processing is used, and if the final processing result is then dithered down to the output bitdepth. ATI's VMR9 processing produces slightly better results for me, but it's not really good, either.

[honai]

Very interesting, thanks!

Two questions:

(1) How would we know that the GPU driver is not applying any post-processing to the (RGB) video image?
(2) Also, doesn't Vista's built-in color correction (present in EVR) enter the equation here?

It might be worth mentioning that the display is the most significant factor in judging the picture, i.e. regardless of the setup of your processing chain an 6/8-bit laptop display, a CRT display, a half-toning plasma set, an LCD set might all yield totally different visible results.

So how do we normalize the test setup to get reliable results?

[madshi]

(1) How would we know that the GPU driver is not applying any post-processing to the (RGB) video image?
Depends. If you feed the GPU YCbCr, it will do all sorts of processing. If you feed it RGB, usually it doesn't. There's no guarantee for that, of course. Probably the best solution would be to pretend to be a game rendering a game scene in RGB. That should make sure that the GPU doesn't try to smarten the image up by applying some fancy video processing. I believe Haali's Video Renderer is based on this idea.

(2) Also, doesn't Vista's built-in color correction (present in EVR) enter the equation here?
If you add further processing steps to the data, things can probably only get worse, because we're talking about problems caused by too low bitdepth processing. So if there are problems visible in XP or with VMR9, I wouldn't expect better results with activated color correction.

It might be worth mentioning that the display is the most significant factor in judging the picture, i.e. regardless of the setup of your processing chain an 6/8-bit laptop display, a CRT display, a half-toning plasma set, an LCD set might all yield totally different visible results.

So how do we normalize the test setup to get reliable results?
Well, we're not talking about things like different gamma curves here. If you look at the screenshots above, the banding visible in the screenshots is produced by neighbor blocks having the exact same color when they shouldn't. Such a thing does not really depend on the display. That's a clear consequence of too low processing bitdepth.

I'd suggest that you try the test patterns yourself. Compare ffdshow's YCbCr -> RGB conversion with that of your graphics card. I'm sure you'll see noticeable differences. On the same display, of course. BTW, the artifacts are even more visible in full screen motion compared to a small static screenshot.

[Beliyaal]

I can't get the graph in MPC-HC to render. Does it require ffdshow to accept raw formats?

madTestPatternSource (smallramp.ytp)::output

Media Type 0:
--------------------------
Video: YV12 256x200

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 0
cbFormat: 88

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 0

BITMAPINFOHEADER:
biSize: 40
biWidth: 256
biHeight: 200
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 76800
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 28 00 00 00 00 01 00 00 c8 00 00 00 01 00 0c 00 (.......È.......
0040: 59 56 31 32 00 2c 01 00 00 00 00 00 00 00 00 00 YV12.,..........
0050: 00 00 00 00 00 00 00 00 ........

[madshi]

It works for me with and without ffdshow. VMR9 accepts it directly on my PC. I had compared the mediatype data to some decoder and made sure I output the same data. So I really wonder why it's not working for you. Can't you connect in GraphEdit, either?

[Beliyaal]

It works for me with and without ffdshow. VMR9 accepts it directly on my PC. I had compared the mediatype data to some decoder and made sure I output the same data. So I really wonder why it's not working for you. Can't you connect in GraphEdit, either?

I think you might want to fill in the VIDEOINFOHEADER. And even better provide a VIDEOINFOHEADER2.

The input to the EVR when going throgh ffdshow has the rcSource and rcTarget filled in:

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

[madshi]

I've uploaded a new build with more complete mediatype fields (same link as before, version number 1.1.0.0). VIDEOINFOHEADER2 should not be necessary. Many decoders only provide VIDEOINFOHEADER.

[yesgrey]

Here are 4 test images with the smallramp test pattern.
9734
I have used MPC-HC with Haali renderer. All images were grabbed with PrtSc and pasted to Microsoft Photo Editor and saved in png format.
Tests performed, sorted by quality, from top to bottom:
1) t3dlut YCbCr->RGB dithering 16bit to 8bit + Haali resize
2) ffdshow resize (bicubic) + t3dlut YCbCr->RGB dithering 16bit to 8bit
3) ffdshow YCbCr->RGB + Haali resize
4) ffdshow resize (bicubic) + ffdshow YCbCr->RGB

As you could see by comparing the images, the results when using Haali renderer's resize are better, because ffdshow resize outputs 8bit per component results, while Haali renderer uses the shaders for resizing, which should be using 32bit FP per component. The best results are when using t3dlut to perform the YCbCr conversion and dithering from 16bit to 8bit, using a 3dlut file with an output bit depth of 16 bit per component.
The dither is the better improvement observed, but the haali resizing also has a slightly edge over the ffdshow resize.

The other tests will follow...;)

[madshi]

I can't get the graph in MPC-HC to render.
Argh, you were right, I didn't notice that on my PC there was always an intermediate filter in between! I've fixed this problem now in the latest build:

http://madshi.net/madTestPatternSource.zip

[mark0077]

So how is evr-cp bicubic resize... I assume because this is done at the graphics card, it depends on the card / its drivers?

Maybe someone could update ffdshow resize to bring it upto par. yesgrey3, are you saying even the newer versions of ffdshow havn't got good yCbCr->RGB conversions. I thought the newest versions used 16bit but maybe its 12bit... Maybe this t3dlut could replace the older ffdshow lookup table / code.

[madshi]

So how is evr-cp bicubic resize... I assume because this is done at the graphics card, it depends on the card / its drivers?

Maybe someone could update ffdshow resize to bring it upto par. yesgrey3, are you saying even the newer versions of ffdshow havn't got good yCbCr->RGB conversions. I thought the newest versions used 16bit but maybe its 12bit... Maybe this t3dlut could replace the older ffdshow lookup table / code.
Don't worry, there will very soon be a new alternative... ;)

Anyway, to answer one of your questions: haruhiko_yamagata has been so kind to let me know that ffdshow actually uses 10bit for color space conversions. However, the final calculation result is currently truncated down to 8bit.