Deinterlacing alternatives?... and short guide of my current method.

[EBITDA]

OK, here it is. My first post to the doom9 forum since after having been a lurker for almost two years. I would have posted sooner, but I always seem to find the anwsers to my questions quickly on this great forum. However, I have now come to a point where I've not found an answer quickly to a question/request. Also, since I've been a lurker for so long and received much benefit, I'm going to provide some input instead of simply asking for a solution to my problem. ;)

OK, now the question/request, and then, I'll explain a deinterlacing method that I have been using for almost two years for anyone who is interested.

I am looking for filter(s) that have both a 60 frame per second option (like DGBob) and a "smoothing" option like TomsMoComp.

Both DGBob and TomsMoComp are great filters in their own right. However, it would be great if their full feature sets were merged into new versions. For example, a version of DGBob that has a "smoothing" feature like TomsMoComp and a version of TomsMoComp that outputs 60 frame per second material.

I would love to see a version of TomsMoComp that outputs 60 frames per second. The 30 frame per second output that the current version outputs is almost as fluid as 60 frame per second output by DGBob. Unfortunately, I have to say "almost" and that is why I am hoping that there are filter alternatives to create 60 frame per content with the fluidity of DGBob AND the picture quality of TomsMoComp.

Any ideas would be much appreciated. :)


Now, as a "pre-emtive" favor to anyone who has read and/or responded to my post, here is a description of the method that I currently use to convert NTSC material to 60 frames per second.

First, a preface as to why I want 60 frames per second.....I am a bit of a perfectionist with few limits when it comes to hardware resources so "perfect" for me means 60 fields per second interlaced should be converted to 60 frames per second progressive. I know that this creates a file that requires considerable CPU resources, but my good ol' 1.4GHz AMD Athlon system handles the 640x480 60fps files without any problem. :)

My Deinterlacing Method. (Requires TMPGEnc and VFAPI)
I have been using TPMGEnc to convert NTSC material from interlaced to 60 frames per second progressive format. I have been using the program's deinterlace filter and setting it to "Even-Odd field (field, adaptation)" Obviously, even-odd means that TMPGEnc is using both fields and is creating 60 frames per second output. Using "Even-Odd field (field, adaptation)" versus "Even-Odd field (field)" helps eliminate the bouncing effect in straight horizontal lines so I always use it.

1) Load the interlaced avi, .d2v, .avs file into TMPGEnc.
2) Click the Setting button on the bottom right corner.
3) When the MPEG Setting window pops up, click the Advanced tab.
4) Make sure all filters are unchecked and double-click on Deinterlace.
5) When the window pops up, select Method "Even-Odd field (field, adaptation)"
6) Now, to ensure that you have the field order set correctly, click the right arror of the horizontal sliding bar below the video window.
7) Hold down the mouse button and let the video play for a while.
8) If the motion is jerky at all then the field order needs to be reset, click OK and then reset the Field Order setting shown in the Video Source Section to the other setting. If the motion was NOT jerky, then simply hit OK.
9) Once back at the MPEG Setting window, make sure the Deinterlace filter is still checked and hit OK.
10) Open the File Menu and choose Save Project.
11) Save the project.
12) Run VFAPI.
13) Open the project file into VFAPI by clicking the Add Job button.
14) Once loaded, click Convert and VFAPI will create a "psuedo" avi file that can be then loaded into any app that accepts avi files as input.
15) Now you can convert the file to DivX, XviD, RV9....etc.

I have found that this method provides excellent ouput. Both fluid and sharp. Yes, the 60fps files do tax the CPU more, but a 1.4GHz Athlon can handle the files perfectly fine, especially when played with BSPlayer and DivX postprocessing set to minimum.

So, you're askin', if the output is both fluid and sharp, why switch to an Avisynth based process? Well, the problem that I have with TMPGEnc is that the darn program converts everything to RGB. With the color conversions from YUY2 to RGB, the final output always appears slightly darker with more contrast than the original.

Also, since Avisynth works in both YUY2 and YV12 colorspaces, I think that an Avisynth based method will very likely be faster.

So, there is my current method. Anyone who has both TMPGEnc and VFAPI should give it a try and let me know your opinions. Especially with the adaptive method being chosen.

Also, when I get some time, I'll post in detail how I capture live NTSC TV programs in 704x480, convert to 640x480 60fps progressive, edit commercials out, and convert the video to DivX, audio to MP3 or Vorbis, and merge both with perfect sych every time. :)

Cheers!

[trbarry]

A couple times now I've sat down and started changes to TomsMoComp to put out 60 fps but gotten side tracked on both occasions, and won't have time to do it soon now.

But if you do a search there is a AVS script function around here somewhere you can use with TomsMoComp that will do it, just not quite as fast as native. It's called something like TomsMoComp60 or something like that.

- Tom

[stickboy]

