New motion compensated deinterlace filter (TomsMoComp)

[trbarry]

I've just released my new TomsMoComp.dll deinterlace filter.

This is a first cut at doing motion compensated deinterlace of video source material, but still doing it at a reasonable speed.

There are actually 2 versions in the zip file; one each for Avisynth and DScaler 4.0.

See the ReadMe file at www.trbarry.com/Readme_TomsMoComp.txt or get the source and DLL at www.trbarry.com/TomsMoComp.zip.

The Avisynth filter also offers a fancy new line doubling option to verically double the size of a (progressive) clip in a way that I think offers a bit more apparent detail than regular scaling. I'll post some samples and some more about that later.

Note this is NOT for film source, only video (ATSC, PAL, or NTSC). Use ForceFilm, DeComb, or GreedyHMA for telecined film material.

This is brand new so any feedback appreciated.

- Tom

[avih]

great tom :)
i'll test it.
how about moComp temporal filter now? ;)

best regards
avi

ps
add '.txt' to your readme link

[trbarry]

Avih -

Thanks. Link fixed now.

- Tom

[UGAthecat]

Too sweet!
I'm with avih also about the MC-temporal filter (as previously begged for here http://forum.doom9.org/showthread.php?s=&threadid=28138 :) )

I did some simulations in photoshop, and the really noisy source I referred to in the post above went from about 40% pixels being 'locked' with a threshold of 20, to about 90% of the pixels being locked when the previous frame was moved to compensate for motion in the new frame.

[Milkman Dan]

tom, I get a "Internal Error: MMX state left on: T:\projects\virtualDub_old\main\VideoSource.cpp:1101"

I have no idea where that path comes from. It's not present on my system.

I have a SSE-enabled Athlon.

[trbarry]

tom, I get a "Internal Error: MMX state left on: T:\projects\virtualDub_old\main\VideoSource.cpp:1101"

oops. Maybe in spite of my warning everyone else constantly about this I may have terminated without issuing an emms instruction. ;) Avery/Vdub has encountered this so often that he has now put in helpful checks for it.

I'll look for it.

But be aware it can also come from BiCubicResize in some versions of Avisynth.

- Tom

[trbarry]

Milkman Dan -

I can't find an exit from the program that has this error. (of course I'm as blind as the next guy)

Could you verify that it happens with all other filters removed?

- Tom

[Milkman Dan]

Sorry for taking so long. I removed all other filters. The error still occurs.

I didn't notice before that there is an AVIsynth read error just before the MMX state error. The address changes each time though.

[dividee]

Just tested your filter. Quality seems very good.
However, I had some access violations too. It only occurs with some combinations of parameters and clip properties, but I didn't find a pattern. For example, with res of 720x480 it only works with TopFirst=0 and SearchEffort<6. If I resize it to 704x480 it works for other parameters, but if I crop it to the same resolution it doesn't. Maybe pitch related? Also it sometimes cause a line of gargabe pixel at the bottom, particularly in "double height" mode (SearchEffort=-1) but not only.

[trbarry]

Grrrrrrrrr......

I have not been able to reproduce the error yet, much less fix it.

Could someone post a script that causes the error? And say what kind of machine and input file it is?

I certainly believe that it happens, it just does not yet happen here.

- Tom

[dividee]

LoadPlugin("TomsMoComp.dll")
BlankClip(width=720,height=480,pixel_type="YUY2")
TomsMoComp(1,0,1)
#TomsMoComp(0,6,1)
#TomsMoComp(0,5,1)
#BilinearResize(720,240).TomsMoComp(0,-1,1)

With the first two set of parameters it crash, the third one works. The last one gives me a colorful dotted line at the bottom.
I have an Athlon XP.

[trbarry]

dividee -

Thanks. I'll try that right away. Hopefully it will crash for me here also (what a thing to say ;) )

BTW, what release of Avisynth are you running?

- Tom

[dividee]

I was using the CVS code from about 24h ago.
Will try with older versions and report back.

[EDIT:] Same behavior with 1.0b7, 1.0b6, 1.0b5 and latest CVS

[trbarry]

Okay, I can crash it here too.

It looks like I process too many lines and fall off the end of the buffer. Unless it's the -1 doubling option. Then I process too few.

Fix soon.

- Tom

[tenebrenz]

how about moComp temporal filter now?

I'm still hoping that someone will write a filter that does temporal smoothing in still areas and spatial smoothing in moving areas which should be a little easier to code than motion-compensated temporal smoothing. I think if I mention it every few months maybe someone will :)

[Wilbert]

There is a VirtualDub filter who does exactly this (I think):
Use Freese website: Time Based Deinterlacer (http://www.uwe-freese.de/vdubfilters.html)

[Koepi]

Ah, too bad, that's a deinterlacer too. I thought you'd come up with a motion compensated temporal smoother ;)

trbarry, can you adopt the code from avisynth's temp smoother (or was it dividee's code?) to work with the found motion? :) (well, and be scene-change adaptive as well is somewhat important i guess...)

*hide*

Regards,
Koepi

[Wilbert]

Ah, too bad, that's a deinterlacer too. I thought you'd come up with a motion compensated temporal smoother :)

Oeps, sometimes I can't read :) Sorry ...

[trbarry]

Sorry guys, the bug is still not fixed. I mostly played hookey yesterday.

And I don't think I can easily adapt this as a temporal smoother.

- Tom

[Defiler]

Just checking in here re: 60fps output (from the CPU Optimization thread.)
Wanted to get on e-mail notify for this thread.
trbarry: Occasionally when I use Force FILM on a DVD that shows 99% film in DVD2AVI, I still get choppy pans. What do you think about leaving such a thing at 29.97fps and using TomsMoComp on it? Stupid idea?

[UGAthecat]

I think the only way us beggars are going to get a M.E. Based Temporal filter is if somone adapts the M.E. algos from XVid :rolleyes: . Just my guess, but I don't think Tom uses full on motion estimation :confused: .
Just out of curiosity, is this another fruit of the labor of porting DScaler stuff?
I just wish I had a portion of the C knowledge you guys are working with, I'd be able to devote all of this surfing/posting time to making something productive.

UGAthecat

PS - If anyone has good links or info on getting started with C++, which programs to use (Ive got VC++/VStudio6), and info on getting started on making filters for avisynth, please PM

[Defiler]

Originally posted by UGAthecat
PS - If anyone has good links or info on getting started with C++, which programs to use (Ive got VC++/VStudio6), and info on getting started on making filters for avisynth, please PM Seconded.

[poptones]

There's a bit on Graft's website. There's also a tutorial in the veedub "plugin sdk." The pixel formats are pretty easy, and the filters already in there provide a good working model.

That's how I learned to do it. And I can barely even drive the compiler (I still haven't a clue how to use the debugger; I just open VS and hit F7 when I'm ready to test). I'm pretty good in jscript, but I never spent much time learning c.

I still don't know much at all about gettings frames from media and such, but filters themselves aren't terribly difficult. Just pick one (I used "subtract" to figure out how to make the layer filter) and start hacking away at it. The rest of it is just figuring out how to do the math for the effect you want. And that's not specific to avisynth - that's just stuff you gotta google.

[trbarry]

I finally fixed the crash and green line bugs (Avisynth & (maybe) DScaler).

