View Full Version : MFlowFPS with bobbed source
tormento
9th December 2010, 12:31
I'd like to deinterlace some 1080i material I own, getting some speed from Nvidia processing (DGNVTools) in bobbed mode.
I have seen examples to increase FPS but no ones to use double framerate to interpolate them in a better single framerate, i.e. given 60i obtain 30p.
I thought about using Motion but I think MVTools2 could give better results.
Didee? =)
Gavino
9th December 2010, 13:07
To get 30p from an 60i source that has been already bobbed to 60p, you can't do any better than a simple SelectEven().
What you want is for the bobber itself to use motion compensation, ie use TGMC or QTGMC.
tormento
9th December 2010, 13:20
TGMC doesn't use Nvidia Video Engine. I know it is inferior by quality but I think that MC could do something to correct the missings.
Didée
9th December 2010, 14:45
As soon as you use MC to postprocess the NV-bob, you loose almost all of NV's speed advantage. Considering that Yadif seems to be quite similar to NV-deinterlacing, you could just as well use TGMC with Yadif as initial bobber.
tormento
10th December 2010, 09:02
Mmm.. any simpler interpolation between frames?
Didée
10th December 2010, 11:28
What "simpler interpolation"? :confused:
Oh, wait - here's a very simple form of interpolation:
source
SeparateFields().SelectEven().BilinearResize(width,height)
Is that simple enough interpolation? :confused:
*****
SetMTMode(5,6)
SetMemoryMax(1500)
Mpeg2Source("1920x1080_mpeg2.d2v")
setmtmode(2)
TempGaussMC_beta2(1,1,0,0,0,0,"bicubic",smode=0,sharpness=0.0,svthin=0.0,sbb=0,blocksize=32,overlap=0,search=1,searchparam=1,pelsearch=1)
SelectEven()
That's ~22fps with ~70% CPU load on an i7-860/HT @ stock settings.
(I would've recommended QTGMC(preset="ultra fast"), but that one crashes for me on FullHD input with SetMTmode(2,6), while TGMC_b2 works. "YMMV".)
But don't whine if any visual issues come up. "Full-HD" and "MVTools" AND "Fast" AND "good quality" are, in this combination, mutually exclusive.
(You wouldn't ask for x264 with --ultrafast speed but --veryslow quality, would you?)
tormento
11th December 2010, 20:48
What "simpler interpolation"? :confused:
Groan, don't make me feel like this =P
I need something better than deinterlace=1 in DGNV. My idea was to interpolate the odd and even frames created by deinterlace=2, going from 60i to 30p.
2Bdecided
11th December 2010, 21:10
You want to convert 60i > 60p > 30p, and you want the 60p > 30p bit to be "better" than selecteven()?
You can add motion blur using m(v)tools, which is good in the sense that it can simulate a slower shutter speed, making the 30p look less stuttery.
But it's bad in the sense that it can introduce artefacts, can be slow to process, and sometimes the original 60p had enough motion blur any way.
I had a script to do it with the old mvtools, but there's mvlowblur built into mvtool 2.
Hope this helps.
Cheers,
David.
tormento
12th December 2010, 09:21
Sorry, you misunderstood. I have no problem getting 60p using DGNV but, as I want to encode to 30p, my idea was to "interpolate" even and odd frames to correct compression artifacts in the original video.
Gavino
12th December 2010, 10:52
Surely any interpolation between the even and odd frames (which represent different moments in time) will be of worse quality than either of those frames???
aegisofrime
12th December 2010, 11:08
I might be missing something here, but why not just use DGSource's Deinterlace=1?
2Bdecided
12th December 2010, 14:45
Surely any interpolation between the even and odd frames (which represent different moments in time) will be of worse quality than either of those frames???You could just blur them together with temporal soften. It'll give double images on fast movement though, and won't help much with blocking anyway.
TGMC can sometimes do a useful job hiding some compression artefacts.
Actual interpolation (I don't think the OP really means interpolation at all!) would, as you say, introduce even more artefacts!
Cheers,
David.
tormento
12th December 2010, 16:55
I suppose Nvidia video engine already does some kind of interpolation when choosing deinterlace=1 (means 30p). I just wanted to get some better results partly using the video engine with deinterlace=2 (means 60p) and with some software algorythm, i.e. some kind of motion compensated interpolation... =P
Didée
12th December 2010, 19:26
NVidia's PureVideo Engine does have a temporal-something processing mode (the so-called "vector adaptive" mode), although it is not exactly clear what it really does. But that doesn't even matter. From the look of what NV's bob/deinterlacing through DGDecNV actually is delivering, I'm pretty confident that it uses only plain spatial interpolation, nothing else. (It looks like simple ELA as known from SangNom or TomsMoComp or tdeint. Including the "dot" artifacts.)
Summarized ...
a) NV's processing is fast, but the speed part is only important if the complete processing chain is very fast. As soon as you start doing MC, the Avisynth script is inherently slow, and you need to be good with the stopwatch to notice any speed difference.
b) From a "quality" point of view, there's absolutely no advantage of using NV's deinterlacing. Any random Avisynth deinterlacer is at least same good, if not better.
Conclusion ...
If you want to use motion compensated temporal processing, then there is simply no point and no benefit to start out with NV's processing. And all that you really want to do, is already offered by Q/TGMC. Motion compensated temporal averaging/denoising is exactly what TGMC natively does.
* * * * *
If you want to try it by all means, it is actually possible to use NV-bobbing together with Q/TGMC, by using the "edeint" parameter. It would require to call 2 times DGMultiSource, and would go like this:
plainsource = DGMultiSource("source.dgi",deinterlace=0)
NVbobbed = DGMultiSource("source.dgi",deinterlace=2) .deleteframe(0) # NV's bobbing is off by one source field
plainsource.TGMC( [params] , edeint=NVbobbed )
It's pretty much pointless to do it this way, but it works.
Didée
12th December 2010, 23:15
I've to (partly) correct myself. NV-deinterlacing via DGDecNV is not purely spatial. At least, it reckognizes *perfectly* static sections. It would be too far fetched to call this "temporal processing" ... however, there is a temporal component of some sort.
Example to examine: LINK (http://www.mediafire.com/?azei61r2098os0d) ( ~60 MB @ MediaFire)
(This clip is 200% zoom, 1/4 speed)
FPS numbers:
DGDecNV: 96.5 fps (decoding bound)
Yadif: 96.5 fps (decoding bound)
tdeint: 54 fps (1 thread)
TGMC: 24.2 fps (1 thread)
TGMC: 67.5 fps (6 threads)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.