Was it TomsBob (http://www.avisynth.org/index.php?page=TomsBob)?

[Richard Berg]

I have to admit that I barely tested TomsBob -- if it works, great, but don't come after me if it breaks :)

[trbarry]

I wasn't referring to TomsBob but to a couple script fragments I've posted before, though I can't find the posts now. But I did find the AVS scripts. Either of those below will deinterlace NTSC or PAL video to 60 or 50 frames / second, respectively. To use them you have to first know whether the clip is stored in a TopFirst or BottomFirst order. See my thread about Useful function for checking TopFirst (http://forum.doom9.org/showthread.php?s=&threadid=34511&highlight=useful+function) for doing this. This all could easily be made into an automatic function now since MPEG2DEC3 returns the proper topfirst value these days but I'm afraid I don't have time to create and test new functions today. So for now just use the correct TomsMoComp function below.

edit: I deleted the word "return" on the last line of both sample scripts so you can add statements after them. I also turned off the TomsMoComp vertical filter options - Tom

If your clip is top first then use:

# TomsMoComp60T.avs, for Top First video
Mpeg2Source("D:\VCR\whatever.d2v")
Top=AssumeFrameBased().ComplementParity()
Bottom=Top.SeparateFields.Trim(1,0).weave
Interleave(Top.TomsMoComp(1,5,0),Bottom.TomsMoComp(0,5,0))


and if it is bottom first then use:

# TomsMoComp60B.avs, for Bottom First video
Mpeg2Source("D:\VCR\whatever.d2v")
Bottom=AssumeFrameBased()
Top=Bottom.SeparateFields.Trim(1,0).weave
Interleave(Bottom.TomsMoComp(0,5,0),Top.TomsMoComp(1,5,0))


These scripts were created last fall for Avisynth 2.0x/YUY2 but should probably still work okay for Avisynth 2.5 and YV12.

- Tom

[EBITDA]

Thanks trbarry.

I'll try the scripts tonight and will discuss the results after I've tested them a little.

I'm assuming that all of this should be typed in the avs script BEFORE any cropping, trimming, and/or resizing. Please let me know if this is correct and if not, what advantages there might be in cropping, trimming and/or resizing before applying the TomsMoComp60T(B).avs language.

Thanks again! :)

[Xesdeeni]

You might also want to look at SmoothDeinterlacer with the doublerate=true option.

Xesdeeni

[EBITDA]

Originally posted by Xesdeeni
You might also want to look at SmoothDeinterlacer with the doublerate=true option.

Xesdeeni

Thanks Xesdeeni. I think that I tried SmoothDeinterlacer and noticed that diagnal lines had jaggies. However, I might be confusing this filter with another filter.

When I get home, I might do a comparison of TomsMoComp with the 60fps script trbarry posted above, DGBob, and SmoothDeinterlacer with doublerate set to true.

I'll post my comments on the results once I complete the comparisons.

[trbarry]

I'm assuming that all of this should be typed in the avs script BEFORE any cropping, trimming, and/or resizing. Please let me know if this is correct and if not, what advantages there might be in cropping, trimming and/or resizing before applying the TomsMoComp60T(B).avs language.

For the most part you can crop & trim first and make it go a bit faster. Just make sure you crop left margins in a multiple of 2 and top margins in a multiple of 4 for interlaced YV12 (2 for YUY2).

But never resize vertically before deinterlacing. (except maybe using InterlacedResize(), still YUY2 only) Vertical resizing blends info from 2 different fields which with interlace would mean maybe 2 different points of time, bad thing.

And my own feeling is you might get slightly better results if you also don't resize horizontally before deinterlacing, maybe slightly less jaggies. But the effect would be very small and maybe not worth it since horizontal downscaling first would make things go faster. I'll have to test that someday.

- Tom

[EBITDA]

OK, here are the results of my first comparison of four different deinterlacing methods. Three methods create 60fps output and one method creates 30 fps output.

Note: The source used was confirmed to be Top Field First.

The three methods that create 60fps output are:

1) The TMPGEnc + VFAPI method that I describe in the beginning of this thread.
2) The TomsMoComp60 method that uses the TomsMoComp.dll and the script that trbarry posted above.
3) DGBob

The method that was used to create 30fps was TomsMoComp with the "smoothing" effect enabled.

A note about using the TomsMoComp60 method: Apparently you must crop and resize before entering the TomsMoComp60 script. If the resize line was done AFTER the TomsMoComp60 script, VirtualDub said that the source was 720x480 versus 640x480 (resize was set to 640x480). It did not matter what method was used (Bicubic, Lanczos, Bilinear). If crop and resize lines were BEFORE the TomsMoComp60 script, then resize worked. I am not sure why this was the case.

The results on an AMD Athlon 1.4GHz system w/ 512MB DDR.

1) TMPGEnc + VFAPI Method: Motion was perfectly fluid; picture was sharp, and there were no jaggies on diagnal lines and no horizontal line artifacts that result from deinterlacing. Also, no "bobbing" effect on purely horizontal lines due to using the "even-odd, adaptive" filter instead of the "even-odd filter". Color was modified slightly due to color conversions between YUY2 and RGB. SPEED was approx 14fps.

