Yadif Improvement - Samples Needed

[mark0077]

Hi all,

I was in touch with the author of the yadif de-interlacer to ask if there were any plans to attempt to bring it upto or near the standard of some of the great hardware de-interlacers we have.

Michael kindly said he would take a look at this but would need a sample which shows where hardware de-interlacers do a much better job than the current yadif version.

"If you could provide some short video (a few seconds is plenty) that is deinterlaced in hw noticeably better than yadif, then i could try to take a look at it."

I could probably come up with a few but I thought I would throw this out to you guys. Have you got any short samples that allow us to easily see the advantages of the newish ati and nvidia de-interlacers to send to Michael.

Thanks,

[tetsuo55]

Does comparing to standalone hardware count?

silicon optix HQV and Faroudja DCDI usually lead to the best results, and are often used in 3000$+ decoders.

Silicon optix uses what they call: Pixel-Based Motion Adaptive with “Second Stage” Diagonal Interpolation

Faroudja uses what they call: Directional Correlational Deinterlacing

They explain how it works here:
http://www.hqv.com/technology/index1/deinterlacing.cfm?CFID=19702652&CFTOKEN=38016814
and
http://www.meridian-audio.com/faroudja/technology.html

Also both support Cadence/Film&Video mode detection, does yadif do this?

One thing is very clear though, Both technologies use per pixel motion based deinterlacing, which basically gives them free cadance detection, Faroudja seems to be ahead of HQV because it appears they have got it all in one pass (cadence detection, deinterlacing, jaggies prevention)

-------

Also how does Yadif react to progressive material? the above chips have no problems passing through progressive content(they completely ignore flags of any kind and do their own thing)

[mark0077]

Excellent links, very good reading. I assume Michael will need a clip that he can (if testing any changes) compare and contrast against his hardware de-interlacer. We might need to find a nice clip(s) that can encompass some of the weak points of yadif. I can't define these clearly enough, but I am sure some of you can and provide a clip.

I use yadif from within ffdshow and when a clip is marked as progressive yadif doesn't seem to kick in BUT this could be ffdshow completely bypassing de-interlacing. I wish I knew enough about the in's and outs of different combinations of flags and input's and how yadif should / does react. It would be good to compile a list of areas where it could be improved, maybe with clip or clips to show or exxagerate these scenarios. Might take a while but to have a software de-interlacer to rival those hardware ones you linked to would be :O:O:O

EDIT: Maybe this thread should be in the new and alternative codecs section?

[tetsuo55]

Yeah, currently we are using various detection methods to enable/disable deinterlacers.

Any file could have any frame or part of a frame interlaced. The currently available best way to deal with this is per-pixel deinterlacing of all content. The deinterlacing process should however not damage the progressive content in any way.

[roozhou]

@mark0077
There is another deinterlacer in MPlayer written by Michael, named mcdeint, which does a better job than YADIF and even better than HW deinterlacer. The problem is it uses SNOW encoder and seems a bit slow( for SD content, ~20 fps on E8400). Better asking Michael to improve mcdeint's performance?

Try sth like
mplayer -vf tfields=1:0,mcdeint=0:0:3 xxx.vob

[mark0077]

Have you any links to comparisons between it and hardware. I see on some of the mplayer forums guys using yadif AND mcdeint. I read through this page discussing yadif and mcdeint being used together. http://guru.multimedia.cx/deinterlacing-filters/

If I could test this combination from within ffdshow using avisynth scripts I could test the performance on core i7 to see if its feasible to do in realtime. I wonder why mcdeint has never shown up in ffdshow options yet ;)

[roozhou]

Have you any links to comparisons between it and hardware. I see on some of the mplayer forums guys using yadif AND mcdeint. I read through this page discussing yadif and mcdeint being used together. http://guru.multimedia.cx/deinterlacing-filters/

If I could test this combination from within ffdshow using avisynth scripts I could test the performance on core i7 to see if its feasible to do in realtime. I wonder why mcdeint has never shown up in ffdshow options yet ;)

Because mcdeint is only available in MPlayer, MEncoder and AVIDemux

[CruNcher]

