DVD Quality - Some Tests

[mark0077]

I am trying to find the perfect dvd decoder + de-interlacer combination and have found some very interesting results.

============================================
My Setup Details
============================================
Vista 32bit SP1 -> Now running some tests under Windows 7 Beta
mpc-hc (1.2.958.0)
ffdshow (revision 2605)
evr-cp output renderer
Nvidia 7600GT (185.20 Drivers, NVidia-Control-Panel Dynamic Range: Full(0-255))
AMD Athlon 64 @ 2.7ghz
Decoders Tested: mpc-hc-libmpeg2, ffdshow-libmpeg2, ffdshow-libavcodec, cyberlink Video/SP Decoder (PDVD8), latest version as of Jan 1st)
All tests ran with evr-custom presentation unless specifically stated otherwise.

============================================
DVDs used to test and specifics on the individual tests used.
============================================

DVD 1: Star Wars Episode 3
Test 1 - Country Copyright Warning: Does the red text displaying the region name appear clear and not blocky. http://www.mediafire.com/?9g9ddlfzxhv
Test 2 - Actual Movie: Does it play at the correct frame rate of 25fps progressive with no de-interlacing performed.

DVD 2: Queen Greatest Hits Volume 1
Test 3 - Queen Menu Freezing: Can I run the mouse over various selections in the audio selection menu and not have it freeze up.
Test 4 - Queen Menu Highlight Appearance: Does the red rectangle that appears around the selection look like a rectangle or does it look messed up.
Test 5 - Queen Menu Highlight Position: Does the red rectangle appear over the underlying grey one perfectly or is it offset in any direction.
Test 6 - Actual Movie: Is it de-interlaced and does the de-interlacing look good.

DVD 3: Red-Dwarf Season 8 Disk 2:
Test 7 - Red-Dwarf Menu: Does it display at all, and is it usable if it displays.
Test 8 - Actual Movie: Is it de-interlaced and does the de-interlacing look good.

DVD 4: The World Is Not Enough:
Test 9 - Actual Movie: Does it play at the correct frame rate of 25fps progressive with no de-interlacing performed.

============================================
Output Colorspace Quality
============================================

Tests Used:
Test 1

Explanation:
The red writing in the copyright text in this test shows off inadequacies in colorspace conversion to your screens 32bit rgb output. Expected results are clear text with no jaggy edges or horizontal artifacts.

Notes:
All decoders used in test output yv12 by default, except for the cyberlink decoder which outputs yuy2.
Output colorspaces were set in ffdshow.
NVIDIA control panel dynamic range set to full (0-255).

Things I am looking at to decide which is best
1) Smoothness of the bottom of diagonal part of Red N in "Ireland"
2) Smoothness of the inside of last letter A or the last letter D in "Ireland"

Results (Format: ffdshow-output-colorspace = TEST RESULT)

EVR-CP (Dropping too many frames randomly for my liking)
libavcodec
yuy2 = BAD
yv12 = PERFECT
nv12 = BAD

libmpeg2
yuy2 = BAD
yv12 = PERFECT
nv12 = BAD

MPC-HC
yuy2 = BAD
yv12 = PERFECT
nv12 = BAD

EVR (Sometimes gets some aspect ratios wrong)
libavcodec
yuy2 = BAD
yv12 = PERFECT
nv12 = PERFECT

libmpeg2
yuy2 = BAD
yv12 = PERFECT
nv12 = PERFECT

MPC-HC
yuy2 = BAD
yv12 = PERFECT
nv12 = PERFECT

Haali Renderer (Sometimes complete freezes, and can't click menu items therefore can't navigate through DVDS or click on Play)
libavcodec
yuy2 = MACROVISION FAIL / SOMETIMES FREEZE
yv12 = Not Supported
nv12 = Not Supported

libmpeg2
yuy2 = MACROVISION FAIL / SOMETIMES FREEZE
yv12 = PERFECT
nv12 = PERFECT

MPC-HC
yuy2 = MACROVISION FAIL / SOMETIMES FREEZE
yv12 = PERFECT
nv12 = PERFECT