2) TomsMoComp60 Method: Motion was perfectly fluid; picture was sharp though not as sharp as TMPGEnc method. No jaggies on diagnal lines and no horizontal line artifacts that result from deinterlacing. Also, "bobbing" effect on purely horizontal lines was minimal though still there slightly. Color was right-on given no need for color conversion. NOTE: There was one very noticeable problem with the ouput. The picture noticeable shimmered vertically. This was likely a result of the method used to "smooth" the output (because when it was turned off for both the even and odd field, the "vertical shimmering" effect was gone.) SPEED was an impressive 20-23 fps. This method was easily the fastest method.

3) DGBob Method: Motion was perfectly fluid; picture was sharp but did have the horizontal line artifacts. No jaggies on diagnal lines. Bobbing effect was subtle and not too noticeable. Color was accurate due to no need for color conversion. SPEED was approx 13-15fps.

4) TomsMoComp Method for 30fps output: Motion was good but not perfectly fluid. Picture was a perfect balance between being sharp and preventing horizontal line artifacts, minimalizing bobbing artifacts and no jaggies on diagnal lines. Color was right-on given no color conversion. SPEED was FAST at approx 22 fps.

Conclusion: Well, have to say that for my taste TMPGEnc + VFAPI method still gives best overall result. DGBob had no speed advantage over TMPGEnc + VFAPI method and the picture was not as good given horizontal "combing" artifacts that remained. HOWEVER, it is quite clear that given the great speed advantage that TomsMoComp provides and the great picture that it provides in 30fps mode, this method will definately beat the TMPGEnc + VFAPI method once the "vertical shimmering" effect is eliminated when the "smoothing" option is employed. (Perhaps the smoothing needs to be "aligned" better between fields.)

I am not a programmer but am a quick learner. Is there any way I can help with a process to determine how to eliminate (or at least minimalize) the "vertical shimmering" effect when employing the TomsMoComp60 script method? The speed advantage that it provides is too great to ignore.

NOTE: With respect to SmartDeinterlacer, I have noticed in the past that it gives the same results as DGBob. Wasn't DGBob created from SmartDeinterlacer? I could be mistaken. ;)

Cheers! :)

[trbarry]

A note about using the TomsMoComp60 method: Apparently you must crop and resize before entering the TomsMoComp60 script. If the resize line was done AFTER the TomsMoComp60 script, VirtualDub said that the source was 720x480 versus 640x480 (resize was set to 640x480). It did not matter what method was used (Bicubic, Lanczos, Bilinear). If crop and resize lines were BEFORE the TomsMoComp60 script, then resize worked. I am not sure why this was the case.

EBDITA -

Sorry, but TomsMoComp will NOT work well if you vertically resize before deinterlacing. The reason you thought you had to do that is because both of my sample scripts ended with a Return statement, so any commands after them were ignored.

I've edited the sample scripts above to avoid this confusion.

Also, I don't currently remember how I implemented the vertical filter options of TomsMoComp, but it was at a time when there was no TomsMoComp60. So it might (or not) be true that it causes the shimmer or jiggling when trying to make 60 FPS. The original scripts I found on my disk did not have that option turned on. So you might also experiment with turning it off for TomsMoComp60, using TomsMoComp(1,5,0) and TomsMoComp(0,5,0) instead of TomsMoComp(*,5,1) above. (zero the 3rd parm) This might be a needless alarm but I'm worrying about the possibility that the vertical filter might offset the picture different vertically between the odd and even frames. If it turns out that is the case I'll fix it, but can't this week. And you can always get more fast vertical filtering by just ending your avs script with UnFilter(0,-15), or so, adjust to taste.

- Tom

[EBITDA]

Originally posted by trbarry
EBDITA -

Sorry, but TomsMoComp will NOT work well if you vertically resize before deinterlacing. The reason you thought you had to do that is because both of my sample scripts ended with a Return statement, so any commands after them were ignored.

I've edited the sample scripts above to avoid this confusion.

Also, I don't currently remember how I implemented the vertical filter options of TomsMoComp, but it was at a time when there was no TomsMoComp60. So it might (or not) be true that it causes the shimmer or jiggling when trying to make 60 FPS. The original scripts I found on my disk did not have that option turned on. So you might also experiment with turning it off for TomsMoComp60, using TomsMoComp(1,5,0) and TomsMoComp(0,5,0) instead of TomsMoComp(*,5,1) above. (zero the 3rd parm) This might be a needless alarm but I'm worrying about the possibility that the vertical filter might offset the picture different vertically between the odd and even frames. If it turns out that is the case I'll fix it, but can't this week. And you can always get more fast vertical filtering by just ending your avs script with UnFilter(0,-15), or so, adjust to taste.

- Tom

Hi Tom,

I remember you mentioning about vertical resizing before TomsMoComp. The resizing was going from 720x480 to 640x480 (no vertical change). The "vertical shimmering" effect was present both when the resizing command was before TomsMoComp60 and when the resizing command was after TomsMoComp60. With option 3 set to 0 for both bottom and top fields, the filter appears to work perfectly with the only problem being the modest "combing" artifacts that remain (artifacts that the vertical filter effectively removes with TomsMoComp30). I did try a little experiment of setting option 3 to 1 for one field and 0 for the other to see the output. The shimmering was still there for both Top1;Bottom0 and Top0;Bottom1. However, if it will help you determine what the problem is, I'll try to compare Top1;Bottom1, Top1;Bottom0, and Top0;Bottom1 to determine if there is any difference in the vertical shimmering effect between the three and will post the results tonight.