Imho especially Nvidia improved a lot in Deinterlacing over the years (10 years ago ATI/Matrox/S3 ruled Video Quality Research) and they can very fast react now too i remember reporting here that with my old 7300 GS another beta driver of theirs even on that old card improved their Deinterlacing to the quality back then of Yadiff (though this drivers Beta Deinterlacing was massively slow for the 7300 GS no realtime was possible anymore 1080i/p) now im not sure how far they are by now :) but im only using their Deinterlacer on my 8800GT if needed and im happy with the realtime 1080i 25/30 -> 1080p 50/60 process :) that would cost alot of CPU power with Yadif (dont even want to imagine how much power i would need for mcdeint or Edi2 based Deinterlacing for 1080i/p realtime on a CPU) and make other task very problematic, though still it seems not possible to use Nvidias Deinterlacer outside of their given Decoder APIs (Mpeg-2,H.264,VC-1) (at least nobody tried it yet) which is a real pity :(, though with the possibility of CUDA and OpenCL existing now it seems every Software Deinterlacer we have now can be ported to the same Hardware by anyone capable of it with ease.
When Donald implemented Nvidias API and Deinterlacer in his Dgadec range of applications some compared it already to other Software deinterlacer and where quiet happy with the results especially i guess the most improvement and what fascinates avg consumers the most is for sure the speed difference for the given quality, which seems to be in a very good ratio for Nvidias Deinterlacer currently, though nobody yet compared power efficiency vs CPU based Deinterlacer like Yadiff for example yet.
Im not so sure though if Nvidia yet reached the Quality of a Edi based Deinterlacer (in Realtime) but with the time given they improve their Gflop power every driver could get better without even people realizing that the quality improved ;) it might improve every beta driver a little bit more :D, especially seeing the massive Ecosystem Nvidia is building up now since some time with all their Partner ISVs in it's massive GPU strike, we can count that all these ISVs report daily about issues and problems to Nvidias Engineers and the telemetry Nvidia gets must be very useful for improving the Video Parts of their Driver see all the improvements that Donalds work made possible for example alone.

As Bill Gates said before he left the building the future is in Software more then ever :). Also seeing the recent T-Mobile Software crash he's of course right ;)

PS: Of course Nvidia disabled the Higher Quality Deinterlacing in the next Beta Driver for the 7300 GS and reverted back to the old less quality then Yadiff one, the power of a Unified Driver Architecture most probably they forget a IF line ;)

[Likewise]

A good way to test deinterlacers: Get a 1080p progressive source. Throw away a field, try to deinterlace it, measure MSE.

I can probably setup a Silicon Optix / Teranex / HQV deinterlacer if we agree on the sources.

[mark0077]

I actually just sent the yadif creator a link to a DVD test disk that nicely shows yadif's shortcomings versus nvidia / ati's hardware de-interlacers. I will look at the 1080p source you talk about, nice idea. Doesn't seem to be alot of.... enthusiasm anymore for good software de-interlacers... maybe there is but I am not seeing it.

[avih]

I actually just sent the yadif creator a link to a DVD test disk that nicely shows yadif's shortcomings versus nvidia / ati's hardware de-interlacers. I will look at the 1080p source you talk about, nice idea. Doesn't seem to be alot of.... enthusiasm anymore for good software de-interlacers... maybe there is but I am not seeing it.
Not sure that's true, however, there are already nice deinterlacers out there (DScaler could use yadif too, the more the merrier). I, for one, would love to see new/better deinterlacers around, it's just that this thread does well as it is ;) keep it updated...

[tetsuo55]

so did anyone find any problematic samples yet?

I have very little interlaced content, and the ones i do have seem to be doing fine with yadif

[mark0077]

Well I sent a link to the yadif creator. Its a free test dvd created by someone but has some nice interlaced content that shows how good the ati and nvidia deinterlacers are compared to yadif..

The waving flag test, with yadif, the text is grainy and hard to read, on ati and nvidia it looks perfect and is very easy to read.

http://www.isaneri.it/bg/TestDVD1_08.zip

No reply from him though.

[roozhou]

Here is a sample
http://www.mediafire.com/download.php?yxtzejyqo0j

With YADIF the rolling text looks really bad.

[Thunderbolt8]

what kind of samples are needed? would like to see some improvement in terms of CPU usage, as it seems it doesnt support multi core. its basically impossible to get double framerate running smoothly together with a quite hardware intensive renderer (like madVR for example). I have no problem with 1080p high bitrate AVC stuff with a quadcore & HD 4770, but as soon as I try double framerate CPU usage is shooting through the roof, because it seems only 1 core is supported, and I get mass skipped & delayed frames. with multicore support there seems to be lot of room to improve performance.

so how can I find out if hardware deinterlacing would work much better in such samples, what players should I use there? I guess the sample must be a native interlaced file then (unlike you can use the double framerate option also on progressive stuff), otherwise the hardware players wouldnt deinterlace at all? so basically 1080i .m2ts stuff from blu-rays?