As before see the ReadMe file at www.trbarry.com/Readme_TomsMoComp.txt or get the source and DLL at www.trbarry.com/TomsMoComp.zip .

Now Version 0.0.1.2 though I forgot to update the Readme fix log.

- Tom

[trbarry]

Just out of curiosity, is this another fruit of the labor of porting DScaler stuff?

UGAthecat -

On this one I actually wrote the Avisynth version first as it is easier to test, but my coding habits and pieces-parts are mostly geared to writing for both these days.

The first (unreleased) version of TomsMoComp was using a block heirarchical scheme for larger motion search, and then a single pixel smaller brute force search. But I only released the 2nd half of it, for performance reasons. The rest didn't seem to help much more for deinterlace quality and probably would have needed a bunch more work.

I'll get back to it later on a faster machine. ;)

- Tom

[trbarry]

For anybody thinking about writing more filters see Ben RG's Writing Avisynth Plugins (http://math.berkeley.edu/~benrg/avisynth-extensions.html) page.

That's where I first started, with a copy of his Invert() filter.

- Tom

[dividee]

It doesn't crash anymore, but for two of the four test cases in the script I posted earlier it now gives a green line on top.
There are the cases with parameters (0,6,1) and (0,5,1).
At first sight, it seems it only happens when Topfirst=0.

[EDIT:] It's not the topmost scanline, but the third one from the top. (second line of the top field)

[trbarry]

Darn.

I tested with all your test cases but I guess I kept tinkering as I went along. Oops.

- Tom

[trbarry]

dividee (and all) -

It appears the problem was only with Bottom First and VF turned on.

If so it's fixed again. Pleas try Again.

- Tom

[dividee]

Yep, it seems all right now!
Thanks a lot for your great work! It still has to prove itself (anyone up for a comparative test?), but I think it's the best deinterlacer known to man ;)

[trbarry]

Thanks a lot for your great work! It still has to prove itself (anyone up for a comparative test?), but I think it's the best deinterlacer known to man

dividee -

Thanks. I wasn't making that claim for it it, but I can't afford a Teranex. ;)

- Tom

[Defiler]

Well, I hope you've got broadband, because I'm going to link to two test files I just created.

The first was made using the following AviSynth script:
LoadPlugin("C:\Bin\AviSynth\mpeg2dec.dll")
mpeg2source("D:\Projects\FUTURAMA_DISC_3\ep1\futurama.d2v")
LoadPlugin("c:\Bin\AviSynth\TomsMoComp.dll")
BicubicResize(640,480,0,0.5)
TomsMoComp(1,15,1)

I fed it to VirtualDub, and used XviD in 1-pass Quality, set to 85%.


The second was made with this script:
LoadPlugin("C:\Bin\AviSynth\mpeg2dec.dll")
mpeg2source("D:\Projects\FUTURAMA_DISC_3\ep1\futurama.d2v")
SeparateFields

I fed that into VirtualDub in Full Processing mode, and used the Deinterlace - Smooth filter to convert it to a progressive 50fps file.
After that, I fed it to Resize (Precise Bicubic A=0.6), 640x480.
Once again, 1-pass Quality, set to 85%.

Caveats: Clearly the resize process uses slightly different settings, and occurs at different stages, meaning that the two deinterlace methods are operating on input frames of different sizes. That shouldn't affect the smoothness of the output, though, and that's what I am interested in. I've fixed that in my latest test files, but I don't want to upload them again. Heh.

Also, this is hardly how I would normally encode these files. I'd be cropping off the borders, retaining more resolution, and doing two-pass with a higher bitrate, etc, etc. Still, they'll do for a simple test. They also serve to illustrate the file size impact of doubling the framerate. You will need at least an 800MHz CPU to play the second clip, unless I am much mistaken.

Without further ado, here are the test files.

1:
http://www.hellninjacommando.com/temp/tom-1-15-1.avi
2:
http://www.hellninjacommando.com/temp/tom-50fps.avi

I am so impressed with this plugin. I've got some real torture tests to feed it tonight, but it seems to give great results. Cheers!

[trbarry]

Defiler -

I've downloaded the files, but it's been a long long day and I'm heading off to bed now.

But you should never resize (except maybe InterlacedResize if absolutely necessary) before any IVTC or deinterlace filter. A resize operation can vertically blend field information before the IVTC or deinterlace filter gets a chance to decide which fields or pixels to use. It will confuse the process somewhat.

But I'll take a look at the rest of it tomorrow.

- Tom

[Defiler]

I realized that after I made the files. I repeated the test with A=0.6, and with the resize after the deinterlace, and it looked much the same. Not a big enough difference to bother reposting.

[WarpEnterprises]

@trbarry: Could you please explain in short what exactly means
that uses motion compensation .
I did a short test and the results where really good, but nonetheless I'm interested in the working principle and the difference to e.g. SmartDeinterlace.
I guess one difference is the way you decide which part of the image is moving.
But when it is moving which pixels do you use?

[trbarry]

WarpEnterprises -

Movement is determined not in blocks but a single pixel (actually a single byte, say luma) at a time. This happens in a very small area that more or less corresponds to the size of the SearchEffort parm.

So say SearchEffort=3. Then TomsMoComp would check only 3 possibilities for the value of a given weave pixel.

1) It moved one space to the right

2) It moved one space to the left

3) It did not move.

4) Otherwise we don't know. Use WierdBob.

Assume x,y,t refer to horiz, vert, and time.

For the case where it moved one space to the right then the value from the previous field at P[x-1,y,t-1] should match the value from the next field P[x+1,y,t+1] within some threshhold. If it matches then the average of the 2 is used. But even then there is a sanity check to ensure it does not create visible weave artifacts. (a vertical median filter)

If the value for that pixel doesn't closely enough match then we use the pixel value generated only from surrounding values in the current frame at t=0 using the WierdBob code.

The WierdBob algorithm is a variation of something I found in a paper on motion comp deinterlacing linked by someone in the Xvid forum when I first mentioned I was working on motion comp deinterlace. I'll go look for the reference but it was part of something called an ELA (or ELF?) algorithm, can't remember now. It was just a passing reference, even in that paper, but it dovetailed nicely into something I was already doing.

But I didn't use any of those sophisticated ideas for motion search. After writing a semi functioning heirarchical block motion search it appeared that for deinterlacing I got best real time results only detecting small motion, and for that I could go faster just brute forcing it in assembler on single pixels, but processed in MMXSSE 8 bytes at a time.

I've never looked at the code for Smart Deintelace so I can't explain the differences from that.

- Tom

edit: The WierdBob algorithm is really an ELA (Edge-based Line Averaging) technique. I can't find the link but I got the idea where it is discussed (but not originated?) in:

Y. -Y. Jung, B. -T. Choi, Y. -J. Park, and S. -J. Ko, "An effective de-interlacing technique using motion compensated interpolation," IEEE Trans. on Consumer Electronics, vol. 46, no. 3, pp. 460-465, Aug. 2000.

[WarpEnterprises]

I still have two problems.
1. The speed of the filter seems to be NOT depending on the search effort
2. A more general problem. (My test-material is self-made Hi8-recordings.)
The resulting video is quite sharp,
but when I view it on TV it looks "jumpy" (as if the shutter speed of the camera would have been to short).
In fast movements the information of one field is lost.
Is there a possibility to simulate a longer shutter speed so to get an effect like a speed blurring, but only in those image parts where the movement is so fast?