Thanks for the suggestion of using UnFilter. I'll give it a try tonight as well. Just out of curiosity, how does this filter work? Is the vertical filtering as sophisticated as the vertical filtering employed by TomsMoComp? Does it even need to be sophisticated? ;)

Thanks again for your help. :)

P.S. Before I moved to NC, I lived in the suburbs of Detroit near Birmingham. I hope the power outage didn't affect you too badly.

[trbarry]

However, if it will help you determine what the problem is, I'll try to compare Top1;Bottom1, Top1;Bottom0, and Top0;Bottom1 to determine if there is any difference in the vertical shimmering effect between the three and will post the results tonight.

EBITDA - (does that mean the financial term?)

Thanks, but don't bother. I'm pretty sure I know what is happening but just have to find the time to fix it, much harder. The filtering in TomsMoComp is not at all sophisticated. It just averages each 2 adjacent lines, the created weave line and the adjacent bob line. But that process makes the image effectively offset by 1/2 line. I think when doing the even frames it is offset the opposite way from when it is doing the odd frames.

The filtering in UnFilter is only a bit more complicated. It attempts to be an (approximate) inverse of a simple softening or sharpening filter, to remove previous stuff done to the image. There is a description in the readme for it and also a huge block of comments in the source code with the math.

OT: For one more week I'm living just SE of Evergreen & 13 Mile Rd., probably quite close to your old stomping grounds. But next week I'll be moving to Ferndale MI.

- Tom

[EBITDA]

Well, I have tested TomsMoComp60 (set to 1,5,0;1,5,0) with the updated script shown above along with various settings for UnFilter. After using many different settings for UnFilter, I was never able to achieve picture quality as good as I get with TMPGEnc's "even-odd, adaptive" deinterlacing method. As I kept decreasing the negative value toward -100 for the vertical parameter, by the time I eliminated the horizontal "combing" artifacts, the picture was very smooth. I literally had to go to -60 to mostly eliminate the "combing". Oh, well.:rolleyes:

However, I did not end my test there. I then compared the TMPGEnc 60fps video to the 30fps video using TomsMoComp set to (1,5,1) to simply do a picture quality comparison. After about 10 minutes of comparing numerous different scenes, I have concluded that the picture that TomsMoComp provides with the third parameter set to 1 is definately close enough to TMPGEnc to switch to TomsMoComp once the third paramater set to 1 works with 60fps output. In fact, given the speed advantage that TomsMoComp provides over TMPGEnc, DGBob, SmartDeinterlacer, etc...., once the third parameter is corrected for 60fps output, TomsMoComp60 will be one super kick-@$$ solution for deinterlacing to 60fps. Of course, none of this would be possible without the great work of trbarry.:D

Therefore, given the great possibilities that TomsMoComp60 will likely provide (great picture quality, perfect fluidity of motion, AND fast encoding speed), I will humbly and gladly wait for Tom to add the 60fps option to TomsMoComp whenever he has time to do so.:)

For my part, once the 60fps version is complete, I'll gladly create a guide for deinterlacing material to 60fps.

Cheers! :)

P.S. EBITDA is a financial term. It stands for Earnings Before Interest Tax Depreciation and Amortization. I am in Corporate and Investment Banking. Video, music and computers are hobbies for me...and I intend to become an HDTV junky once I can get the dough to plop down on a 42" HDTV Plasma. I am currently looking at either a Panasonic or Sony model. It should look sweet when hooked up to an HTPC with a DVI connection.:D

[EBITDA]