would be really great if speed could be improved for the double fps rate option (or is there any other way/prog/filter which also can do double framerate for all videos? actually thats the only thing I'm interested in for smooth playback, I dont even need that deinterlacing part).

[nm]

what kind of samples are needed? would like to see some improvement in terms of CPU usage, as it seems it doesnt support multi core.
IIRC, ffdshow-tryouts has a multithreaded, SSE2/SSSE3-optimized version of yadif. I haven't looked at the code, but perhaps it could be ported back to MPlayer and AviSynth.

(or is there any other way/prog/filter which also can do double framerate for all videos? actually thats the only thing I'm interested in for smooth playback, I dont even need that deinterlacing part).
Use MVFlowFPS for that. I gathered a few nice links the last time this was asked: http://forum.doom9.org/showthread.php?p=1283249#post1283249

[roozhou]

IIRC, ffdshow-tryouts has a multithreaded, SSE2/SSSE3-optimized version of yadif. I haven't looked at the code, but perhaps it could be ported back to MPlayer and AviSynth.


I did send a SSE2/SSSE3 patch for yadif to mplayer-dev-eng mailing list last year. Only the SSSE3 detection part was accepted and the others were rejected by Michael. That's why there is now SSSE3 detection code in mplayer but SSSE3 is never used.

Roughly SSE2/SSSE3 gives 20%~30% speedup on Pentium Dual and 65nm Core2 compared to MMX and less speedup on K8. On K10 and 45nm Core2 it may gain a little more but not as much as 60% claimed by the ffdshow-tryouts developers.

[LoRd_MuldeR]

What was the reason for rejection and can it be fixed?

[nm]

What was the reason for rejection and can it be fixed?
Sure, with a little more work: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-November/059012.html

@roozhou: Did you take a look at the multithreading part, would it be more difficult to port?

[Thunderbolt8]

IIRC, ffdshow-tryouts has a multithreaded, SSE2/SSSE3-optimized version of yadif. I haven't looked at the code, but perhaps it could be ported back to MPlayer and AviSynth.


Use MVFlowFPS for that. I gathered a few nice links the last time this was asked: http://forum.doom9.org/showthread.php?p=1283249#post1283249
I downloaded ffdshow from here: http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=439938
but when comparing the CPU usage with yadif double fpsrate there didnt seemed to be a difference between the non SSE_ICL ffdshow versions for me. in both cases 1 CPU was at the roof, while the load of the other one wasnt much higher as without yadif usage.

also tried that here: http://forums.guru3d.com/showthread.php?t=288017
but frankly said with ffdshow and madVR playback was even a little slower as with yadif double fpsrate (C2D @2,8GHz)
(have to add though that I in general also need to scale 1080p sources to 1280x1024 and therefore also need to apply ffdshow sharpening, maybe all that is a bit too much :S) what I noticed though was even it seemed to be a little slower than yadif the CPU usage of the 2nd core was higher in this case here as with both ffdshow versions & yadif double fpsrate, so multithreading seems to be active here.

[nm]

I downloaded ffdshow from here: http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=439938
but when comparing the CPU usage with yadif double fpsrate there didnt seemed to be a difference between the non SSE_ICL ffdshow versions for me.
I don't think there should be any significant difference between different builds of the same ffdshow-tryouts revision as long as the hand-coded assembly optimizations are in use. The difference in SSE and non-SSE builds are the compiler settings used when building the C/C++ code. They don't affect assembly routines and only have a minor effect on the overall performance.

in both cases 1 CPU was at the roof, while the load of the other one wasnt much higher as without yadif usage.
This indicates that multithreading doesn't work for you for some reason.

also tried that here: http://forums.guru3d.com/showthread.php?t=288017
but frankly said with ffdshow and madVR playback was even a little slower as with yadif double fpsrate (C2D @2,8GHz)
Well, these filters have a different purpose and they require opposite types of source video. You should only use MVFlowFPS for progressive (or already deinterlaced) sources and yadif for interlaced video. Double-rate yadif doesn't predict new frames from progressive video -- it just adds artifacts. Using MVFlowFPS for half-rate deinterlaced video is also not wise since proper bobbing is more efficient and less lossy.

[roozhou]

Sure, with a little more work: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-November/059012.html


I am getting tired of refactoring the code. If Michael was really interested in such optimzation, he should do it himself instead of asking me to do.

I make MPlayer daily build every morning and SSE2/SSSE3 yadif works fine. I don't care whether this patch becomes official.


@roozhou: Did you take a look at the multithreading part, would it be more difficult to port?

It would be more beneficial if you make MPlayer multithreaded than making yadif multithreaded. I mean running decoding and filtering in seperate threads.

[Thunderbolt8]

Well, these filters have a different purpose and they require opposite types of source video. You should only use MVFlowFPS for progressive (or already deinterlaced) sources and yadif for interlaced video. Double-rate yadif doesn't predict new frames from progressive video -- it just adds artifacts. Using MVFlowFPS for half-rate deinterlaced video is also not wise since proper bobbing is more efficient and less lossy.
ye, thats what I tried, I used a progressive 1080p file in that case. but as already said, unfortunately MVFlowFPS still seems to have too much demand for my system. but why is there then the option to process progressive flagged frames as well in yadif?

btw. do any of those setting in the avisynth field (boxes or the script) somehow change the quality of the output (e.g. different colours etc.)? the reason I use madVR is I want to have the best PQ output as possible so I now just wonder if all that stuff with chroma and uncheckmarking those boxes yuy2 rgb etc. have any effect here.

and with regards to that #assume line, does that framerate doubling only with with 23.976 and 25fps files or also with exact 24fps stuff? (a few blu-rays have exaclty 24 fps)

[nm]

but why is there then the option to process progressive flagged frames as well in yadif?
Because some interlaced or hybrid sources may be flagged incorrectly or even encoded as progressive.

btw. do any of those setting in the avisynth field (boxes or the script) somehow change the quality of the output (e.g. different colours etc.)? the reason I use madVR is I want to have the best PQ output as possible so I now just wonder if all that stuff with chroma and uncheckmarking those boxes yuy2 rgb etc. have any effect here.
The chroma references in the script are related to motion analysis; they don't affect the output colors. I'm not really familiar with either ffdshow or madVR, but I'd guess that you should disable any colorspace conversions (from YV12 to YUY2/RGB/...) in ffdshow and let madVR handle them.

and with regards to that #assume line, does that framerate doubling only with with 23.976 and 25fps files or also with exact 24fps stuff? (a few blu-rays have exaclty 24 fps)
The script doubles the source framerate, which can be anything as long as it's progressive video.

[Thunderbolt8]

k,thanks

[LoRd_MuldeR]

You need samples where Yadif doesn't performs well? Guitar strings!

Here are some Yadif -vs- NNEDI2 samples that should illustrate the problem clearly:

Sample 1:
http://img406.imageshack.us/img406/7416/yadifvsnnedi21a.png
http://img14.imageshack.us/img14/4438/yadifvsnnedi21b.png

Sample 2:
http://img43.imageshack.us/img43/4121/yadifvsnnedi22a.png
http://img3.imageshack.us/img3/1751/yadifvsnnedi22b.png

Sample 3:
http://img338.imageshack.us/img338/5857/yadifvsnnedi23a.png
http://img338.imageshack.us/img338/5140/yadifvsnnedi23b.png

[Dark Shikari]

Those aren't really samples... you can't really run a temporal deinterlacer on a static image.

[LoRd_MuldeR]

Those aren't really samples... you can't really run a temporal deinterlacer on a static image.

I know still images are not really samples. But I think those images should be sufficient to illustrate the issue. In case anybody is interested, a sample of the original video clip can be provided.

However I assume any music clip with guitar strings (or similar structures) would show the same effect, more or less. At least I have seen this many times in various music clips...

[mark0077]

Thanks. The yadif author didn't seem too interested in yadif improvement when I spoke to
him last. Maybe software deinterlacing is going to be not so good compared to hardware for a while yet.

Would love to take it on as a project but think improvement of something that already exists would be more likely to be successful.

[LoRd_MuldeR]

Thanks. The yadif author didn't seem too interested in yadif improvement when I spoke to him last. Maybe software deinterlacing is going to be not so good compared to hardware for a while yet.

Naaa. Software deinterlacing can give great results. Tritical's YadifMod combined NNEDI2 does handle this kind of footage pretty well ;)

But it's much slower. Too slow for realtime on my Q6600. If the original Yadif could be tweaked to handle this better (not necessarily as good as NNEDI2), that would be nice :)

Also since NNEDI(2) is only provided as a binary, it cannot be incorporated into Avidemux. But Yadif already is available in Avidemux...

[Astrophizz]

If it's too slow for realtime, how is it better than a hardware deinterlacer that can give better results than software deinterlacers that do work in realtime? Do you mean just for encoding?

[Dark Shikari]

If it's too slow for realtime, how is it better than a hardware deinterlacer that can give better results than software deinterlacers that do work in realtime?Because they have dedicated hardware.

[roozhou]

If it's too slow for realtime, how is it better than a hardware deinterlacer that can give better results than software deinterlacers that do work in realtime? Do you mean just for encoding?

Why not first implement the algorithm of hardware deinterlacer in software?