[trbarry]

WarpEnterprises -

The speed should depend upon the search effort but that currently max's out at about 27 or so. And in DScaler I can get 60 fps out of it with a SeachrEffort=13 setting. So maybe you can't notice the difference as much with all the other decoding/encoding overhead.

The jerkiness is maybe because under Avisynth it will take 50 (60 ntsc) fields / second and output 25 (30) full frames. Under DScaler it can output up to 60 full frames / second but I foolishly didn't support that for Avisynth. I'll try to add that later.

- Tom

[Defiler]

I've experienced the same "jumpiness" with this filter. Smooth -> Jerk -> Smooth -> Jerk.
No such problem with decomb.dll's FieldDeinterlace()
I've tried various search levels, mostly 21, like the Readme uses for an example.
I can post a short test clip to illustrate, if you'd like.

[trbarry]

I can post a short test clip to illustrate, if you'd like.

Defiler -

Yes, please if possible. I'm about to release a new version of this with horizontal doubling but because of all the various flavors and options it is a pain to regression test it. So if there is something I should fix first I'd really like to see it.

But please also post your avs script.

- Tom

[trbarry]

I don't usually encode clips at 60 fps because you have to store all the darn things, which take up more space. And at higher resolutions it even takes too much CPU to play them.

But for those of you determined to encode at 60 fps and who have machines capable of playing it, maybe you might experiment with the following scrips. These are based upon one by Poptones over in this thread (http://forum.doom9.org/showthread.php?s=&threadid=28568&pagenumber=3).

But try either:

# This script is only for TopFirst material
LoadPlugin("d:\save-oe\MPEG2DEC2.dll")
LoadPlugin("F:\TomsMoComp\Avisynth\TomsMoComp.dll")
Mpeg2Source("D:\VCR\Its_All_Here.d2v")
Top=AssumeFrameBased().ComplementParity()
Bottom=Top.SeparateFields.Trim(1,0).weave
return Interleave(Top.TomsMoComp(1,15,0),Bottom.TomsMoComp(0,15,0))


or

# This script is only for BottomFirst material
LoadPlugin("d:\save-oe\MPEG2DEC2.dll")
LoadPlugin("F:\TomsMoComp\Avisynth\TomsMoComp.dll")
Mpeg2Source("D:\VCR\Its_All_Here.d2v")
Bottom=AssumeFrameBased()
Top=Bottom.SeparateFields.Trim(1,0).weave
return Interleave(Bottom.TomsMoComp(0,15,0),Top.TomsMoComp(1,15,0))


Just an experiement. But if you preview both quickly in vdub it should be pretty obvious which one works best for your clip. Just step through a few frames with motion, one frame at a time.

- Tom

[poptones]

Is there a more up to date dll? When I try that script on my P2/450 I get a mofo of a crash.

[fisix]

not doing 60fps, but the plugin works beautifully and flawlessly on a boxing match captured off tv. the filter=1 looks nice.

i looked at the difference between a couple different options in fielddeinterlace by graft and tomsmocomp... and i could see obvious jaggs in diagonal edges in the progressive frames served by fielddeinterlace that WERENT THERE with tomsmocomp.

i thought at first it was a problem (in grafts) with which field came first, but in the process of ruling that out, i noticed that there didn't seem to be a difference in using field=1 or field=0. ? i guess the jags might just be an error in fielddeinterlace, but i'm concerned with not easily seeing a difference in field=0 or field=1 in tomsmocomp.

outstanding filter, tom. thanks.

-fisix

p.s. if yould like to see the frames, just let me know and i'll send them to you in email and you may post them (i can't webserve). your choice of gif, jpeg, whatever.

[WarpEnterprises]

Me too saw only very small differences between 1 oder 0. Try looking at lines, in one setting they look smoother, in the other a little bit staircase-like.

[Defiler]

Originally posted by trbarry

Yes, please if possible. I'm about to release a new version of this with horizontal doubling but because of all the various flavors and options it is a pain to regression test it. So if there is something I should fix first I'd really like to see it.

But please also post your avs script.Didn't notice your reply before I left for work today. I'll link an example this evening.

[trbarry]

Is there a more up to date dll? When I try that script on my P2/450 I get a mofo of a crash.

poptones -

There have been a couple versions, all listed above. You should be able to compare version info by right clicking on the dll, or just comparing the file dates of yours with the current zip. It's so small you might as well download again to be sure. But yes, the very 1st version would crash sometimes.

But if you are running the current version please email me. You are the only known P-II tester. I thought I wrote it so P-II was supported but something might have slipped through. But I'm sure we can find it and I'll send you another test version once we have an idea what's happening. I've now got the horizontal expansion (SE=-2) now working also but wanted to test a bit more before releasing.

All the source and project is in the zip. Can you compile it under VS6? If so, does it blow up on an unsupported P-II instruction or just fall off the end of the buffer like it did before?