Originally posted by stickboy
Was it TomsBob (http://www.avisynth.org/index.php?page=TomsBob)?

I decided to try TomsBob and am not sure if this is intended to return 60fps progressive material.

Has anyone used TomsBob? Even though I verified that my source is TopFirst, when the settings for TopFirst didn't work, I decided to invert the command lines per the instructions. It made no difference. Also, the fps were actually 30fps NOT 60fps.

Below is my script.

SetWorkingDir("C:\Program Files\Gordian Knot\")
LoadPlugin("mpeg2dec3.dll")
LoadPlugin("UnFilter.dll")
LoadPlugin("TomsMoComp.dll")
LoadPlugin("SimpleResize.dll")

# SOURCE
mpeg2source("D:testfile.d2v")

#
function TomsBob (clip c)
{
c = c.SeparateFields.TomsMoComp(1,-1,0).SimpleResize(c.width,c.height+1)


# add this if your clip starts on a half-frame (e.g. a top-field
# in a BottomFirst? clip)
#c = c.Trim(1,0)


# invert these for TopFirst? source material
top = c.SelectEven
bottom = c.SelectOdd


bottom = bottom.Crop(0,1,0,0)
top = top.Crop(0,0,0,-1)
return interleave(bottom, top)
}

# CROPPING
crop(0,0,720,480)

# RESIZING
LanczosResize(640,480)

Again, if anyone knows how to use TomsBob with TomsMoComp to create progressive 60fps material, I would greatly appreciate it.

Thanks in advance. :)

[EBITDA]

Sorry if my "bump" isn't considered appropriate, but I haven't received any responses in a while and was concerned that my thread was going to be deleted.

Given that more and more TV shows are being released on DVD and TV capture hardware/software is becoming easier to use, I have to believe that there are many people like me out there who are a bit on the "perfectionist" side and would prefer encoding TV shows by deinterlacing to 60fps to keep motion perfectly fluid. I do already have a very effective method that I use, but it is much slower than what would likely be the case with a purely AVISynth filter approach.

Are there any "coders" out there that might be able to look at TRBARRY's source code for TomsMoComp filter (I think that he provides it in the download of the filter) and fix the problem that he mentioned might be in the filter when used to deinterlace at 60fps. He said it might be a while before he can get to it since he is working on other things. I'd offer to look into it myself, but the only programming language I understand is VB (and only slightly so). :(

Given how much slower DivX 5.1 is in slow/slowest mode vs. 5.05 in its slowest mode (standard in 5.1), I'd like to trade-off some of the speed gain from an AviSynth filter approach with the speed drop-off from going to DivX 5.1 slow mode.

Any responses greatly appreciated! :)

[acrespo]

I did a test with TomsMoComp60T.avs and I think the best quality deinterlace method. But my final video is DivX or Xvid and I need a speed down to 23.970 fps to best quality at lower bitrates.
Can anybody help me?

[trbarry]

If you start with a 60i video source then you would probably want to go to 30 fps. But if you started with a telecined film source that would go to 24 fps then you would be better off using Decomb instead of TomsMoComp.

- Tom

[acrespo]

I have captured anime from my TV card, then I have a 30fps video. My atual method is:

AviSource("anime.avi") <- 29.970 fps video
TomsMoComp(1,5,1)
Decimate(5) <- 23.970 fps

I can't see differences on speed (jump frames).

If I use TomsMoComp60T, I need Decimate two times. The first to change from 60 to 30 fps (Decimate(2)) and the second to change from 30 to 23.970 fps (Decimate(5)). But after two decimates, video has visible lost frames.

I see less interlace artifacts after use TomsMoComp60T than using normal TomsMoComp. This is the reason to use TomsMoComp60T. If I can decimate from 60 to 23.970, I will use this method.

[EBITDA]

Originally posted by acrespo
I have captured anime from my TV card, then I have a 30fps video. My atual method is:

AviSource("anime.avi") <- 29.970 fps video
TomsMoComp(1,5,1)
Decimate(5) <- 23.970 fps

I can't see differences on speed (jump frames).

If I use TomsMoComp60T, I need Decimate two times. The first to change from 60 to 30 fps (Decimate(2)) and the second to change from 30 to 23.970 fps (Decimate(5)). But after two decimates, video has visible lost frames.

I see less interlace artifacts after use TomsMoComp60T than using normal TomsMoComp. This is the reason to use TomsMoComp60T. If I can decimate from 60 to 23.970, I will use this method.

acrespo,

When you use TomsMoComp60T, do you have the third parameter of TomsMoComp set to 1? This is the parameter that helps eliminate the last remnants of deinterlacing artifacts. You mention that you see less interlace artifacts when using TomsMoComp60T versus normal TomsMoComp. In all of my tests, I have found that TomsMoComp (normal), with the third parameter set to 1, provides better picture quality that TomsMoComp60T with the third parameter set to 0. (It's my understanding that TomsMoComp needs to be tweeked to allow it to work properly in TomsMoComp60T avs script WITH the third parameter set to 1.) The big problem though is that motion with TomsMoComp won't be as fluid as with TomsMoComp60T. (NOTE: THIS IS ONLY RELEVANT IF TALKING ABOUT PURE INTERLACE VIDEO CONTENT.) This is what I have been encoding a lot of lately and is why I started this thread.

Since you are capturing anime as opposed to pure video (like most of the tv shows I capture), try trbarry's suggestion of using Decomb since anime is film based. However, for any tv show that you like to capture that is recorded in video, TomsMoComp60T is a great solution for perfectly fluid 60fps progressive playback (assuming your cpu is powerful enough). And once the third parameter of TomsMoComp set to 1 works in the TomsMoComp60T avs script, I believe that this will be the ultimate method for deinterlacing 60i VIDEO content to 60p combining speed of encoding, fluid motion and picture quality.

-Cheers

[EBITDA]

Well, it appears that this thread is at the threshold of falling off the board. Since the TomsMoComp60 method with option 3 set to 1 doesn't yet work, and it doesn't appear that it will be fixed in the near-term, I am considering pursuing an alternative that might be as good.

There is a filter called tprivtc.dll that many people use in their avisynth scripts so that they can take advantage of TMPGEnc's very effective IVTC filter. I think I will start a pursuit of getting that filter to work with all of the deinterlacing options that TMPGEnc offers.

More to follow on that project.

If anyone out there is very familiar with how tprivtc.dll works, please resond. Any input is greatly appreciated.

Cheers! :)

[Mug Funky]

here's a bob that works like DGbob but uses tomsmocomp.

it's slow as HELL though. i use it for deinterlacing pure video that i want to look "filmlike" because premiere and after effects just don't have good deinterlacers.

http://www.sharemation.com/mugfunky/funkydeint.avs

there are 2 functions in this filter... funkydeint() and funkybob(). they don't have input options yet, but i prolly should adapt funkybob to be able to change field order (right now i think it's just bottom-first)