rgb32hq (ffdshow converts to rgh32) = VERY GOOD (some jaggies on the N are visible that arn't there with yv12 + yv12 chroma upsampler and less visible with yv12)
Avisynth ConvertToRGB32(matrix="rec601") = VERY GOOD (some jaggies on the N are visible that arn't there with yv12 + yv12 chroma upsampler and less visible with yv12)

Using vmr9 renderless or windowed was absolutely ridiculously blurry compared to evr so I'm not even going to go and test all of the combinations.

Comparison Images:

Zoomed Comparison
http://img131.imageshack.us/img131/916/comparisonzoomxr4.th.png (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png)

Individual Images:

ffdshow RGB32
http://img186.imageshack.us/img186/864/rgb32jk3.th.png (http://img186.imageshack.us/my.php?image=rgb32jk3.png)

ffdshow RGB32HQ
http://img255.imageshack.us/img255/2199/rgb32hqko8.th.png (http://img255.imageshack.us/my.php?image=rgb32hqko8.png)

Avisynth ConvertToRGB32(matrix="rec601")
http://img374.imageshack.us/img374/9992/avisynthqh3.th.png (http://img374.imageshack.us/my.php?image=avisynthqh3.png)

YV12
http://img187.imageshack.us/img187/3111/yv12yk8.th.png (http://img187.imageshack.us/my.php?image=yv12yk8.png)

YV12 + MPC YV12 Chroma Upsampling Shader
http://img122.imageshack.us/img122/4930/yv12chromart7.th.png (http://img122.imageshack.us/my.php?image=yv12chromart7.png)

Conclusion: I think everyone needs to recheck this on their machines, maybe someone with an ATI card can check yv12 quality, as I am surprised that rgb32hq wasn't the clear winner after reading all of the posts on this forum.
Note if using the cyberlink decoder with mpc-hc, along with evr-cp, I got ugly results, as evr-cp with yuy2 gives bad results.
Can anyone give an explanation as to what might be happening with evr vs evr-cp. What might be at fault for the different yuy2 results? Nvidia, ffdshow, decoders, microsoft?)

============================================
Interlaced / Progressive Frame Detection Quality
============================================

Tests Used:
Tests 1,2,6,8,9

Explantion:
This test will see which of the decoders does the best job of detecting progressive vs interlaced frames. ffdshows frame type seems to change from decoder to decoder so I have given the output below with the results.

Results (Format: Test X: PASS/FAIL ffdshow-frame-type-output)

mpc-hc Renderer
Test 2: FAIL I
Test 6: PASS I
Test 8: PASS I
Test 9: FAIL I

ffshow libmpeg2 Renderer
Test 2: FAIL P/B
Test 6: PASS P/B
Test 8: PASS P/B
Test 9: FAIL P/B

ffdshow libavcodec Renderer
Test 2: PASS P/B
Test 6: SEMI-PASS P/B (Note: Gets de-interlaced but field order seems to be set incorrectly, must be swapped in ffdshow to prevent ugly juddering effect)
Test 8: PASS P/B (Was I in previous build tested)
Test 9: FAIL P/B

cyberlink (dxva on) - * Results may not be valid as I can't get it to pass interlace flag onto ffdshow to see if yadif kicks in or not, anyone know a way?
Test 2: PASS I
Test 6: FAIL I *
Test 8: FAIL I *
Test 9: PASS I

Conclusion: Can anyone explain whats going on here? None of them get close to passing all tests. Is there a way I can manually go in and see how these frames are flagged?
I need to figure out how to stop cyberlink doing its own de-interlacing, and simply pass on the flag to ffdshow. This way I can test more reliably, and see how its detecting frames.

Update: It is only coming to my attention now, that most PAL dvds are badly flagged, with alot being flagged as interlaced. Here are some links that I was reading on this issue.

Discussion of badly flagged PAL dvds.
http://www.hifi-writer.com/he/progscan/progprob.htm#update2

An old page with software / hardware dvd player interlaced / progressive detection tests.
http://www.hometheaterhifi.com/cgi-bin/shootout.cgi?function=search&articles=all

You can see in the link above, that one hardware dvd player in the test on this page seemed to have a very good score in detecting interlaced vs progressive, detecting it without the use of the flag at all. Wouldn't it be great to have this level of detection in our software decoders. This might require a bit of work in the mpeg2 decoders / ffdshow but its something that would be really useful and I think is needed for any of these decoders to become a viable solution to high quality DVD Playback. Anyone know of any way I can improve the interlace / progressive frame detection with current software?

============================================
Effects of bad interlaced / progressive frame detection
============================================

I won't go and explain the effects of not de-interlacing some frames that should be de-interlaced, but the opposite is causing me more grief, progressive frames being de-interlaced.
When the wrong type of frame is detected, it seems all sorts of ugly effects happen to dvd menus, and as far as ffdshow is concerned, any filter in ffdshow that has a "Frame Type" setting or "Interlaced?" setting, like the RGB conversion filter, can be effected if it doesn't get the right frame type.

For Example: RGB conversion - Method - Interlace or progressive: Auto. With this setting on auto libmpeg2 and rgb32hq gives horrible looking results in Test 1 when the frame type is not forced to progressive, as auto seems to be reading the incoming frame as interlaced resulting in horrible horizontal lines.
I am sure the resize filter in ffdshow is effected also when its "Interlaced" option is set to auto, but I havn't tested this as I don't use resize in my setup.

Conclusion: This bad detection is having a large impact on my playback quality, especially when progressive frames are wrongly de-interlaced. It also effects ffdshow filters and functions such as the rgb conversion as noted above with libmpeg2 and rgb32hq conversion going wrong because of bad detection).

============================================
De-Interlacing Quality (Software vs Hardware)
============================================

Tests Used:
Tests 6, 8

Results (Format: ffdshow-output-colorspace = RESULTING QUALITY)

Software De-Interlacing (Using yadif (double framerate) de-interlacer in ffdshow as its by far the best to my eyes and many others)

yv12 = PERFECT
yuy2 = PERFECT
yvyu = PERFECT (some stuttering on my machine)
uyvy = PERFECT
nv12 = PERFECT
rgb32 = PERFECT

Hardware De-Interlacing (Results obtained by setting ffdshows "Set interlace flag in output media type" and disabling de-interlacing. If using mpc-hc decoder, its "Set interlace flag in output media type" must be enabled also for the flag to be passed all the way through to hardware de-interlacer)

yv12 = NA (CANT SELECT YV12 when set interlace flag in output option set)
yuy2 = PERFECT
yvyu = BAD
uyvy = PERFECT
nv12 = PERFECT
rgb32 = BAD

Conclusion: Hardware De-Interlacing is excellent and the only combination of good colour and good hardware de-interlacing I could find so far was using evr and yuy2 as colourspace output in ffdshow. For software, no problems at all in using yadif software de-interlacer (double framerate) and any good colorspace output.

============================================
DVD-Menu Rendering Quality
============================================

Tests Used:
Tests 3, 4, 5, 7

