What's the difference between the different deinterlacing options?

[Gooberslot]

I've searched trying to find out what the differences are and which would be best to use but I've had no luck. The only thing I've found out from my own experience is that field deinterlace seems to match most closely what I get from PowerDVD. I've also discovered that it gives much better compressibility results than Kernel Deinterlacer which means it must be bluring or discarding information. Of course none of this actually tells how they're working.

[len0x]

I'm gonna move this to avisynth forum since its very technical question.

[Gooberslot]

LOL and here I was thinking this might have belonged in the Newbie section. :D

[len0x]

As you discovered yourself Field Deinterlacer indeed the most blurry one (but can you can use no blend option which should improve it). Smart Bob or Kernel Deinterlacer are better sharp ones.

I don't think PowerDVD uses any comprehensive deinterlacing - its just Bob, so I really wonder how you can compare it to Field Deinterlacer (may be its just on that source).

[kingmob]

For me it really depends on what i want, but usually i use TomsMoComp. If you don't care about the loss of resolution in still parts, want smooth movements and are able to playback a 50+fps movie, smartbob is also a very good option imo.

Smartbob seperates the fields and upscales their half vertical resolution back tot the normal resolution (thus you lose resolution). Your framerate becomes the fieldrate, so movement is much smoother, but an extra 'downside' is that your video contains twice as much frames than any other option!
As far as i understand, TomsMoComp measures the parts where you get interlace artifacts and uses some sort of bobbing on that, but on the parts where there aren't any artifacts it combines both fields. So it retains resolution, but halves your framrate (to the 'normal' 25 or 29.97)

[scharfis_brain]

when you use the avisynth-function TMCBob(), you'll have bobbing capabilities with tomsmocomp.



function tmcbob(clip i, int se)
{
a=i.tomsmocomp(-1,se,0)
b=i.doubleweave().selectodd().tomsmocomp(-1,se,0)
interleave(a,b)
}

[len0x]

Originally posted by kingmob
... want smooth movements and are able to playback a 50+fps movie, smartbob is also a very good option imo.


FYI SmartBob used in GK uses an option to not double frame rate...

[PlazzTT]

If I can stick my noob head in here...

What are the cons / bad points of TomsMoComp? I always use TomsMoComp(1,5,1).

I'm guessing this page hasn't been updated in a while: http://www.100fps.com/ (at least not since TMC was released), but it says this about Motion Compensation as a de-int method:

"This is the best solution, but unfortunately only for companies that can pay for expensive hardware solutions. "

And it says the cons of Motion Comp are:

"Expensive hardware equipment. How expensive? Can you say $50'000? Or think $100'000? Then spell T-E-R-A-N-E-X. This is equipment as used for professional broadcasting: Teranex."

But now we have a free software solution with TomsMoComp, so why doesn't everyone use it?

[tritical]

One of the things you have to take into account is exactly how the motion compensation is being done. TomsMoComp is a very nice filter, but when it comes to its motion compensation it is about as far down the totem pole of techniques as you can get :D. It does single pixel searching, and with a setting of 5 will only be looking about 1 or 2 pixels to each side. After it searches, it decides whether to use the result of the search or that of its bob which is done with 5+5 tap ela. The teranex equipment I don't know much about, I went to their site but they provide no relevant information about it. If I was a betting type of guy (which I'm not ;)) I would say it probably uses some type of block based motion compensation along the lines of pmvfast, epzs, etc... which like every other block based technique that has been tried for motion compensated filtering/deinterlacing only works with very specific types of motion and probably has something it drops back to on rotational motion, zooms, etc... But who knows, their equipment might be great, provide perfect results on everything, and be worth $100,000.

[webwonk]

I don't want to start a religious war here but...I have been playing with WMV9-AP (Advanced Profile) which is available when you install the WMFormat95sdk; and the just released WMP10. One of the options of AP is to encode and maintain interlace. When I playback interlaced WMV9-AP through WMP10 on my computer, it looks pretty good. What kind of auto de-interlacing does WMP10 do? It must be doing something better than field-deinterlacing, maybe bob?

Anyhow, what is the view of this forum on maintaining interlace? I've read Minolta's thread and agree that ffmpeg and wmv9 do a pretty good job.

Is there any settings in the new WMP10 that improve playback on a progressive display interlaced encodes?

Thanks for any info you folks can supply.

Regards,

Webwonk

[Mug Funky]

xvid will also maintain interlacing, as well as good old fashioned mpeg-2. but then, practically any codec will handle interlaced images so long as you can spare the bitrate.

the deinterlace-on-playback is an issue though - with xvid you're usually at the mercy of the avi container, unless you're muxing it into mp4 or ogm/mkv.

to be honest, i've not tried maintaining interlace in most of my encodes as i don't have the hardware to really enjoy it (no DVD burner, or standalone mpeg-4 player), so i just keep the sources until i have the luxury of maintaining interlace.

for my own reasons, i wouldn't touch WMV with a thirty foot clown pole, no matter how good it may or may not be.

if you want motion-compensated deinterlacing, then you could always use MVtools by Manao. it takes a buttload of scripting and will be slow, but it's fun to play with. you will need a fallback deinterlace technique as well though.

[scharfis_brain]

Mug Funky: Did you had any success with MV-compensated deinterlacing with MV-tools?

[Didée]

Disregarding the fact that I'm an elephant in a china store, as soon as things come to (de)interlacing, I'd say that we currently cannot produce motion-compensated deinterlacing by means of the MVTools.

What would be needed is a special interlaced ME-mode that calculates motion vectors field-wise, taking the (present) opposite field as guidance to get the correct vector length for the reconstruction of the "missing" field.

Without such a mode, I fear all efforts are spoiled.

[Mug Funky]

@ scharfi:

what didee said is pretty much true. it's a chicken and egg thing. to motion compensate properly you need a very smart bob, and you're motion-compensating to achieve smart bob...

...but it is fun to play with, like with anything. the second law of thermodynamics didn't stop inventors trying to achieve perpetual motion :)

[Didée]

... , I fear all efforts are spoiled.
Wait a minute. Manao also presented us with MVCompensate() ...

What about te following:

Generally:

- Make a *soft* bob, e.g. TMCbob with "line averaging" active
- calculate fw & bw vectors
- selecteven/selectodd those vector clips
- apply MVCompensate to the original top/bottom field sequences, using those "decimated" vector clips, producing fw and/or bw compensated fields
- try and see if those can be used as-is, or if averaging fw(n-1) with bw(n+1) is better, or ...

Basically, here it is a problem that the vectors are created on a bobbed source with lack of vertical information, thus making the vertical coordinates of the vectors unprecise.
However, using a soft bobber should already dim the problem down. Additionally, one could try either of the following:

- Take the soft-bobbed clip, reduce its height by 2, then calculate the vectors
- Take the soft-bobbed clip, sharpen it vertically, calculate the vectors, apply ^^above procedure on the fields with point-resized doubled height, and reduce them again afterwards

... or something similar.

Vertical precision *might* be a problem, but it should be possible to make it minor enough. The vector lenghts, however, would be correct.

I suppose it could work. Or someone tell me why it obviously can't work.

?

[scharfis_brain]

I already tried a similar thing:

bobbing with stupid tmc(-1,-1,0)
mv-analysed this fwd & bwd towards the current frame/field

then mv-comensated the fwd & bwd ones and mixed them together.

but the result was just ugly, mv-tools were restoring the field they were analysed to, and not the missing field, so all jaggyness remained in the 'restored' field...