the quality is about as good as i know how to make it, and feel free to change bits of code.

[ookzDVD]

@EBITDA,

I just did try your tricks last nite,
and the result is superb, the motion is "real" no ghosting effect,
and the picture is perfect!

[EBITDA]

Originally posted by ookzDVD
@EBITDA,

I just did try your tricks last nite,
and the result is superb, the motion is "real" no ghosting effect,
and the picture is perfect!

Glad to hear that my method works well for you. What version of TMPGEnc do you have? Do you use GordianKnot to encode the "psuedo avi" created by VFAPI to DivX/XVID...etc? Or do you use another program to encode the avi? What is the speed of your system? [CPU, operating system, player software] I'm just wondering because 60fps playback does require lots of CPU time.

Since you like the method, please help spread the word. Now that CPUs are getting stronger and stronger, I'm hoping that 60fps deinterlacing will become the standard method....Especially since all digital/HDTVs accept 480p input......Now all we need is for ATI/NVIDIA to provide standard HD component outputs on their TV-Out/All-In-Wonder video cards. :D

Also, I've been a bit busy right now, but I still do plan on trying to find a way to use tprivtc.dll to deinterlace to 60fps in an avisynth script so that I can hopefully eliminate the color-conversion step.

Cheers! :)

[vhelp]

@ EBITDA.. :)

I too, am a tweaker in Interlaced sources ie, DV home footage. I'm
alsways forever searching the best method w/ mimimum artifacts or
whathave you. But..
.
.
Doesn't your method of 60 fps deinterlace "skyrocket" your bitrate
when you encode since you are encoding to 60 fps now (or did I miss
something here) ??

Yes, please explain.

Cheers :)
-vhelp

[EBITDA]

Originally posted by vhelp
@ EBITDA.. :)

I too, am a tweaker in Interlaced sources ie, DV home footage. I'm
alsways forever searching the best method w/ mimimum artifacts or
whathave you. But..
.
.
Doesn't your method of 60 fps deinterlace "skyrocket" your bitrate
when you encode since you are encoding to 60 fps now (or did I miss
something here) ??

Yes, please explain.

Cheers :)
-vhelp

You are correct to assume that 60fps will require a higher bitrate. Theoretically, I think that it should require double the bitrate per minute of encoded material than if it were deinterlaced to 30fps. However, given the sophistication of the current video CODECs out their (DivX, XVID, WM9, RV9, etc...) and their methods of analyzing the differences between frames and only encoding differences, it might be true that double the bitrate isn't necessary. I would say that you should at least increase the bitrate by 1.75x. One thing nice about GordianKnot is that it includes a Bits/(Pixel*FrameRate) calculator to help ensure that you are keeping the bitrate high enough for the resolution that you have chosen.

The vast majority, if not all, of material that I will likely ever back-up to CD-ROM that will require deinterlacing versus IVTC are TV shows. I usually stick with comedies that, when commercials are edited out, usually run 22-25 minutes. If I record a show that is a 60 minute show, I split it between 2 CDs.

Here's my thought on TV shows. Since CD-Rs are SO VERY cheap right now, I use an ENTIRE CD-ROM for a 30 minute comedy (22-25 minutes minus commercials) recorded at 640x480. This gives me plenty of space to keep the bitrate very high, (usually greater than 4000kbps). Note, 4000kbps for 60fps should be similar quality wise as 2000kbps for 30fps.....and 2000kbps for 30fps at 640x480 should definately be plenty to keep the picture quality quite high. For material longer than 45 minutes, you can either keep it at 640x480 and split the video to multiple CDs OR reduce the resolution slightly....(like 512x384) and keep it on one CD.

Please note that this is how I back-up TV shows. For material as special as home videos, I might actually lean toward spending the bucks for a DVD-Burner and use DVD-Burning software to back-up your videos to DVDs so you can share them with family and friends. I personally don't have a DVD-Burner yet so I can't help you if you decide to go that route.

Let me know if you have any further questions regarding 60fps deinterlacing, but please do remember that 60fps playback does require a good amount of system resources. If you have a barebones and/or older system (ie. PIII, sub 2.0GHz P4, or an AMD Athlon below 1.4GHz) these files might not play without problems. That is why I think that you might want to seriously consider DVD backup of your DV home videos and leave DivX to CD-Rom for TV shows etc...

Hope this was helpful!:)

[vhelp]

@ EBITDA,

cheers :)

I have a much better understanding of your given requirements
as well as setup for your final archive. For yours, this suites you
perfect.
.
.
I was curious from a general perspective (larger audiance) and from
this approach, might not be for everyone, if their goal is
for different form of process/project - - hope you understood that :)

Yeah, the 60 fps is something I've ben experimenting on as well, but
I'm busting a lot of screws along the way. But, I'll forge ahead hehe.