Results (Format: Test X: PASS/FAIL (notes)

mpc-hc Renderer
Test 3: PASS (Only PASS'es when ffdshow is not used. Even if ffdshow filters disabled, I can't stop the combination causing a FAIL here. Some compatibility issue somewhere here)
Test 4: PASS
Test 5: PASS
Test 7: PASS (Only PASS'es when ffdshow is not used. Even if ffdshow filters disabled, I can't stop the combination causing a FAIL here. Some compatibility issue somewhere here)

ffshow libmpeg2 Renderer
Test 3: PASS
Test 4: SEMI-PASS (Doesn't look like a perfect rectangle as it should be, slight doubling effect seen, probably due to bad positioning.).
Test 5: SEMI-PASS (Looks 1 or 2 pixels off perfect positioning)
Test 7: PASS

ffdshow libavcodec Renderer
Test 3: PASS
Test 4: SEMI-PASS (Doesn't look like a perfect rectangle as it should be, slight doubling effect seen, probably due to bad positioning.).
Test 5: SEMI-PASS (Looks 3 or 4 pixels off perfect positioning)
Test 7: PASS

cyberlink dxva
Test 3: PASS
Test 4: PASS
Test 5: PASS
Test 7: PASS

Conclusions:
mpc-hc decoder is the winner, but slight freezes when used in conjunction with ffdshow.
Isn't libmpeg2 used in mpc-hc... so how can there be differences in the results...

============================================
EVR vs EVR CP vs Haali Renderers
============================================

Still figurnig out which is best, evr-cp giving me problems with some tests which i didn't think would happen.... more here later...

============================================
Resizer Quality
============================================
todo.. as I am finding some weird problems with some of the popular resizers

============================================
Overall Conclusions:
============================================
I think there is a compatibility issue between mpc-hc decoder and ffdshow (slight menu freezes).
I think yv12 output with nvidias latest drivers is the best output method, even better than rgb32hq in ffdshow in my opinion.
Bad detection of interlaced / progressive frames by the decoders has a massive impact on playback quality aswell as some of the simple dvd menus quality, and can cause problems with ffdshows filters down the line, as these filters often depend on good descriptions of the incoming frames.
yadif de-interlacer is excellent in all output colorspaces, it just needs to know when to de-interlace and when not to, and I think this comes down to the decoders again.
Small note to ffdshow developers, switching to / from the libmpeg2 decoder while a video is running causes my player to crash, with a "this program is not responding" dialog from windows. This doesn't happen when selecting other decoders in ffdshow and clicking ok.
============================================

Any suggestions for changes to my setup or comments on my findings would be appreciated.

Regards,

[Atak_Snajpera]

I will settle for 5-tap lowpass for the moment as it seems to be the best choice within ffdshow to my eyes.
5-tap lowpass
http://img150.imageshack.us/img150/9876/5tapwc0.th.png (http://img150.imageshack.us/my.php?image=5tapwc0.png)

Yadif
http://img150.imageshack.us/img150/881/yadifas1.th.png (http://img150.imageshack.us/my.php?image=yadifas1.png)

Source
http://img152.imageshack.us/img152/9449/sourceco5.th.png (http://img152.imageshack.us/my.php?image=sourceco5.png)

I still think that Yadif is the best at moment

[mark0077]

Updated original post

Yadif doesn't seem to be whats causing the uglyness / artifacts at all. It seems to be the mpc decoder and libmpeg2 incorrectly sending interlace information on to yadif that seems to be causing this problem. Yadif + libavcodec is the winner as far as quality goes for me at the moment, but does anyone know why I libavcodec is completely freezing on my menus (menus "appearing" but not being visible, only blindly clickable).

As far as I can tell, here are some bugs that I may have come accross on this journey of mine (unless I can correct them through some options ;) )

libmpeg2: incorrectly sets interlace flag but gets menus perfect
mpc-hc decoder: incorrectly sets interlace flag and is dodgy in dvd menus (once one item is hovered over, no other item can be highlighted)
libavcodec: correctly sets interlace flag but freezes on the queen DVD's audio options menu and doesn't show red dwarfs dvd menu at all

[Leak]

libavcodec: correctly sets interlace flag but freezes on the queen DVD's audio options menu and doesn't show red dwarfs dvd menu at all
Are you perhaps using an AviSynth script for extra filtering?

In that case libmpeg2 sends some extra info used to detect menus and funneling static menu images through that libavcodec (IIRC) doesn't.

[mark0077]

Hi Leak,

No avisynth scripts used, I am only using de-interlacing function in ffdshow, along with the forcing of 32bit rgb.

Thanks for that though, I would love to iron out these problems..

[tetsuo55]

Intersting tests..

You're results basically represent bugs in either the individual items(decoder/deinterlacer) or the combination of items.


the tests reveal critical bugs in all the Mpeg2 decoders you have tried.
the bugs are at least valid when the decoders are used with MPC-HC and/or are part of FFdshow.

could you repeat the test with:
Mplayer: http://forum.doom9.org/showthread.php?t=138725

I'm not sure if you can choose between libvacodec or libmpg2.
Or even how to know which one its using.

If playing with mplayer is fine the bug is in either ffdshow or mpc-hc
If mplayer is busted too the bug is in ffmpeg

[mark0077]

Here are some basic results so far to narrow down where the problem is (not alot of results)

MPlayer, too buggy to properly test with, initial testing shows de-interlacer incorrectly de-interlaces progressive material. Can't see a way yet to use ffdshow in mplayer.
Zoom Player - After some configuration, I can't stop it giving me a stack overflow error.
TheaterTek - No matter how much of a priority I give to the ffdshow video decoder, it won't appear in TT 2.6's list of processors.
Any others I could try? (wow all of these software errors really makes you appreciate mpc-hc, its almost perfect)

[Leak]

Can't see a way yet to use ffdshow in mplayer.
Well - you can't. That's the idea of testing with mplayer - it's fully self-contained, with absolutely no use of DirectShow (and thus no problems caused by DirectShow either)...

np: Tocotronic - Digital Ist Besser (Digital Ist Besser)

[mark0077]

Excellent thanks for that. A problem I am having with MPlayer is stopping me testing the menus. MPlayer seems to start all of my (hard disk copies) DVDS at the first scene, skipping all menus.

MPlayer De-Interlacing Results
Queen DVD: De-Interlaced with yadif (double framerate), shimmering effects as seen earlier (I suspect due to not detecting field order correctly again)
Star Wars: De-Interlaced with yadif (double framerate), Incorrectly de-interlaced and played at 50fps. (I suspect same problem I had before with interlace flag not being sent around correctly)
The World Is Not Enough: Endless loop of play / stop.
Red Dwarf: Endless loop of play / stop.

================================

So I'm seeing the same problems with de-interlacing in both MPlayer and ffdshow + mpc. Also i'm seeing the incorrect de-interlacing field order being selected in both.

Whats the best thing that I can do to report this?

Thanks all,

[Reimar]

MPlayer, too buggy to properly test with, initial testing shows de-interlacer incorrectly de-interlaces progressive material.

For better or worse, MPlayer will not try to "magically" get it right, but at least for the commandline version you can use "D" (uppercase D) to temporarily disable deinterlacing.
Also, FFmpeg decoder is used by default, use -vc mpeg12 to get libmpeg2.
There obviously are differences between those, since the last time I checked, libmpeg2 would not work right with still frames in MPlayer.
One issue with libavcodec may be codec delay: decoded frames will usually be returned one or more frames after their encoded representation has been passed to the decoder, so for one-frame clips you will only get any output after passing empty "encoded" data to the decoder so that any buffered frames are returned.
And you need to use dvdnav:// with MPlayer to get menus, dvd:// will play the first title directly.

[mark0077]

Thanks for that.

So this frame delay in libavcodec might be whats causing the dvd menus to be broken.... (Is this a bug flagged to be fixed or should it be reported?)

When you say MPlayer doesn't try to "Magically" get de-interlacing right, why doesn't it? Where do you think the problem lies here like what piece of code is at fault for not deciding to de-interlace or not. (I'm thinking of who can I speak with / report this to, to eventually get this fixed).

I will try enabling dvd menus now in MPlayer and eventually try libmpeg2 to see can I figure out anything of the other menu problems, but I am assuming for the moment its because of the libavcodec frame delay issue you mentioned.

[Reimar]

So this frame delay in libavcodec might be whats causing the dvd menus to be broken.... (Is this a bug flagged to be fixed or should it be reported?)


Note I am talking out of fuzzy memory, I may be wrong.
To my knowledge it is not considered a bug. You might be able to work around it by setting the low_delay decoder flag, but I think that was considered a bad idea.
The correct solution for all I know is when you reach the end of a stream, call decode with NULL as input until no more frames are returned.


When you say MPlayer doesn't try to "Magically" get de-interlacing right, why doesn't it? Where do you think the problem lies here like what piece of code is at fault for not deciding to de-interlace or not. (I'm thinking of who can I speak with / report this to, to eventually get this fixed).


From my point of view it is a matter of philosophy: reliable auto-detection is not possible (which is why I called it "magical") and in such cases MPlayer will do whatever the user told it to do, assuming they know better (personally I _hate_ programs that think they know better, because in reality they don't).
Of course there is also the argument that in theory a good deinterlacer would never hurt quality for progressive, so (beyond CPU usage) there is no need to disable deinterlacing.
However a clean patch to implement it would probably be welcome, it should mainly be a question of getting the information to the main loop and calling
run_command(mpctx, "set_property deinterlace 0/1");
Feature requests go to bugzilla.mplayerhq.hu (or the MPlayer-users list), but that only helps if some developer actually cares - hordes of users asking for a feature often helps with that, just one person asking probably not so much :)

[mark0077]

libavcodec: So if its not considered a bug, then libavcodec cannot be used as a decoder if dvd menu navigation is required..... this baffles me....

De-Interlacing: I thought auto-detection could be done reliably (my bad), I guess I'll have to look more into this as I find things like the pure video decoder auto detecting interlaced vs deinterlaced flawlessly where as these tests I have done show these combinations I tried can't detect one versus the other, I was hoping it was a bug rather than something that can't be worked around. dang.....

[Leak]

libavcodec: So if its not considered a bug, then libavcodec cannot be used as a decoder if dvd menu navigation is required..... this baffles me....
Well, it's at least not a bug in libavcodec - it's up to the player app to feed it null input until no frames come out anymore...

np: Tocotronic - Das Böse Buch (Tocotronic)

[Reimar]

libavcodec: So if its not considered a bug, then libavcodec cannot be used as a decoder if dvd menu navigation is required..... this baffles me....


Well, since MPlayer uses libavcodec and still frames work it can be used. It might be that ffdshow maps the DirectShow API incorrectly to libavcodec or in the worst case that they are indeed incompatible (though I doubt it).
I think it makes most sense for some ffdshow developer to have a look at this (I'll try to answer PMs or emails concerning this, but I am only a FFmpeg/libavcodec developer, I don't know much about actually using it...).

De-Interlacing: I thought auto-detection could be done reliably (my bad)

Well, you can reliably detect whether it was _encoded as interlaced_. Unfortunately particularly with DVB this is not always related to whether the content itself is interlaced.

[mark0077]

Well, since MPlayer uses libavcodec and still frames work it can be used. It might be that ffdshow maps the DirectShow API incorrectly to libavcodec or in the worst case that they are indeed incompatible (though I doubt it).
I think it makes most sense for some ffdshow developer to have a look at this (I'll try to answer PMs or emails concerning this, but I am only a FFmpeg/libavcodec developer, I don't know much about actually using it...).



Well, you can reliably detect whether it was _encoded as interlaced_. Unfortunately particularly with DVB this is not always related to whether the content itself is interlaced.

Oh thats great your one of the developers. Well I will do my best to explain any more details I can give regarding the libavcodec problem. I think you're right with your diagnosis because dvd menus that have moving video in them work fine, its only menus or screens that are one static image that seem to completely freeze and not appear.

I understand what you mean with the de-interlacing. Its weird how a standard 25fps interlaced video like "The World Is Not Enough" dvd is being de-interlaced when it shouldn't.... And you made a good point that a good de-interlacer shouldn't harm interlaced content, and yadif is almost this good as it just adds slight flickering effects on edges when it de-interlaces material it shouldn't.

Let me know what I can do to help with the libavcodec. Even if I could make a tiny contribution to the development of these fantastic tools would be great.

Edit:
Updated original post as the libmpeg2 blockyness was caused by ffdshow rgb32hq, selecting to force to yv12 fixes this. Another bug somewhere I feel?

Edit:
Updated original post as I narrowed all blockyness problems with libmpeg2 down to ffdshows "Interlace or progressive" option in the "RGB Conversion" section. Looks like its not receiving the correct frame type information and the conversion is messed up.

Edit: Updated original info on menu freezing with mpc-hc, turns out it was the mpc-hc + ffdshow combination thats causing this, need more digging to find out what ffdshow setting is doing this. mpc-hc alone has no menu freezes.

Conclusions so far:
Alot of my problems with quality and blockyness boil down to bad interlacing flag information, it messes up menu quality, rgb conversion and obviously video playback quality when its not detected correctly. This is now my priority, to figure out how to fix this.
libavcodec: The menus freezing could be the fact it doesn't display frames immediately. I will look into can this be "fixed".
mpc-hc menus: Using the mpc-hc decoder and ffdshow (even with no special features of ffdshow used), menus freeze up. Recommend against this combination until I find out what exactly is causing it.

[mark0077]

Rewrote original post completely. I have found some more tweaks to my setup and I'm sure this will be news to many.

With my nvidia 7600gt, outputting in colorspace yv12 gives better quality than rgb32hq. I wonder is this because of the new 181.00 drivers I am using.

This gives me a nice drop in cpu usage. All results above. I can post pictures of any test results if necessary.

[Leak]

With my nvidia 7600gt, outputting in colorspace yv12 gives better quality than rgb32hq. I wonder is this because of the new 181.00 drivers I am using.
Did you force RGB32HQ to do progressive conversion? (On the RGB conversion page, under "Method")

Using interlaced conversion on non-interlaced material will look worse...

np: Kid606 - Who Wah Kill Sound? (Kill Sound Before Sound Kills You)

[mark0077]

Its set to Auto.

The only time I needed to change it to force progressive was with libmpeg2, but in all other combinations of the color test, my selection of auto seem to be correctly mapped to progressive.

[Atak_Snajpera]

mark0077 if you want to achieve very good quality you should use Shader -> YV12 Chroma Upsampling (quality is similar to HQ-RGB32 but it's faster)

I personally use
EVR Custom
Resize -> PS 2.0 Bilinear
Enabled Chroma upsampling
Deinterlacer -> Yadif

[mark0077]

WOW

That actually makes the diagonal parts of the letters in my test look slightly smoother than just using yv12.

So far, in order of quality from best to worst on my machine

yv12 + yv12 chroma upsampling
yv12
rgb32hq

The rest are just too ugly to even list. I'm surprised rgb32hq isn't closer to the top though... I need to inform myself on this whole luma / chroma business :) I assume from my limited knowledge that older nvidia drivers were to blame for the bad yv12 to rgb conversion, and these newer ones are much better. But this chroma upsampling makes it that tiny bit better again.

[Atak_Snajpera]

I forgot to mention that I always disable all build in splitters and decoders. I've just done small test. HQ-RGB32 looks exactly the same as yv12 + yv12 chroma upsampling.

YV12
http://img267.imageshack.us/img267/2650/yv12zv6.th.png (http://img267.imageshack.us/my.php?image=yv12zv6.png)

YV12 + Chroma upsampling
http://img185.imageshack.us/img185/7361/yv12withchromaupsamplinuy9.th.png (http://img185.imageshack.us/my.php?image=yv12withchromaupsamplinuy9.png)

HQ-RGB32
http://img228.imageshack.us/img228/4407/hqrgb32xa4.th.png (http://img228.imageshack.us/my.php?image=hqrgb32xa4.png)

[mark0077]

Almost the same but not exactly. If you look closely at the following images, you might notice the artifacts I describe below with rgb32hq.

ffdshow RGB32
http://img186.imageshack.us/img186/864/rgb32jk3.th.png (http://img186.imageshack.us/my.php?image=rgb32jk3.png)

ffdshow RGB32HQ
http://img255.imageshack.us/img255/2199/rgb32hqko8.th.png (http://img255.imageshack.us/my.php?image=rgb32hqko8.png)

YV12
http://img187.imageshack.us/img187/3111/yv12yk8.th.png (http://img187.imageshack.us/my.php?image=yv12yk8.png)

YV12 + MPC YV12 Chroma Upsampling Shader
http://img122.imageshack.us/img122/4930/yv12chromart7.th.png (http://img122.imageshack.us/my.php?image=yv12chromart7.png)


Things I am looking at to decide which is best
1) Bottom of Diagonal Section of Red N in Ireland
rgb32: Very Jaggy Edge
rgb32HQ: Very-Slight Jaggy Edge
yv12: PERFECT
yv12 + yv12 Chroma Upsampling: PERFECT

2) Inside of last letter A or the last letter D
rgb32: Some artifacts visible
rgb32HQ: Some artifacts visible (actually more than rgb32...)
yv12: Small amount of artifacts visible
yv12 + yv12 Chroma Upsampling: ALMOST PERFECT (Tiny tiny amounts of artifacts visible, but almost invisible unless you really zoom in)

My vote here is that the order of quality of each of the output colorspaces is clearly the following (unless those little artifacts/blocks are meant to be present??)

BEST
1 - yv12 + yv12 chroma upsampling
2 - yv12
3 - rgb32hq
4 - rgb32
WORST

[Atak_Snajpera]

next time post png files instead of lossy jpg

[mark0077]

updated to pngs with comparison
http://img131.imageshack.us/img131/916/comparisonzoomxr4.th.png (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png)

[Leak]

Well, the YV12 Upsampling shader with what seems to be nVidia's YV12 correct chroma upsampling (ATI does about the same when using NV12) simply blurs the chroma a little.

With the point upsampled, blocky chroma it was intended for it pretty much turns the point sampling into bilinear sampling.

(At least that was my intention when I wrote it... :D)

But yeah, the RGB32HQ chroma does look slightly funky in comparison... :confused:

np: Kid606 - Let It Rock (Pretty Girls Make Raves)

[leeperry]

updated to pngs with comparison
http://img131.imageshack.us/img131/916/comparisonzoomxr4.th.png (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png)
interesting! I did the same test on an ATi a while ago :
http://forum.doom9.org/showpost.php?p=1137196&postcount=1868

now that I got an nvidia, I might do it again....but because I use ConvertToRGB32() + ddcc gamut conversion, it would be pointless.

OTOH, I might try to play around with chromaresample="spline36" / chromaresample="bicubic" : http://avisynth.org/mediawiki/ConvertToYV12

from my tests RGB32HQ 16-235 BT.709 in ffdshow & ConvertToRGB32(matrix="rec709") don't yield the same results either...

[mark0077]

Yes thats the post I was looking for today but couldn't find it. Yes I remember your yv12 results were not so great so maybe its an ATI issue. 99% of people probably wouldn't notice the difference but this is what we get for being perfectionists eh.... :)

Let me know your findings.

[leeperry]

CRC is identical between these 2, even if converting to YUY2 in between so I'm not sure...will ask IanB :)

default is bicubic..

ConvertToRGB32(matrix="rec709")
chromaresample="PointResize"

ConvertToRGB32(matrix="rec709")
chromaresample="spline36"

[leeperry]

ok IanB has answered me that the chroma upsampling algorithm can't be changed in Avisynth.

anyway, I think ConvertToRGB32(matrix="rec709") is more accurate than RGB32HQ in ffdshow(PNG's are 10% bigger), try it some time ;)

RGB32HQ 16-235 BT.709 :

http://pix.nofrag.com/a/d/7/3b34018880dbf4f814fde1c1e7afbt.jpg (http://pix.nofrag.com/a/d/7/3b34018880dbf4f814fde1c1e7afb.html)

ConvertToRGB32(matrix="rec709") :

http://pix.nofrag.com/c/a/3/9e6036cb45bef2a19cf2baffa0041t.jpg (http://pix.nofrag.com/c/a/3/9e6036cb45bef2a19cf2baffa0041.html)

maybe it's coz the levels conversion is not exactly identical....who's wrong between the 2 then ? :D

[mark0077]

Thanks for that, Ill try avisynth. I have never used it before, is it simply a matter of using the line

ConvertToRGB32(matrix="rec709")

in the avisynch section of ffdshow and enabling it. This seems to crasm mpc-hc for me.... I'm surely doing something wrong.

Also, regarding the YCbCr specification, 709 vs 601, should I change this depending on the type of video I'm playing, or the type of display I have?

At the moment I am using my pc monitor, but sometime in the next week i will be connecting to a Samsung Series 9 46" so I'm not sure what changes I should make to make things look as good as can be on that with regards all of this.

[mark0077]

Updated original post with more findings, and added some prelimary cyberlink decoder results. I hope I am adding the right cyberlink decoder by using "cyberlink Video/SP Decoder (PDVD8)".

Can't seem to figure out how to stop cyberlink doing de-interlacing, and how to make it send the interlace flag onto ffdshow so I can test it.

Cyberlink passed all of the dvd menu tests, absolutely perfect in the all :)

Also I am noticing differences between color quality results between evr and evr-cp, mainly that yuy2 looks ugly with evr-cp, and fine with evr. this can have an impact if using cyberlink decoder with evr-cp without ffdshow, as it outputs yuy2 by default.

Now I have found a combination of colorspace and hardware de-interlacing that gives me good color and good hardware de-interlacing. This combination is EVR (not evr-cp), yuy2. Looks perfect (if only the decoder would figure out what should and shouldn't be de-interlaced... :))

TODO:
May need to reword original post after I find out how to control cyberlinks decoder more.
Surprised at evr vs evr-cp having an impact on color quality tests, need to figure out whats at fault here.
Add avisynth rgb32 results when I figure out how to do it properly.

Good thing is, still learning, and finding more "bugs" here and there.

[leeperry]

I'm using Avisynth 2.57 with MT 0.7....but you can't run Convert() in MT so all you need is installing Avisynth 2.58 and that should work!

maybe you can play your chroma test sample with it, my guess will be that it'll look better than ffdshow RGB32HQ.

use 601 for SD, 709 for HD....you can easily make profiles in ffdshow.

[mark0077]

I'm disappointed to say that I got avisynth working, and its doing the rgb32 conversion, but it looks the same, or almost identical at least to ffdshows rgb32hq. Nvidias own yv12 / yuy2 -> rgb32 is superior here.

I don't suppose any ffdshow, or libmpeg2 / libavcodec have any comments on the results above, especially the dreadful de-interlacing problems. I'm disappointed to see these great decoders beaten by things like Cyberlink and Windvd in both dvd menu quality, and interlaced frame detection...

[wozio]

especially the dreadful de-interlacing problems. I'm disappointed to see these great decoders beaten by things like Cyberlink and Windvd in both dvd menu quality, and interlaced frame detection...

Decoders doesn't deinterlace stream, especially cyberlink or windvd ones. GPU does deinterlacing. The same effect you can get from ffdshow by sending interlaced flag and outputting nv12 color space for best results.

[mark0077]

Oh I know but isn't it the decoder that decides whether the frame should be interlaced or not? They all seem to get it wrong in lots of situations, some more wrong than others... where as my "crappy" standard dvd player in our living room seems to get it right and not mess up in some places these decoders got it wrong.

Regarding nv12 as the best and sometimes stated as "the only" way to get hardware de-interlacing,my conclusions at least on my nvidia card are that this is now NOT the case.

The bad quality of nv12 color compared yv12 meant nv12 was a no-no. Hardware deinterlacing doesn't give best results with nv12 in my results.

The only combination of good quality color in my tests and perfect hardware de-interlacing was using the following combination.

EVR renderer and
yuy2 as colourspace output (Can be used in mpc-hc without the need for ffdshow by deselecting the output in planar format option. Its the default output of cyberlink decoders so no ffdshow needed for this setup here. And it can also obviously be forced as output colorspace in ffdshow.).

EVR-Custom Presentation + yuy2 gave horrible color quality in my tests, only evr and yuy looked good.

[wozio]

Oh I know but isn't it the decoder that decides whether the frame should be interlaced or not? They all seem to get it wrong in lots of situations, some more wrong than others... where as my "crappy" standard dvd player in our living room seems to get it right and not mess up in some places these decoders got it wrong.

No, decoders just send if particular frame is interlaced or not and this is set in stream, not decided by decoder. GPU then decides if deinterlace frame or not.

Regarding nv12 as the best and sometimes stated as "the only" way to get hardware de-interlacing,my conclusions at least on my nvidia card are that this is now NOT the case.

Yes, basically deinterlacing will work on any supported color space, but advanced, best quality methods work only on nv12. At least on my ati, maybe on nvidia it is other way but I doubt it.

The bad quality of nv12 color compared yv12 meant nv12 was a no-no. Hardware deinterlacing doesn't give best results with nv12 in my results.


Strange since nv12 is basically the same as yv12. On my ati system I get perfectly the same results color wise both on nv12 and yv12. Of course chroma sampling is broken on ati but I don't care since I use nv12.

On ati hardware deinterlacing is best on nv12, on other color spaces it gives only dumb bob. (I'm talking about my system which has old ati x1650 card, maybe on new cards it is other way.)

I can't find any comparison of yv12 to nv12. Could you please post screen shots, maybe we could see what is wrong in there.

Sorry I don;'t have theses dvds to compare by myself to your results, maybe we could do some downloadable content to have possibility to compare on different systems?

Regards
Piotr

[haruhiko_yamagata]

One issue with libavcodec may be codec delay: decoded frames will usually be returned one or more frames after their encoded representation has been passed to the decoder, so for one-frame clips you will only get any output after passing empty "encoded" data to the decoder so that any buffered frames are returned.

I have added workaround for this issue in ffdshow at rev 2570 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2570).
libavcodec returns a frame immediately without flushing.
It's too dirty to submit a patch to FFmpeg though.

[Reimar]

I have added workaround for this issue in ffdshow at rev 2570 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2570).
libavcodec returns a frame immediately without flushing.


Firstly, I think you could handle that just as easily from the calling code, just check the last bytes for SEQ_END_CODE after the first decode and call decode again with 0 size if you found that.
Secondly, I think this can and will only work right if you handle your timestamps correctly, in which case you can just as well (ok, it probably is a bit more effort) set CODEC_FLAG_LOW_DELAY and reorder the B-frames yourself.
Lastly, there was also this on FFmpeg-devel: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-November/019538.html
Assuming it worked, you only need the

+ }else{
+ /* look for SEQ_END_CODE at the last data in this buffer*/
+ /* dvd's won't send the next frame start on still images*/
+ /* SEQ_END_CODE will have to stay at the beginning of a frame*/
+ if(state == SEQ_END_CODE)
+ return i-3;

Part to "fix" the parser if you use the libavcodec AVParser or else fix whatever you use as parser like that.

[haruhiko_yamagata]

Firstly, I think you could handle that just as easily from the calling code, just check the last bytes for SEQ_END_CODE after the first decode and call decode again with 0 size if you found that.
Great idea, I have tried and it works for me. Only one problem is that ffdshow use CODEC_FLAG_TRUNCATED. ffdshow does not always have the 4 bytes in calling buffer. Though it is difficult to trigger it in real DVD.

Secondly, I think this can and will only work right if you handle your timestamps correctly, in which case you can just as well (ok, it probably is a bit more effort) set CODEC_FLAG_LOW_DELAY and reorder the B-frames yourself.
I can understand this, but yes it's a bit of effort.
I'm too lazy to do that.

Lastly, there was also this on FFmpeg-devel: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-November/019538.html
Assuming it worked, you only need the

+ }else{
+ /* look for SEQ_END_CODE at the last data in this buffer*/
+ /* dvd's won't send the next frame start on still images*/
+ /* SEQ_END_CODE will have to stay at the beginning of a frame*/
+ if(state == SEQ_END_CODE)
+ return i-3;

Part to "fix" the parser if you use the libavcodec AVParser or else fix whatever you use as parser like that.
This fits best for ffdshow. Thank you!

[mark0077]

This is excellent, I will update the libavcodec results in the original post after I have tried the new ffdshow version.

Regarding nv12 de-interlacing, its definitely not an option on my nvidia, you should check the already posted images of nv12 colors in the original post. And yes yuy2 de-interlacing is perfect on my nvidia. Could another nvidia user confirm these results, and maybe someone could test colorspaces using evr and evr-custom presentation on their ati cards and post the screenshots and results for comparison.

I use an mpeg2 file labelled interlace_test2.mpeg aswell as the Queen DVD to test the de-interlacing quality. Maybe I could use a more reliable test file and post images but I am 99% sure that nvidia can do lovely hardware de-interlacing with colorspaces other than nv12.

Regarding interlaced / progressive frame detection, if the decoders simply passes on whether the frame is progressive or not, then there shouldn't be a difference between the different decoders in my test. My test shows that there is a difference, and the de-interlacer, whether it be software or hardware is getting different frame information depending on the decoders, some more right than others.

I still believe there are problems with some of the decoders, I would love to know how the frames in my test are actually labelled. Is there a way I can find this out reliably. That way i can tell which decoders are actually reading the frame information correctly or not.

[mark0077]

Updated original post with some results from the new ffdshow. libavcodec no longer freezes in dvd menus that just contain one frame. Good stuff! I'll run the de-interlacing tests again to see if there are any changes with this new ffdshow version.

[wozio]

Regarding nv12 de-interlacing, its definitely not an option on my nvidia, you should check the already posted images of nv12 colors in the original post. And yes yuy2 de-interlacing is perfect on my nvidia. Could another nvidia user confirm these results, and maybe someone could test colorspaces using evr and evr-custom presentation on their ati cards and post the screenshots and results for comparison.

I don't see screenshots, there are only for yv12, as far as I see.

I use an mpeg2 file labelled interlace_test2.mpeg aswell as the Queen DVD to test the de-interlacing quality. Maybe I could use a more reliable test file and post images but I am 99% sure that nvidia can do lovely hardware de-interlacing with colorspaces other than nv12.

I will check it on my system and post results from other video clips I have.

Regarding interlaced / progressive frame detection, if the decoders simply passes on whether the frame is progressive or not, then there shouldn't be a difference between the different decoders in my test. My test shows that there is a difference, and the de-interlacer, whether it be software or hardware is getting different frame information depending on the decoders, some more right than others.


I theory there should not be any differences between decoders.

[mark0077]

Will uploaded nv12 screenshot when I get home...

[tetsuo55]

You might want to try a newer build of FFdshow, there have been several commits related to both mpeg2 decoders over the past 2 days.
The latest mpeg2 related commit is from 2 hours ago

[tetsuo55]

At rev 2587, I've cleaned all known issues of libavcodec MPEG-1/2.
Is there anything left?
Now libavcodec may surpass libmpeg2.

And I'm going to change libmpeg2 to flag interlacing like libavcodec.
Any objections?

Anyway, there is no reliable flag in most cases. It's just "how the stream was encoded", not "how it should be treated after decoding".

Looks like libavcodec should pass all tests now

[mark0077]

Updated libavcodec de-interlacing results (and rechecked libmpeg2's)

Only changes in the newer ffdshow versions is libavcodec with Test 8. The ffdshow frame type displayed in the osd simply changed from I to P/B. All of the tests with libavcodec now give the frame type as p/b.... any ideas why this is so? Anyways the problem with my Queen DVD is still there with libavcodec.. the field order seems to be wrong, and needs to be swapped. This is not the case with libmpeg2 which doesn't have this problem.

I think the interlaced / progressive frame detection is another mini project in itself because of the fancy detection methods that would need to be implemented beyond just checking the flags which are almost always set incorrectly on PAL DVDS at least. For the moment at least, it would be nice to see the decoders giving the same results.

So to summarize, there are now two differences between libmpeg2 and libavcodec results in the frame type detection. libavcodec passes 2, libmpeg2 doesn't. libavcodec only can pass Test 6 when ffdshow is set to swap the incoming fields.

mpc-hc Renderer
Test 2: FAIL I
Test 6: PASS I
Test 8: PASS I
Test 9: FAIL I

ffshow libmpeg2 Renderer
Test 2: FAIL P/B
Test 6: PASS P/B
Test 8: PASS P/B
Test 9: FAIL P/B

ffdshow libavcodec Renderer
Test 2: PASS P/B
Test 6: SEMI-PASS P/B (Note: Gets de-interlaced but field order seems to be set incorrectly, must be swapped in ffdshow to prevent ugly juddering effect)
Test 8: PASS P/B (Was I in previous build tested)
Test 9: FAIL P/B

I am off to see if I can see any other differences that I can mention in the original post.

[Leak]

Will uploaded nv12 screenshot when I get home...
You wouldn't happen to be on a field trip or something? ;)

[tetsuo55]

Updated libavcodec de-interlacing results (and rechecked libmpeg2's)

Only changes in the newer ffdshow versions is libavcodec with Test 8. The ffdshow frame type displayed in the osd simply changed from I to P/B. All of the tests with libavcodec now give the frame type as p/b.... any ideas why this is so? Anyways the problem with my Queen DVD is still there with libavcodec.. the field order seems to be wrong, and needs to be swapped. This is not the case with libmpeg2 which doesn't have this problem.

I think the interlaced / progressive frame detection is another mini project in itself because of the fancy detection methods that would need to be implemented beyond just checking the flags which are almost always set incorrectly on PAL DVDS at least. For the moment at least, it would be nice to see the decoders giving the same results.

So to summarize, there are now two differences between libmpeg2 and libavcodec results in the frame type detection. libavcodec passes 2, libmpeg2 doesn't. libavcodec only can pass Test 6 when ffdshow is set to swap the incoming fields.

mpc-hc Renderer
Test 2: FAIL I
Test 6: PASS I
Test 8: PASS I
Test 9: FAIL I

ffshow libmpeg2 Renderer
Test 2: FAIL P/B
Test 6: PASS P/B
Test 8: PASS P/B
Test 9: FAIL P/B

ffdshow libavcodec Renderer
Test 2: PASS P/B
Test 6: SEMI-PASS P/B (Note: Gets de-interlaced but field order seems to be set incorrectly, must be swapped in ffdshow to prevent ugly juddering effect)
Test 8: PASS P/B (Was I in previous build tested)
Test 9: FAIL P/B

I am off to see if I can see any other differences that I can mention in the original post.

It would help if you could make 30 seconds/less than 100mb samples of each test.
This way the ffdshow and mpc-hc dev's can test on their own systems.

I believe de-interlacing is broken in more way's than your tests reveal.
In the short term we should get accurate and consistent flag-reading behaviour in. After that is working we should focus on advanced detection algorythm

[mark0077]

Can anyone tell me how I can rip sections of these DVDS for testing, including some of the menus that I use for testing menu layout.

It would be nice to also come up with a "suite" of de-interlacing tests, like the suites I see used for testing hardware de-interlacers to see how they detect frames. If anyone can come up with a list maybe we can track down some clips for use in testing especially when the advanced detection algorithms begin being implemented by the developers.

I also have to upload nv12 color output on my nvidia card to show you ATI users how bad it is for me on nvidia.