- Tom (trbarry#trbarry. com #=@)

[trbarry]

Me too saw only very small differences between 1 oder 0. Try looking at lines, in one setting they look smoother, in the other a little bit staircase-like.

I should have mentioned in the Readme (but didn't) that the first (TopFirst) parm will be ignored and will have ZERO effect when SearchEffort is < 0 and only a very tiny effect when SE=0.

But for SE > 0 (when actually doing motion search) you will find that if you specify the TopFirst parm wrong then the motion search will more often fail to find a match and more often bob slow moving pixels. So the picture will be slightly more jaggie with slightly less detail.

Ah, a table: ;)


SE < 0 Doubling only, no motion search, ignore TopFirst
SE = 0 WierdBob only, no motion search, TopFirst effect small
SE > 0 Motion comp deinterlace, TopFirst matters


For those of you that have also downloaded my older GreedyHMA deinterlace filter there is some TopFirst discussion in the readme file and a couple AVS scripts in that zip to determine what the value of TopFirst should be. See www.trbarry.com/GreedyHMA.zip .

One of these days I'm going to have to see how Donald Graft made it automatic on some of his filters.

Avisynth actually keeps track of which it thinks is the dominant field but it often gets it wrong so that info is not reliable. Maybe instead we just need a generic AutoSetParity() filter the could look at the data on the fly and keep it correct. But I'm not sure how easy that would be. It can even change within clips due to edits, etc.

- Tom

[vlad59]

Hi Tom

I found a good interlaced source to test your script : it's The Lodoss Chronicles (an anime). And I found something strange :confused:

My script is following (it's simple) :

mpeg2source("C:\Temp\dvd\DVDVOLUME\lodoss.d2v")
TomsMoComp(0,10,1)


I found that bottomfirst works better for me (especially on scene change) but I got strange result (I've attached an png image in a zip)

The stranger thing is if change the searcheffor to 15 this buggy frame is good but I found another one buggy.

If I change the setting to top field first I don't have any problem (but the scene change are more crappy)

I can send you a 4 or 5 frame long hulfyuv if you want.

EDIT : removed attachment to save bandwidth (Tom already have a hulfyuv clip)

[trbarry]

I can send you a 4 or 5 frame long hulfyuv if you want.

Vlad -

Thanks, yes, I'd like to look at it.

- Tom

[Billy|B-A]

This may be a stupit question, but I am new to Avisynth and editing/making scripts. (truthfully i never knew that a avs file could be opened in notepad)I have a few questions about how to use it. Please think of me as a 5yr old child when explaining this.

1. Instead of using Avisynth can I just edit the avs file made by GordianKnot include TomsMoComp.dll?

sample script (http://personal.atl.bellsouth.net/atl/p/e/perdue3\opening.txt)

2. I installed Avisynth, so by doing this am i really just using the program anyway?

3. What do the setting mean? i.e.(1,0,1)

4. Can Avisynth read d2v files? (After a little pratice I may be able to skip GordianKnot

5. What commands are available? What do they do?

edit - Please disregard the settings, just doing so "how to kill this file" testing.

[manono]

Hi-

Until Tom gets back to correct-amend this response, I can fill in.

1. When you use an .avs, you are using AviSynth. And the answer is yes, you can manually edit the .avs created by GKnot.

2. When you frameserve using the .avs, you are using AviSynth.

3. Read the help file included when you downloaded it. The first number is top or bottom field first. The second number is motion search precision. The third number is whether or not to add in his vertical filter. And I believe TomsMoComp should be placed after crop, but before resize (like in with the Deinterlacer stuff of your GKnot generated .avs).

4. Yes-look at your "mpeg2source("D:\VHD\opening.d2v")" line in the .avs.

5. A big question I'm sure not going to answer fully. You might start by searching the AviSynth Docs (http://math.berkeley.edu/~benrg/avisynth.html) and the Language Tutorial (http://math.berkeley.edu/~benrg/avisynth-tutorial.html) and Luke's Guide (http://www.lukesvideo.com/avisynth.html). As for additional commands-plugins, see question 21 of the AviSynth Q&A At The Top Of This Page (http://forum.doom9.org/showthread.php?s=&threadid=25002) where you should have started in the first place.

[trbarry]

Billy|B-A

manano's pretty much covered it better than I could. I'll just elaborate on #4 a bit since it is not always obvious at first what goes on here.

Avisynth loads the mpeg2dec.dll filter. Then when the mpeg2source("D:\VHD\opening.d2v") command is encountered in the script Avisynth calls that function within mpeg2dec.dll. The mpeg2source() functions reads the .d2v file to find out how to randomly read and process the real mpeg2 file, passing back uncompressed records to Avisynth as requested.

- Tom

[Billy|B-A]

Cool, thanks for the help!! It really helped out alot.

[trbarry]

By default the end of the script is supposed to return the result of the last function. But I've had problems ending on some commands and so often put in an explicit return. But I don't think it is supposed to be needed.

- Tom

[Billy|B-A]

Heh...I kinda found that out myself. Then edited the post to only find out that you had answered my question when the page refreshed.

Thanks for the awsome filter. I am having the best results I have seen yet!!:D

edit:type-o

[1loser]

I'm a newbie at DVD encoding and my first conversion was from an interlaced source. I used the filter TomsMoComp(1,15,1). Does this filter change the video from interlaced to progressive? Not that I truely understand what that means.

LoadPlugin("C:\Program Files\DVD2SVCD\MPEG2Dec\MPEG2DEC.dll")
LoadPlugin("C:\Avisynth\temporalSoften2\TemporalSoften2.dll")
LoadPlugin("C:\Avisynth\TomsMoComp\Avisynth\TomsMoComp.dll")
LoadPlugin("C:\Avisynth\unfilter\UnFilter.dll")
mpeg2source("Croupier.d2v")
ConvertToYUY2()
TomsMoComp(1,15,1) not sure how to determine if the last value should be 0 or 1
BicubicResize(448,448,0.0,0.0,0,0,720,480)
UnFilter(60,60)
TemporalSoften2(2,5,5)
AddBorders(16,16,16,16)
ResampleAudio(44100)

Do the below results show that the encoding was done correctly? An example would be frame type changing from interlaced to progressive.

Vob file
Field topfirst: yes
DCT type: field
Quantscale: nonlinear
Scan type: alternate
Frame type: interlaced

Encoded video
Field topfirst: yes
DCT type: frame
Quantscale: nonlinear
Scan type: zigzag
Frame type: progressive

[WarpEnterprises]

Interlace is easy to explain: if you see those combed areas then it's interlaced, if not, the it's progressive.

All those flags you mentioned can be set arbitralily - the mean nothing how it really is! (of course often they are correct if YOU used the correct encode settings. e.g. you can encode interlaced even if the source is progressive and that results in more bitrate need,.
Take a look at http://www.100fps.com/ Good explanation.

And yes TomsMoComp is a very good deinterlacer (if you really need!)
The 1/0 gives little effect, set it to 1.

Care on those telecined videos. They look interlaced but can be made progressive again without "filtering", but only shifting the fields the right way (see decomb.dll from donald graft)

And if you are NTSC then there are pulldown topics (I'm PAL-only)

[manono]

Hi-

Yeah, I agree-I'm not sure you should be using it at all. It's meant for pure interlaced sources, not movies where you can Force Film or IVTC and return the progressive frames. If the source is pure interlace, there are no progressive frames to begin with or finish with. Maybe hakko504's Sticky (http://forum.doom9.org/showthread.php?s=&threadid=23776) will be useful.

[1loser]

Originally posted by manono
Yeah, I agree-I'm not sure you should be using it at all. It's meant for pure interlaced sources, not movies where you can Force Film or IVTC and return the progressive frames. If the source is pure interlace, there are no progressive frames to begin with or finish with. Maybe hakko504's Sticky (http://forum.doom9.org/showthread.php?s=&threadid=23776) will be useful. I opened a different file "jackson brown going home" in DVD2AVI and I get 98 % interlaced and I used the TomsMoComp filter, it seems I shouldn't have. I will check out the Sticky you mentioned. Thanks.

Originally posted by WarpEnterprises
Interlace is easy to explain: if you see those combed areas then it's interlaced, if not, the it's progressive.

Take a look at http://www.100fps.com/ Good explanation.

And yes TomsMoComp is a very good deinterlacer (if you really need!)
The 1/0 gives little effect, set it to 1.

Care on those telecined videos. They look interlaced but can be made progressive again without "filtering", but only shifting the fields the right way (see decomb.dll from donald graft)

And if you are NTSC then there are pulldown topics (I'm PAL-only) I have this http://www.100fps.com/ on my computer saved from a while ago and everytime I look at it I get confused. Maybe I'm trying to take in to many news things at once but I'll take another look. Looks like I need to look into "decomb.dll from donald graft" I didn't know that "TomsMoComp filter" is for pure interlaced and didn't even know it could be both progressive and interlaced.

When converting a DVD to a SVCD is the idea to always get the output to be progressive? That was my main concern here. I have a GUI interface for PulldownBatchFE and it has an option to NOT perform a pulldown BUT you can select progessive frames - mark each frame as progessive or interlaced. Will that option be useful here? It was easier converting DivX to SVCD I guess because I already had a progressive source.

Really appreciate your help here.

[droolian01]

Hi tom and all.

I got a rather nasty result using your tomsmocomp deinteralcer (i was late for work and just threw together a quick .avs - need to encode the cap again as the crop was wrong anyway!!) which is totally due to me being stupid and trying to use it on a telecined source. I even got the field order wrong!!! When used appropriately your deinterlacer gives excelent results.

The cap i was encoding kept changing field order (from editing??), had blured fields, you know the usual mix, and this got me thinking - why not use telecide to sort the field order followed by tomsmocomp to clean up what telecide left over.

I've tried this script with a couple of tiny test caps and the results seem very good:

telecide(post=false)
TomsMoComp(1,15,0)
crop(xxxxxxx)
simpleresize(464,368)

In the couple of very small tests i've done setting topfield=1 (true) was the correct setting both times. I'm hoping that this setting can be left permanently at 1 following telecide.

Hope this is ok (i think encoding time will be dramatically increased - have yet to do an encode of more than a few seconds) if this is just dumb on a theoretical basis please tell me and i can then abort the (probably massively long) encode now, as i have got a backlog of several buffy/enterprise/6 feet unders to do (again!).

What do you all think?

Thanks.

[Richard Berg]

If time is a concern I'd crop before doing the rest of the processing, but other than that I'll just have to try & see how it works.

[trbarry]

The above might work but I don't know enough about Telecide internal workings to be able to predict the results. If the field order is constantly changing then maybe there is no other good choice.

Please let us know. ;)

- Tom

[manono]

Hi-

I opened a different file "jackson brown going home" in DVD2AVI and I get 98 % interlaced and I used the TomsMoComp filter, it seems I shouldn't have.

I was talking about Croupier when I said it should probably be Force Filmed or IVTC'd and TomsMoComp maybe shouldn't be used. In the case of the Jackson Browne DVD, many concert DVDs are pure interlace and are prime candidates for TomsMoComp. There's an easy way to find out though. Make the .d2v with no Force Film, and then either open it in GKnot or make an .avs without Decomb and open that in VDub. Then scroll to some places where movement is easily seen. Then advance one frame at a time. If every frame is interlaced, then it's pure interlace, should be kept at 29.97fps, and TomsMoComp used on it.

[1loser]

Originally posted by manono
[I]Make the .d2v with no Force Film, and then either open it in GKnot or make an .avs without Decomb and open that in VDub. Then scroll to some places where movement is easily seen. Then advance one frame at a time. If every frame is interlaced, then it's pure interlace, should be kept at 29.97fps, and TomsMoComp used on it. I'm not sure what "force filmed means" but I loaded this script into virtualdub and in every 5 frames 2 are interlaced and 3 are not.

LoadPlugin("C:\Program Files\DVD2SVCD\MPEG2Dec\MPEG2DEC.dll")
mpeg2source("jacksonbrown.d2v")
ConvertToYUY2()
BicubicResize(448,448,0.3,0.3,0,0,720,480)
AddBorders(16,16,16,16)
ResampleAudio(44100)

This is the exact script I used with a bitrate of 2120 and got execellent results.
LoadPlugin("C:\Program Files\DVD2SVCD\MPEG2Dec\MPEG2DEC.dll")
LoadPlugin("C:\Avisynth\TomsMoComp\Avisynth\TomsMoComp.dll")
LoadPlugin("C:\Avisynth\unfilter\UnFilter.dll")
LoadPlugin("C:\Avisynth\temporalSoften2\TemporalSoften2.dll")
mpeg2source("jacksonbrown.d2v")
ConvertToYUY2()
TomsMoComp(1,5,0)
TemporalSoften2(2,5,5)
BicubicResize(448,448,0.3,0.3,0,0,720,480)
UnFilter(40,40)
AddBorders(16,16,16,16)
ResampleAudio(44100)

I still would like my main question answered please. When converting a DVD to a SVCD is the idea to always get the output to be progressive?I'm still confused about this

[droolian01]

Hi everyone.

Just encoded a capture of '6 feet under' using telecide(post=false) followed by TomMoComp(1,15,0). Firstly the encoding time increased about 1.5-1.75 that of using telecide alone, but the outcome did seem better. It is difficult to tell but tomsmocomp seemed to reduce the effect of the blurred fields always present in these american tv programs (when watched/capped in the uk) better than the postprocessing usually done with telecide. It is subtle but it seems that instead of geting mostly 50:50 blended fields, there are many fewer of these, most blends seem to be 75:25.
If i can afford the longer encode times in the future i may well use this again, or for 'special' encodes. Combining these two features (field matching and motion compensated deinterlacing) into one - hopefully quicker filter - may help with the curse of blended fields which i try sort nearly everyday capping us tv stuff.

Hope this is of any use/interesting.
Thanks again.

[trbarry]

droolian01 -

Cool. I didn't know whether it would work or not. And I'll bet it would be a heck of a lot faster if we could talk Donald Graf into adding a "Telecide(Post=TomsMoComp(,,)" option somehow.

- Tom

[Guest]

The problem with using TomsMoComp after Telecide is that it will degrade good progressive frames. FieldDeinterlace is specially designed to totally leave alone frames that it decides are not combed. I don't know if TomsMoComp has combing detection that would prevent it from ever being spoofed by content of a progressive frame, but I would guess not.

That is not to say that TomsMoComp could not be enhanced to work like this; but I am just getting clear of the personal issues that have kept me away from video and it is some time still before I can begin to think about that.

[droolian01]

Hello neuron2!

I'd hoped that the progressive frames wouldn't get affected by TomsMoComp. I only tried it on one encode, and the effect did seem subtle (more likely the filters in my brain connected with visio-spacial discrimination were more active than any avisynth script!!)

Anyway thanks for the explanation, glad to see you post again - we (well me anyway!) need your guidance!!

See Ya

[Guest]

Thank you, droolian01, for your kind words. It is good to be back.

[trbarry]

The problem with using TomsMoComp after Telecide is that it will degrade good progressive frames. FieldDeinterlace is specially designed to totally leave alone frames that it decides are not combed. I don't know if TomsMoComp has combing detection that would prevent it from ever being spoofed by content of a progressive frame, but I would guess not.

Hi Donald -

Glad to see you back.

It was concern for the above that prompted me to suggest being able to all TomsMoComp only on interlaced frames. This filter is optimized ONLY for interlaced video source, unlike Decomb or GreedyHMA. I made a choice to give up the generality to hopefully get better deinterlacing.

It should still give decent results, better results than bad pulldown processing, but it definitely won't be as good as proper IVTC on well mastered progressive or telecined source.

And I wasn't intending to try to make it more general purpose in the future either. This one is for video.

- Tom

[Guest]

Hi Tom,

Yes, of course. I fully understand. I was responding to the person who suggested replacing FieldDeinterlace with yours as the post processor to Telecide.

I will have some feedback for you on TomsMoComp shortly.

[Belgabor]

Hi Tom,

nice piece of work. :D

Unfortunately I found a few artefacts for you :/

(left is original, right after TomsMoComp(1,5,1). I tried diffrent searcheffords, no diffrence)

Cheers
Belgabor

[trbarry]

Yikes! What is that? Are you sure it is even video source or is that a blended frame? Or both?

For search effort you should be ok, though you might check the TopFirst parm. But I found out today that SearchEffort=5 or less will have fewer artifacts, at least for some sources. Above that level TomsMoComp will start also doing vertical motion comp which seems more vulnerable to video noise for some reason I don't yet understand.

Is is possible you could post or send me about 10 frames or so? (no more). Or if not, could you at least try it with SearchEffort=0 (no motion search) and let me know the results? Note TopFirst does not matter (much) in that case .

- Tom

[Belgabor]

Gosh, I should have been more specific, sorry. I dun mind the blending that much (and yes, your're right, the source has blended fields. you gotta love such anime on PAL -.-). What I meant where those pixels that shoulndt be there.

I made the clip, its about 3.5Mb. How can I get this to you?

Setting Motion search to 0 gets rid of the pixels.

[EDIT] Damn, i just realized how f**ked up this source really is. Almost every interlaced frame has a blended field :(

Cheers
Belgabor

[trbarry]

Belgabor -

Hopefully that is small enough you can just email it to me, though I'm not sure what my limit there is anymore.

But try trbarry@trbarry.com

Please send the input clip though, not the results. Maybe I can figure out what is going on.

- Tom

[Belgabor]

What your filter most seems to hate are only slightly blended fields as you can see in the attached picure (which is left to right: original, separated fields, TomsMoComp(1,0,1), TomsMoComp(1,1,1)) You have to look a bit carefully to notice the small blending.

Cheers
Belgabor

[trbarry]

Belgabor -

I've got the clip but probably can't offer any more help. It is not something that can be deinterlaced. I don't know how certain blends can cause those artifacts but maybe it will become obvious over time.

I even have a newer version I was testing but it did not help any.

All I can suggest with very blended or pathological material is to try both (1,0,1) and (0,0,1), which I guess you already have. The first will use only top fields and the second only the bottom fields. I even thought I had a solution for you at first because your short clip starts out with only bottom blended fields, but then it switched to both.

Sorry I can't offer anything more useful.

- Tom

[Belgabor]

Doh, doh, doubledoh! The only thing i never tried was trying the other field order! Sorry ^^'

Kinda thought if that would have been wrong, nothing should have worked.

Anyways, :stupid:

Works like charm with (0,...)

Cheers & tanks for your efford
Belgabor

[cweb]

Tomsmocomp with these parameters
video=TomsMoComp(video,-1,5,1)

gave me good results with an interlaced PAL dvb-s source clip...

I hadn't tried it before and I was surprised to see the quality of the result.

[mf]

Man, talk about digging up an old thread there! This one's about 1,5 years old!

[cweb]

Yes, that's true, but I wanted to point out a use I found for it.
It was a recording of a news clip which had some 'noise' (moving areas).
It worked on it like magic....

[trbarry]

Heck, I was pleasantly surprised. When I saw this thread bubble to the top I was afraid it was someone reminding me I'm still procrastinating on a new version. ;)

- Tom

[mf]

Originally posted by trbarry
Heck, I was pleasantly surprised. When I saw this thread bubble to the top I was afraid it was someone reminding me I'm still procrastinating on a new version. ;)

- Tom
A new version would of course be nice. If you could make one that can retighten combing from field-separated upsizing, I would be very thankful :). Current TomsMoComp drops most of the second field when I try that.

[trbarry]

A new version would of course be nice. If you could make one that can retighten combing from field-separated upsizing, I would be very thankful . Current TomsMoComp drops most of the second field when I try that.

Sorry. I'm not sure what you mean by that. Could you elaborate a bit. As long as SearchEffort > 0 it should use the second field when the motion is still or slow enough to compensate.

- Tom

[Soulhunter]

Psst ...and remember the 3D version of AddGrain !!!

Bye

[mf]

Originally posted by trbarry
Sorry. I'm not sure what you mean by that. Could you elaborate a bit. As long as SearchEffort > 0 it should use the second field when the motion is still or slow enough to compensate.

- Tom
Okay.

Original frame:
http://lsoust.hypermart.net/sntmc/sntmc-original.png

Interpolated first field:
http://lsoust.hypermart.net/sntmc/sntmc-field1.png

Interpolated second field:
http://lsoust.hypermart.net/sntmc/sntmc-field2.png

Interpolated fields weaved:
http://lsoust.hypermart.net/sntmc/sntmc-weaved.png

Weaved image downsized (equivalent of a field blend):
http://lsoust.hypermart.net/sntmc/sntmc-blend.png

Weaved image processed with TomsMoComp(0,15,0):
http://lsoust.hypermart.net/sntmc/sntmc-weaved-tmc.png

Now here is where it gets interesting. Already you can see a lot of vertical resolution is lost. I see vertical pixelation as if the image was pointsized. Now to make my above point clear,

TomsMoComp'ed image downsized:
http://lsoust.hypermart.net/sntmc/sntmc-weaved-tmc-sizedback.png

Looks pretty much identical to our field 1 interpolation that we originally had, which forces me to conclude most of the second field was thrown away. This is what I mean with "re-tightening combing from field-separated interpolation". TomsMoComp or at least something motion-compensated is the only proper way to do this properly. As you can see the interpolation of the fields alone is already very good, but for fine details you really need the second field too.

[trbarry]

mf -

I'm not sure what you are doing here but there is no way that TomsMoComp(0,15,0) will make a 960 line frame out of a 480 line frame. So something else is going on.

Could you post your script?

- Tom

PS - I don't recommend ever using SE > 5 anymore. It causes single stray pixel artifacts in a way I don't completely understand. So maybe use TomMoComp(0,5,0) instead. I'm probably going to just disable SE > 5.

[mf]

Originally posted by trbarry
mf -

I'm not sure what you are doing here but there is no way that TomsMoComp(0,15,0) will make a 960 line frame out of a 480 line frame. So something else is going on.
It's not TomsMoComp that's doing the interpolation, I just want to use TomsMoComp on the interpolated picture (which worked before for SSTomsMoComp (http://forum.doom9.org/showthread.php?s=&threadid=66540&highlight=sstomsmocomp), so don't tell me I'm trying to do impossible things :D)

Could you post your script?
Sure.

sn = last
sn.SangNom(0)
sn1 = last

sn.SangNom(1)
sn2 = last

Interleave(sn1, sn2)
Assumefieldbased().Weave()

TomsMoComp(0,15,0)
LanczosResize(input.width, input.height)

[trbarry]

I have no idea what SangNom means. Should I? ;)

- Tom

[Kurosu]

mf is acting "l33t" (elite) because he got on a french board a new MarcFD's plugin. It's said to be edge-directed. Seeing how it was implemented (Avery Lee's resizer was maybe a start point) could be interesting.

As for the name, which mf may not have figured, let's spoil the fun: it means Blood(y)Name (ie the heck if I have an idea of a name for that filter - or maybe WithoutName with a pun intended).

[mf]

Originally posted by Kurosu
mf is acting "l33t" (elite) because he got on a french board a new MarcFD's plugin. It's said to be edge-directed. Seeing how it was implemented (Avery Lee's resizer was maybe a start point) could be interesting.
Would l33t in this context be positive or negative (I will have to suspect the latter)? I'm just experimenting. I wanted to recycle my idea for SSTMC (replacing SangNom as the interpolator, in SSTMC I use TMC's internal interpolation) for SangNom but it seems there are some problems, which is why I posted here. As for the french board: it's not my fault that MarcFD doesn't post here anymore. And about the name: I couldn't care less what name it has. As long as it just does what it does now, which is nice and pretty interesting.

[trbarry]

so don't tell me I'm trying to do impossible things

Well, I won't. But I can't resist commenting that you don't seem to be very happy with the results and there is no way I can help from info available in the posted script. ;)

- Tom

[mf]

Originally posted by trbarry
Well, I won't. But I can't resist commenting that you don't seem to be very happy with the results and there is no way I can help from info available in the posted script. ;)
What further info do you need?
French info on SangNom (http://atlas2.tgv.net/~media-video/forum2/viewtopic.php?t=3655)
Direct download link for SangNom (http://mf.creations.nl/avs/filters/SangNom.dll)
What it does: it's an edge-directed interpolator that throws away the second field (based on parity), much like TMC with motion search -1. I don't want it to throw away the second field :D.

[Sigmatador]

Originally posted by mf I don't want it to throw away the second field :D. [/B]

Encode at 60fps :p

[bilu]

Originally posted by mf
What it does: it's an edge-directed interpolator that throws away the second field (based on parity), much like TMC with motion search -1. I don't want it to throw away the second field :D. Looks very good. Maybe good enough to discar a field? :D


Bilu

[mf]

Actually, you are both right. The interpolation is good enough to actually use it in Bob-mode, there is virtually no real bobbing going on except on the edges. With a comb mask it'd be great. However, if it were motion-compensated, you wouldn't even need a comb mask, in theory :D. Of course, that's in theory, so if you'd use a comb mask with it being motion-compensated, you'd have even better results :p. Bah, I'll stop fantasizing. Nobody's gonna make a motion compensator that's good enough :rolleyes:.

Yes trbarry, you may interpret that as a challenge to prove me wrong if you want.

[billou2k]

Hello there,
I captured some dvb stuff that I reencoded in xvid interlaced 720*576.
I'm looking for a good way to play it back on a computer screen.
I've had a look at several filters that can operate at the player side (I'm using mpc): decomb looks to be one fo the best at 25fps playback (not showing the stroboscopic effect than some others do by blending fields).
Smoothdeinterlace at 50fps looks like one of the best method but it looks like it requires a huge processing power (and it doesnt work with latest avisynth 2.5)
I've had a look at Dscaler too although some plugins look quite good the app doesnt look very stable and playback just freezes from time to time and using dscaler option in ffdshow doesnt look very stable either.
However I'd really like to have the playback at 50fps without complicated processing or motion search so that it could be played on my machine. Is it possible?
As we are quite happy with the way TV playback interlaced stuff I was wondering if there was a method simulating the way TV handles that..
Now there is the question of how TV is doing:
Is it just displaying a new field every 1/50th second on top of the previous one? or is it displaying it between the lines of the last displayed field? or something else?
In the first case "scalerbob" in Dscaler would do a similar job as tv wouldnt it?
Thanks

[kassandro]

Originally posted by billou2k
Is it just displaying a new field every 1/50th second on top of the previous one? or is it displaying it between the lines of the last displayed field? or something else?
Thanks
It is displayed between the lines of the last displayed field and the human eye has the impression of seeing both fields without any combs at once. That's the magic of interlace.

[billou2k]

thanks Kassandro
I guess it's been answered ages ago but I couldnt find it on the forum: so is it possible to simulate it with our monitors? or does it exist? They all have high refresh rates so we could think we should be able to simulate it in an efficient way couldnt we?
Now I guess that's not as easy as it seems as most of the 50fps solutions I found are high complexity deinterlacers that do motion estimation etc...

[mf]

I've thought about this many full moons :D. It's not only a trick of the eye but also of slow phosphor. Phosphor keeps its lit state for a short period after being shot by electrons. This makes for a kind of natural field combination with a temporal bias. Combine that with slow human vision, and you have a display that retains its full resolution (both fields) when the picture is static but only half when the picture is moving. Because of the nature of basic (bilinear, bicubic, lanczos) interpolation, the image is greatly distorted between fields. Bob doesn't have the natural advantage of the interlaced screen, but only relies on the eye trick. This makes for a very instable image even in static picture. I've been thinking of an adaptive Bob that uses either point resampling (just like a real interlaced screen) or edge-directed resampling (after seeing the approximation of SangNom being so accurate), and run an adaptive smoother with a temporal radius of two frames (fields), with the field alignment altering constantly (meaning that pixels get evaluated between frame 0 field 1 and frame 1 field 0, and frame 1 field 0 and frame 1 field 1, etc). I have no idea how this would work out even in theory, but it was my idea anyway :).

[Mug Funky]

hmm... nice idea (wtf? i have no clue :))

one nitpick - the effect of phosphorescence only lasts a few lines.

try take a photo of a TV screen at a shutter speed less than 1/50. it's rather like exponential decay in cooling, and i've never been able to move my eyeballs fast enough to notice this effect.

i'd love to see edge-direction and motion compensation together at last though. definitely.

(wow... this is an OLD thread! hehe)

[mf]

Originally posted by Mug Funky
one nitpick - the effect of phosphorescence only lasts a few lines.
Then explain to me how it comes that certain old monitor types that happen to have a slower phosphor will appear to flicker less than newer ones (same goes for TVs) at the same refresh rate? :) Observation has proven that the effect reaches beyond "a few lines". Also, I've noticed that modern TVs appear more easily "pixelized" - the jagged edge you see when an object on an interlaced screen is in motion. I've done some comparing in TV shops with a lot of screens displaying the same signal :).

[Mug Funky]

ah, yes. i thought about old green monochrome screens, but didn't bother to mention it. those were SLOOOOW.

my current tv has only about 100 lines of phosphorescence, and none of them are above half the intensity of the actual scan.

of course on an older tv there might be a more visible effect, but i've only ever noticed pixellation and apparent interlace artifacts when watching telecined NTSC (which i avoid like the plague for obvious reasons in PAL land :))

artifacts are easier to spot with less scanlines

[kassandro]

I can't believe in phosphorescence. If it were true, then you must see combs in the presence of motion, but I have never seen any on TV. When I watch CNBC on my digital satellite TV card, it is very difficult to read the ticker tape, because the numbers are moving fast and interlace makes them almost unreadable. On the other hand, if I watch the same program on TV the numbers are just sharp. There cannot be phosphorescence. I think the flicker is due to the whimpy 50 fps. The Americans with their 60 fps are much better of in that respect.

[mf]

Originally posted by kassandro
I can't believe in phosphorescence. If it were true, then you must see combs in the presence of motionWrong. The other way around. If the phosphor is too fast you see combs. Just put your computer monitor in interlaced mode (if you have an ATI card, nVidias don't support it). Most of the combs are invisible but some come through.I think the flicker is due to the whimpy 50 fps. The Americans with their 60 fps are much better of in that respect.Beside the point. I'm talking about that flickering gets worse or better at the same exact refresh rate with varying monitors (and thus phosphor types). If you want to test it for yourself, take a brand new LG or whatever monitor, put it at 60Hz, and then compare it with the same brand from a few years back (I've tested it with an Iiyama 21" from 1995). Same resolution. Same refresh rate. Less visible flickering.

(We are getting pretty off topic though - might want to resume discussion about deinterlacers before a mod feels the need to intervene)

[billou2k]

I dont think it is that offtopic. After we re taking about why we have to deinterlace. On the opposite I think it's intersting if we can make our mind on what really are the differences between interlaced tv playback and pc monitors and why it is so difficult to play interlaced material on a monitor.
If you have got/found technical articles about it that would be great to share here as well I think. That's intersting to read all your opinions.
As for the basic deinterlacing filters existing at the moment is there one that basically plays back a 25/30 fps video at 50/60fps and simply refreshes a field every 1/50th 1/60th of second between the lines of the previous field?
(just to see what it looks like)

[mf]

It is not so hard to display interlaced material on a monitor - you just need a proper videocard and a CPU beefy enough to handle the InterlacedResize() to your display resolution. I've tested it with telecined anime at a high refresh rate (100Hz) in interlaced mode, and even if the refresh rate doesn't match(!) the output looks smooth and not combed. Only sometimes does a little combing come through (at low motion) - which apparently doesn't change or go away by matching the refresh rate to the video framerate (60hz). I was amazed at the fact that it just looked smooth, as I've never seen telecined material on a real TV before (I live in PAL land so if anything's been telecined it's also been converted back to PAL causing choppiness).

[kassandro]

Originally posted by mf
Wrong. The other way around. If the phosphor is too fast you see combs.
Almost by definition, you can only see combs if two fields (with a time difference) are displayed simultaneously and this can only happen if phosphorescence lasts too long and not if it is too short. Probably, if you would have watched tv on these old green monochrome screens you would have seen combs. If phosphorescence would last longer than 1/50 of a second then you would begin to see combs for PAL clips. On the hand, if phosphorescence is too short, than you would see flicker. Ideally you would like to have phosphorescence a little bit less than 1/50 of a second and then to disappear instantly. Unfortunately, this is impossible, because the decline of phosphorescence is more or less exponential in time. That's why a high vertical frequency is so important to reduce flicker. The high priced 100 HZ tvs therefore display each field twice, to reduce flicker.

[kassandro]

Sorry I was quoting instead of editing!

[scharfis_brain]

If you want to see, how a TV work, try to simulate that with my scanlines-simuator
TVdeint


a normal 50Hz (60Hz) TV should work like this:
tvdeint(0.2).temporalsoften(some strong parameters)

a really cheap 100 (120) Hz TV works like this:
tvdeint(0).selectevery(1,0,0).temporalsoften(...)
(this TV will have reduced area-flicker but line-flicker is not gone)

a better 100/120 Hz TV uses complete bobbing-deinterlacing with thresholding to reduce all flicker

[kassandro]

No! The combs are just replaced by ghosts, which is typical for blur deinterlacers. On a TV you have neither ghosts nor combs. I think the human brain "remembers" the old field with a motion correction such that it fits to the new field, which is just displayed. From this point of view the sharp impression of interlaced tv is just an optical illusion, which you simply can't emulate on a computer screen.

I simply loaded the wrong script. Now the flicker is so strong, that nobody would watch such kind of tv. I have a two week old 19 inch TFT-display (DVI connected), though.

[MfA]

100/120 Hz tvs use motion compensated deinterlacing (of a slightly higher calibre than TomsMoComp ;).

[scharfis_brain]

@MfA: only the really expensive ones.
the cheap ones are only displaying every field twice (flickering on thin lines)
the better ones have thresholded deinterlacing (stairstepping)
and the best ones have motion-compensated deinterlacing and/or fieldmatching for PAL/NTSC-Film.

[Mug Funky]

interestingly enough, the REALLY cheap 100hz prog TVs actually display combing! just like a computer screen.

[Didée]

Well, I'm sitting here with a 100Hz TV of Phillips. It's the "biggest" model they offer without their "true motion" technology.

- On motion, some little ghosting is present - must be combing, but in fact I cannot spot it as such.

- scrolling text is 100% combed, and often just un-readable.

Now, is a device for € 1200.-- really THAT CHEAP? I had expected a little more of it!

- Didée

[scharfis_brain]

hehe, saw that on a sony, too

that must be some kind of deinterlacer, that doubleweaves lowmotion-areas and bobs high motion.

scrolling text has maybe not enogh motion for getting bobbed.

this means that probably a too high threshold for motion dectection is choosen.

Aren't there any hidden menues or options to customisze the deinterlacing of yout Philips TV?


btw. I really dislike 100 Hz TVs because they cannot reproduce the input-signal as it was.
Most of them also apply some kind of image-(dis)-enhancement, which ofversharps edges, flattens detailed areas, smears motion.

I like my good old pure analogue 50 Hz-TV with a slow Phosphor, which makes the 50Hz flicker not that noticeable...

[avih]

or, just get a BIG (and good) progressive monitor, and use dscaler ;)

OT: the only issue i have with dscaler is that i can't sync the monitor refresh 100% to the video signal frequency (or a multiple of it).

i actually think that dscaler CAN do better in this department (use some software schmidt-trigger to 'move on' to the next frame sync). otherwise, every once in a while i get about a full sec of 'matching refresh rate to video freq' jitter...

i wouldn't mind even dropping/dupping a field once in a while instead of a jitter for a full second. i just want it smooth ;)

[Leak]

Originally posted by avih
OT: the only issue i have with dscaler is that i can't sync the monitor refresh 100% to the video signal frequency (or a multiple of it).

i actually think that dscaler CAN do better in this department (use some software schmidt-trigger to 'move on' to the next frame sync. otherwise, every once in a while i get about a full sec of 'matching refresh rate to video freq' jitter...

I haven't used DScaler for some time since I hardly watch TV anymore (and if I do, I do it on our 16:9 set), but I guess at least version 5 should be able to fix that using Reclock since it's using DirectShow all the way...

Of course, version 5 also got it's own MPEG2/DVD decoder so it'll be perfect for watching DVDs, but alas it's still some way off... :(

np: Latyrx - Latyrx (The Album)

[avih]

well, reclock adjusts the VIDEO (through the audio) playback speed to match the monitor's refresh rate. but with TV playback (or an external video signal) you just can't change its rate. it's a broadcast. all you can do is either change the monitor's refresh rate in few ppm (part per million) to match the video (probably depends on the capabilities of the display card, i know my old voodoo3 could do that), or dup/drop fields (was frames) once in a while to get back into sync. mind u, i'll assume a monitor refresh a double of the field rate (i.e. pal 50Hz, monitor 100Hz). so by adjusting using 1/100 of a sec, it could be hardly noticable, but much smoother.

[Leak]

Originally posted by avih
well, reclock adjusts the VIDEO (through the audio) playback speed to match the monitor's refresh rate. but with TV playback (or an external video signal) you just can't change its rate. it's a broadcast.

Ugh, you're right - what was I thinking? *bangs head on desk*

np: The Orb - Rose Tinted (Dal Vivo A Roma)

[TEB]

Hi. when using .info in avisynth 2.5.6 it still says Parity: top field first after using this deinterlacer.. sHouldnt avisynth report progressive?

[Wilbert]

AviSynth keeps track of whether a given clip is field-based or frame-based. If the clip is field-based it also keeps track of the parity of each field (that is, whether it's the top or the bottom field of a frame). If the clip is frame-based it keeps track of the dominant field in each frame (that is, which field in the frame comes first when they're separated).
http://www.avisynth.org/AssumeFieldFirst

[TEB]

thx for the response but i still dont get it...:( I thought the point to deinterlacing was to make the frame progressive, hence one shouldnt need to set that avisytht variable? Or am i missing something major here?

[Wilbert]

Currently (v2.5x and older versions), AviSynth has no interlaced flag which can be used for interlaced video. There is a field-based flag, but contrary to what you might expect, this flag is not related to interlaced video. In fact, all video (progressive or interlaced) is frame-based, unless you use AviSynth filters to change that.
http://www.avisynth.org/AdvancedTopics