I'm not a GordianKnot user but sounds too complicated for my
project needs. I'm more a straight divX encoder - the long way w/ vdub. But..
.
.
Thanks for clearing that up for all of us, and keep up w/ the ideas and
methods here.

-vhelp

[ookzDVD]

Originally posted by EBITDA
Glad to hear that my method works well for you. What version of TMPGEnc do you have? Do you use GordianKnot to encode the "psuedo avi" created by VFAPI to DivX/XVID...etc? Or do you use another program to encode the avi? What is the speed of your system? [CPU, operating system, player software] I'm just wondering because 60fps playback does require lots of CPU time.

Since you like the method, please help spread the word. Now that CPUs are getting stronger and stronger, I'm hoping that 60fps deinterlacing will become the standard method....Especially since all digital/HDTVs accept 480p input......Now all we need is for ATI/NVIDIA to provide standard HD component outputs on their TV-Out/All-In-Wonder video cards. :D

Also, I've been a bit busy right now, but I still do plan on trying to find a way to use tprivtc.dll to deinterlace to 60fps in an avisynth script so that I can hopefully eliminate the color-conversion step.

Cheers! :)

I'm using TMPGEnc v. 2.521.58.169, Yes, I'm using GKnot to convert
the fake avi into XviD. I'm using Athlon XP +1700, WinXP Pro SP1,
the encoding speed is not bad, I can reach about 20fps encoding
@352x240 resolution.

I'm still using old GeForce MX2/200 with TV-out to my RCA TV.
But the result is very GOOD!
:)

[ookzDVD]

@EDITBA,

I really want to know about the resolution you used for your
DVD backup since the 60fps needs more bitrate.

How many CDs, which codec do you use ?

Please tell me more.

Thank you.

[zambelli]

Wait, hold on a second. Why is everyone resizing to 640x480 at 60 fps? What's the advantage of that? That seems like such a waste of bitrate. Leave the content at 640x240 and set the AR to 1:2. Both ASF and Matroska support pixel aspect ratios.

Am I missing something here?

[EBITDA]

Originally posted by ookzDVD
@EDITBA,

I really want to know about the resolution you used for your
DVD backup since the 60fps needs more bitrate.

How many CDs, which codec do you use ?

Please tell me more.

Thank you.

For DVD backup, the only material that I have backed-up is originally NTSC in 4:3 format so 720x480 gets resized to 640x480. For TV captures with my video card, I capture at 640x480 so there is no need to resize. As far as bitrate goes, I let GordianKnot calculate the bitrate for storage on 1CD (this is for 30 minute comedies). For 60 minute dramas (45 minutes with all of the commercials edited out), I split the show into two, BEFORE I encode it so again, I let GordianKnot calculate the appropriate bitrate for storage on 1CD for each half.

I use DivX 5.1 multi-pass (usually 3 or 4 passes) to encode. I use Huffyuv to capture.


Wait, hold on a second. Why is everyone resizing to 640x480 at 60 fps? What's the advantage of that? That seems like such a waste of bitrate. Leave the content at 640x240 and set the AR to 1:2. Both ASF and Matroska support pixel aspect ratios. :)

Am I missing something here?

Your statement "Leave" the content at 640x240 implies that it is your understanding that I am capturing in 640x240 resolution. I am capturing in 640x480 interlaced resolution. Also, NO DVD (that I know of) provides content in a 240 vertical resolution.

I hope that this clears up what might be a big misunderstanding of how I capture and convert 640x480 30fps interlaced material to 640x480 60fps progressive material. :)

[zambelli]

Your statement "Leave" the content at 640x240 implies that it is your understanding that I am capturing in 640x240 resolution. I am capturing in 640x480 interlaced resolution. Also, NO DVD (that I know of) provides content in a 240 vertical resolution.

No, that's not what I was implying. Interlaced 640x480 video contains two fields in each frame. The vertical resolution of each field, therefore, is half the resolution of each frame. So if each frame has a resolution of 640x480, then each field has a resolution of 640x240, does it not? VirtualDub illustrates this clearly when it converts 640x480 @ 29.97 fps clips to 59.94 fps clips - it also halves the vertical resolution.

So my question is: after you convert 640x480 @ 29.97 to 640x240 @ 59.94 fps, why then resize 640x240 back to 640x480? Isn't that just line doubling? Isn't that a waste of bitrate?

[scharfis_brain]

no, its no was of bitrate!
reducing height to 240 will reduce image sharpness.
both fields have different spatial postions (that's why the video bobs up and down in Vdub, when going to 59.94 fps)

this bobbing is eliminated, by shifting one of both fields by half pixel. or first blowing them up to 480 and then shift by 1 pixel.

but due to the spatial offset, there is much more information in static areas left, when using a clever deinterlacer, that weaves static areas and bobs moving areas.

[lost-coder]

Sorry, I just couldn't let this go ;)


Since you like the method, please help spread the word. Now that CPUs are getting stronger and stronger, I'm hoping that 60fps deinterlacing will become the standard method....Especially since all digital/HDTVs accept 480p input......Now all we need is for ATI/NVIDIA to provide standard HD component outputs on their TV-Out/All-In-Wonder video cards.

You seem to be implying that 480p is 60fps :confused:, as far as I know it's not. It should be 30fps just like 480i since they both fit into the same bandwidth. Remeber all those (H)DTV's have there own frame buffers to decode the signals so it would be easy to display a 480p frame twice.

[trbarry]

You seem to be implying that 480p is 60fps , as far as I know it's not. It should be 30fps just like 480i since they both fit into the same bandwidth. Remeber all those (H)DTV's have there own frame buffers to decode the signals so it would be easy to display a 480p frame twice.

480i @ 60 fps video source has 60 unique fields / second. Properly deinterlacing them can yield 60 unique frames / second, though at not quite the same detail as if it was originally from 480p cameras.

In DScaler, both my Greedy/HM and TomsMoComp filters deinterlaced to 480p @ 60. But when I made Avisynth versions I just supported half that because that seemed to be what everybody was using here. Obviously that was a mistake because machines are getting faster, storage is getting larger, and 60 fps looks much smoother than 30.

I still do intend to correct that for TomsMoComp but it's taking me awhile to get back to it.

- Tom

[lost-coder]

I was thinking about this some time after I posted. How was fps being used? Was it frames or fields per second? When I posted I used frames per second since thats how I usaully use it. The NTSC derived 480i and 480p are 30 frames per second with each 480i frame consisting of two fields.

The issue I had was that EBITDA seemed to be saying the (H)DTVs 480p input was 60 frames per second. The only way to get that would be to use the monitor input turning the TV into a computer monitor.

Now, if this is to be viewed on a monitor or a nice large TV through a computer input, fine. It's the implication that any 480p TV can handle a 60 frame/s input that bothered me. Only the computer input can handle more than 30 frames/s.

Ah well, maybe I'm just reading to much into it.

[EBITDA]

Originally posted by lost-coder
I was thinking about this some time after I posted. How was fps being used? Was it frames or fields per second? When I posted I used frames per second since thats how I usaully use it. The NTSC derived 480i and 480p are 30 frames per second with each 480i frame consisting of two fields.

The issue I had was that EBITDA seemed to be saying the (H)DTVs 480p input was 60 frames per second. The only way to get that would be to use the monitor input turning the TV into a computer monitor.

Now, if this is to be viewed on a monitor or a nice large TV through a computer input, fine. It's the implication that any 480p TV can handle a 60 frame/s input that bothered me. Only the computer input can handle more than 30 frames/s.

Ah well, maybe I'm just reading to much into it.

My comment wasn't specific to what the frame rate might be for a 480p signal sent from a computer card such as the ATI All-in-Wonder via component cables. Frankly, I intend to connect my computer to a plasma via either VGA or DVI once I get a HDTV plasma TV.

From all of the extensive reading that I've done at avsforum.com regarding HDTV and HTPCs (Home Theater PCs), 480p WOULD be 60fps since the refresh rate of the video signal is 60Hz AND my files are 60fps at a full resolution of 640x480.

The question that I have is since the standard refresh rate for a 480p signal sent via component cables (or HDTV-DVI for that matter) is 60Hz AND my computer is playing a progressive 60fps video clip (whether 640x480 or resized to full screeen) why WOULDN'T the fps shown on the HDTV be 60fps? (Assuming that the TV doesn't upconvert the 480p signal to 1080i for display.) Also, if all HDTVs can handle the bandwidth to display a 1080i 30fps signal (which takes up the same bandwidth as a 540p 60fps signal) why wouldn't it be able to show 480p 60fps?

(I could be mistaken above, but my claim seems logical to me.)
Check out AVSFORUM.COM if you have questions regarding HDTV and how to connect PCs to HDTVs via various inputs. I learned a lot at that site. It's great!
Cheers! :)

[lost-coder]

Originally posted by EBITDA
My comment wasn't specific to what the frame rate might be for a 480p signal sent from a computer card such as the ATI All-in-Wonder via component cables. Frankly, I intend to connect my computer to a plasma via either VGA or DVI once I get a HDTV plasma TV.


As I said, in that case it would be 60fps.


The question that I have is since the standard refresh rate for a 480p signal sent via component cables (or HDTV-DVI for that matter) is 60Hz AND my computer is playing a progressive 60fps video clip (whether 640x480 or resized to full screeen) why WOULDN'T the fps shown on the HDTV be 60fps?


Your'e probably right. I keep thinking that 480p is limited to the same bitrate as 480i on those other inputs, which would mean that it's limited to 30fps with the TV doubling the frames as it does for OTA signals.

Oh well, this little side issue doesn't require any further input from us. At least not here ;) .

[trbarry]

Your'e probably right. I keep thinking that 480p is limited to the same bitrate as 480i on those other inputs, which would mean that it's limited to 30fps with the TV doubling the frames as it does for OTA signals.

My Toshiba HD-RPTV can accept either 480i, 480p, or 1080i inputs. The 480p has a horizontal scan rate of twice the 480i. The 1080i rate is a bit higher yet (IIRC 15.75, 31.5, 33.75 Khz)

Usually I display the desktop (and DVD's) at 960x540p which my TV cannon distuinguish from 1080i. I use DScaler to watch my Tivo and always deinterlace everything to 60p.

- Tom