Please tell me I'm not crazy!

[madoka]

Recently I've ran across several DVDs which Decomb handles quite poorly. Most of them are pure NTSC (according to DVD2AVI), so just using FieldDeinterlace should suffice. However, this tends to produce aliased and / or shimmering edges, especially in the ghosted frames. Then I found using Telecide, but not Decimate (which I shouldn't on NTSC material) produces better result, mostly because it removes the ghosted frames (where the glitch occurs most frequently). But now I get choppy frame rate AND still the occasional glitch.

Then, by chance, I decided to try the "field bob" VirtualDub filter (for speed reasons I generally avoid VDub filters), and the result was pretty good! Some edges still shimmer but it's less noticeable, and none were aliased. But how can this be, with Decomb being more sophisticated in its methods?

So then I use AviSynth's built-in Bob filter, and the result was even worse. But doesn't Bob do exactly the same thing as "field bob"? If not, can someone explain to me why they are named similarly?

Am I seeing (or not seeing) things?

[ArdenDag]

Ok, first of all, when you previewed the movie (in different areas) in DVD2AVI, did the film show at 100% Film (Just FILM listed, or FILM 95+ %)?

If it did, then you can simply FORCE FILM the movie, otherwise, you need to make sure FORCE FILM is NOT selected, and then later deinterlace or IVTC the film.

The different procedures you need to run through depends on whether the film is truly fully interlaced or if it is just telecined. Normally films are just telecined.

Try this in your .avs script, see if it helps improve the quality.

Telecide(Guide=1,post=false)
Decimate(Mode=2,Quality=3,Cycle=5)

This, obviously, needs to be used when the film was NOT force filmed when the .d2v project was made in DVD2AVI.

Hope this helps.

[hakko504]

Bob is a generic name for filters that a) double the framerate b) interpolates the video from fields to frames c) shifts video up/down so resulting video doesn't jump.

The internal Bob of AviSynth, is more or less shorthand for clip.separatefields.BicubicResize(clip.width,width.height) and doesn't work very well as you noted.

(I assume) fieldBob is a form of smartbob routine, that checks the interpolated value against the value that this pixel had in the field that was just removed, much like any smart deinterlacer. In fact, most smartbob's are just minor modifications of deinterlacers. This is mostly accentuated by Xesdeeni's smoothdeinterlacer, that actually has a doublerate parameter that decides if it should deinterlace or bob the video. The trick is really to switch top/bottom-first between every frame, after doubling the framerate.

Example using TomsMoCompfunction TMCBOB(clip clip, int "searcheffort")
{
newclip=clip.separatefields.doubleweave()
top=newclip.selectEven.TomsMoComp(1,searcheffort,0)
bottom=newclip.selectOdd.TomsMoComp(0,searcheffort,0)
return Interleave(top,bottom)
}

[Richard Berg]

A real "TomsBob" has to be a bit trickier in order to avoid half-pel bobbing. For example, look here (http://www.avisynth.org/index.php?page=TomsBob) -- some blurring results from the extra resize, but it's pretty unavoidable in this type of method.

Back to your question: I'm not at all familiar with DVD2AVI, but perhaps it's trying to tell you that the source is truly interlaced (not just telecined)? In that case a deinterlacer like TomsMoComp is exactly what you need.

[soujir0u]

Even at 99% FILM (as reported by DVD2AVI), I still get combed frames with FORCE FILM turned on. I find leaving Field Operation OFF, and then using telecide and decimate by decomb gives better results...

I've noticed that Telecide(post=true) and fielddeinterlace gives shimmering effects sometimes, especially with text, but the picture is much sharper than other deinterlace methods.

Btw, do software DVD players like WinDVD and PowerDVD use Bob to deinterlace? The results are pretty good... Wonder which Avisynth filters can achive the same effect.

[hakko504]

Actually I've used this script a couple of times with surprisingly good results, but then I always add some form of resizing down to half size (usually 352x288 PAL). It requires a lot of bitrate though, so using it without b-frames enabled in XviD/DivX is not recommended.

And I must say that I agree with madoke, when it comes to interlaced NTSC/PAL, decomb is not a very good solution. Depending on what you aim for, other deinterlacing methods like TomsMoComp, Greedy or Smooth will give a much better result. I've done a couple of comparisons lately, and in general, Smooth will give best quality, but requires a high bitrate. TomsMoComp is the most compressable and still has a quite good picture quality. Greedy ends up somewhere in between, better picture than TMC, but not as good as Smooth, and it requires less bitrate than Smooth, but higher than TMC.

[madoka]

Originally posted by ArdenDag
Ok, first of all, when you previewed the movie (in different areas) in DVD2AVI, did the film show at 100% Film (Just FILM listed, or FILM 95+ %)?

As I stated previously, DVD2AVI reports the sources to be pure NTSC.
Originally posted by hakko504
Bob is a generic name for filters that a) double the framerate b) interpolates the video from fields to frames c) shifts video up/down so resulting video doesn't jump.

This is what I thought how Bob works, which was why I'm puzzled at why it works better than Decomb.
Originally posted by soujir0u
Btw, do software DVD players like WinDVD and PowerDVD use Bob to deinterlace? The results are pretty good... Wonder which Avisynth filters can achive the same effect.
AFAIK they do, unless your video card supports hardware deinterlacing. Then they delegate the job to the video card.
Originally posted by hakko504
And I must say that I agree with madoka, when it comes to interlaced NTSC/PAL, decomb is not a very good solution. Depending on what you aim for, other deinterlacing methods like TomsMoComp, Greedy or Smooth will give a much better result.
Thank you, so I'm not seeing things after all! (Or we are both insane -_-) But then again my question is why? Of course I don't expect Decomb to handle all cases perfectly, but then I also assume it can't do worse than the simpler methods.

Also, which filter are you referring to as "Smooth"?

----

I've been thinking about a different strategy: deinterlacing or IVTC is simply throwing processor cycles in trying to reconstruct a better image from a crippled source. So theoretically the more processor cycles (and of course correspondingly more sophisticated algorithms) I can throw at the problem, the better result I can get. So perhaps I should simply encode the fields directly (using SeparateFields) now, and as computers gets faster, I can get better and better reconstructions.

[hakko504]

Originally posted by madoka
Also, which filter are you referring to as "Smooth"?
----
So, perhaps if Decomb isn't the solution, I should use something else. But are there any that's native to AviSynth (i.e. doesn't require to work under RGB color space)?
Both Xesdeeni's Smoothdeinterlacer, GreedyHMA and TomsMoComp works in YUY2 and are plugins to AviSynth2.0x. TMC also exists for AviSynth2.5a.

[Guest]

Decomb does not do bob deinterlacing so it is silly to ask why it cannot produce results like VirtualDub's field bob, or others. When you bob, you split fields and double the frame rate, so all combing must of necessity disappear. The downside is the increased frame rate and the artifacts resulting from bobbing.

Note that Decomb is intended for recovering progressive frames, and FieldDeinterlace is intended to handle the frames that cannot be recovered. If you have pure interlaced source, you are better off with a bob solution or TomsMoComp.

[hakko504]

Originally posted by neuron2
Decomb does not do bob deinterlacing so it is silly to ask why it cannot produce results like VirtualDub's field bob, or others. When you bob, you split fields and double the frame rate, so all combing must of necessity disappear. The downside is the increased frame rate and the artifacts resulting from bobbing. ...and for field-matching/IVTC Decomb is by far the best solution available, IMHO. But: by making fielddeinterlace public people assume that it must be a good deinterlacer for general deinterlacing, which unfortunately it isn't. For bob-deinterlacing in AviSynth I think Smoothdeinterlacer is the only solution at the moment. Tom said something about adding this feature to TomsMoComp, but I think he got sidetracked with YV12 before he could add it.

[madoka]

Originally posted by hakko504
Both Xesdeeni's Smoothdeinterlacer, GreedyHMA and TomsMoComp works in YUY2 and are plugins to AviSynth2.0x. TMC also exists for AviSynth2.5a.
Yes, thank you. I figured it out later myself and deleted the question from my post accordingly, without noticing that you've already replied. :)

However, all is not well. I have just tried out TomsMoComp and SmoothDeinterlacer, and neither produced the result I got with VirtualDub's "field bob" filter.

TomsMoComp: I got results that are slightly better than AviSynth's built-in Bob filter, which means they're not that great. I played with the parameters, but the outcome didn't change much.

SmoothDeinterlacer: I have a feeling that the underlying logic it employs is very similar to Decomb's FieldDeinterlace, for I got close to exactly the same artifacts described before: aliased and / or shimmering edges. By adjusting the parameters I was able to control the artifacts but only to have other problems (combed fields getting through, etc.).
Originally posted by neuron2
Decomb does not do bob deinterlacing so it is silly to ask why it cannot produce results like VirtualDub's field bob, or others. When you bob, you split fields and double the frame rate, so all combing must of necessity disappear. The downside is the increased frame rate and the artifacts resulting from bobbing.

Note that Decomb is intended for recovering progressive frames, and FieldDeinterlace is intended to handle the frames that cannot be recovered. If you have pure interlaced source, you are better off with a bob solution or TomsMoComp.
I see, so I was uninformed and have been using the wrong tool. However, VDub's "field bob" seems to do more than just bob deinterlacing, for as stated previously, it doesn't produce the same output as AviSynth's Bob.

Perhaps I should head over to the VirtualDub forum and ask how does "field bob" works. Or better, if someone knows of an exact port for AviSynth.

[Guest]

Originally posted by madoka
I see, so I was uninformed and have been using the wrong tool. However, VDub's "field bob" seems to do more than just bob deinterlacing, for as stated previously, it doesn't produce the same output as AviSynth's Bob.

Perhaps I should head over to the VirtualDub forum and ask how does "field bob" works. Or better, if someone knows of an exact port for AviSynth. There's no mystery about how it works. The code for nudging the fields up and down does some implicit smoothing.

It would be easy to make an external filter out of it and then import it into Avisynth.

[trbarry]

For bob-deinterlacing in AviSynth I think Smoothdeinterlacer is the only solution at the moment. Tom said something about adding this feature to TomsMoComp, but I think he got sidetracked with YV12 before he could add it.

hakko504 -

I did sort of get side tracked but the code is about half done. I'm adding it as I add the SE=-1 vertical frame doubling support to TomsMoComp for YV12. But when finished it should all also work for YUY2 at 60 fps. This will be full TomsMoComp support, not just for bob'ing at SE=0.

Given what else I'm working on it will probably still be another week or 2. But I haven't forgotten.

- Tom

[hakko504]

@trbarry

Take your time. It's better to get something that works good than having to report bugs and try new versions every two days to see if the bugs have been corrected. It's not like it's the most sought-after feature either, but there are some like me and madoka that would like a go at it.

[madoka]

Originally posted by neuron2
There's no mystery about how it works. The code for nudging the fields up and down does some implicit smoothing.
Well, everything's a mystery to me until someone explains it to me :)

It would be easy to make an external filter out of it and then import it into Avisynth.
Yes, but this would incur a colorspace conversion that I want to avoid for speed reasons.

[madoka]

After playing around a bit more, I seems that using TomsMoComp directly without doing SeparateFields, SelectEven, etc. gives me the best results. Thanks for enlightening me about its existence.

[trbarry]

I guess I'll repeat a warning here I've hinted at before. Due possibly to a bug I can't find the number of artifacts seems to increase in TomsMoComp with SearchEffort > 5.

So while that makes the motion search work a bit better I recommend SE=5 for all Avisynth users. The next step up is 9 where it burns more CPU, makes a few stray dots, and doesn't really accomplish much more. So more is not necessarily better.

Though I still run with SE=11 in DScaler. Not sure why.

- Tom

[hakko504]

@neuron2
I just remembered one more thing:
Originally posted by hakko504
By making fielddeinterlace public people assume that it must be a good deinterlacer for general deinterlacing, which unfortunately it isn't. This is supported heavily by Gordian Knot, as fielddeinterlace is the only true deinterlacer available as an alternative in the deinterlacing menu! Which means that TheWEF made two bad choises out of three possible when it came to deinterlacing.:devil: Greedy and Smart is available, but only if you modify the .avs! And IMHO fast deinterlacing should have been Separatefields.selectEven as it produces less artifacts, and is truly a fast choise.

[Guest]

Originally posted by hakko504
This is supported heavily by Gordian Knot, as fielddeinterlace is the only true deinterlacer available as an alternative in the deinterlacing menu! Which means that TheWEF made two bad choises out of three possible when it came to deinterlacing I can't keep quiet anymore, because you never miss a chance to bash FieldDeinterlace().

Tell us all what you think is so bad about it, preferably supported by real examples.

[hakko504]

Originally posted by neuron2
Note that Decomb is intended for recovering progressive frames, and FieldDeinterlace is intended to handle the frames that cannot be recovered. If you have pure interlaced source, you are better off with a bob solution or TomsMoComp. I think you said it yourself too Don.

But let me just state one thing: I do not think field deinterlace is a necessarily bad deinterlacer. I just think that in a lot of cases there are better deinterlacers available, but that they are not used because the only choise GKnot gives you in the menus is fielddeinterlace! My primary goal is to make people aware that there are other alternatives and that they should try these to see what fits their needs the best.

And if you want tests, then I'll give it to you.

I made a few tests a couple of days ago on a PAL anime, and the final size of the files were quite definite:
field 267350016
Greedy 249667584
Smooth 274003968
telecide 241498112 (but this produced a very jerky video, and not enjoyable at all)
telecide 244205568 (this time with blend=true, slightly less jerky)
TomsMoComp 239357952

Script used was this mpeg2source("H:\2x1\2x1.d2v")
#
# DEINTERLACE
# one of these was enabled in every test
#
#Telecide(blend=false)
#FieldDeinterlace(blend=false)
#GreedyHMA(1,0,0,0,0,0,0,0)
#SmoothDeinterlace()
#TomsMoComp(1,15,1)
#
# CROPPING
#
crop(24,8,680,552)
#
# RESIZING
#
BicubicResize(512,384,0,0.5)Avisynth2.06, Decomb4.02, Don't remember versions of the other deinterlacers.

In my eyes Smoothdeinterlacer produced the best picture quality followed by telecide,Greedy,Telecide(blend=true),TomsMoComp and last field.

Every time I have made similar tests, usually Compression tests in GKnot, I have come to approximately the same result. (except I wouldn't use telecide on a normal interlaced source)

Give me a few minutes (maybe an hour) to reboot my computer and I'll post some pictures illustrating my views.

[Guest]

There's a difference between saying that TMC might be preferable for given cases and saying FD is bad, so avoid it, which you did in another thread.

TMC is more compressible because it globally smoothes the frame. If your primary goal is compressibility and you welcome the blurring, then OK, TMC is more suited. But if you want to leave as much of the image untouched as possible, then TMC is not the best choice.

Yes, I agree that users should have access to and experiment with all available solutions. But for you to go around telling people to avoid FD just because your number one priority is compressibility is silly.

There is an existing thread that clearly shows the smoothing done by TMC. Furthermore, Tom has acknowledged a bug that causes it to corrupt the image with some settings. Why do you never mention that?

[Guest]

Originally posted by hakko504
By making fielddeinterlace public people assume that it must be a good deinterlacer for general deinterlacing, which unfortunately it isn't. And in what way is it not good in a general sense?

Later you say:

Originally posted by hakko504
I do not think field deinterlace is a necessarily bad deinterlacer.. Is there a small domain between 'not good' and 'bad'? C'mon, Hakko, tell us what you're really thinking.

[MrBunny]

Back to the original issue for a bit...
DVD2AVI isn't always correct when it lists the frame type of the movie. While it is correct most of the time, there are times that they think FILM material is pure NTSC. The fact that telecide alone seems to prevent some of the artifacting and other ugliness might be an indication of such. I would try having a look at the telecide only encode you've done and see if there's any pattern of dupe frames that might indicate it's actually progressive and not NTSC. You could also check the deinterlaced encode for a 3:2 non-ghosted vs ghosted frame pattern (though it is sometimes quite hard to notice).

Just a thought,

Mr. B

[Guest]

Yes, MrBunny, good point. It is not unheard of for a DVD to be made by taking 3:2 pulled down material and MPEG encoding it as interlaced frame pictures. DVD2AVI reports it as 100% NTSC because there are no RFFs, but if you use non-Force Film to decode it, you can IVTC it perfectly well (e.g., with Decomb, Greedy, IVTC22, IVTC4, TMPGENC, etc.).

[hakko504]

@neuron

general deinterlacing means that in most cases you can find something better than fielddeinterlace.

And yes, in my vocabulary there is quite a gap between 'not good' and 'bad', usually because the former only imples the existence of something better, but the later is speaking for itself. There may be a problem here since I'm not natively english speaking and I willingly admit that I haven't always grasped the full nuances of the language.

I have not recommended TomsMoComp because of picture quality and you can easily find posts where I state that my tests with TMC not were satisfactory.

To the point: I have here added 4 pictures from a movie I had done some other deinterlacing tests on. Unfortunately this was an erotic movie and the here attached pictures were the only ones I could find that were NOT x-rated. It is also a frame with very little motion in it so it's not really a good measurement of how the deinterlacers handle that. Still in my eyes I think the order of quality is Smooth, field, Greedy, TomsMoComp. (Partly judged by how it looks when it is played back on the monitor). But really, this is my point: In most cases Smooth gives the best quality, so if bitrate isn't a problem then use that. And if you are aiming for compression then TomsMoComp will give you that, if you like the smoothing it produces. field ends up somewhere in the middle where Greedy also is.

If you can wait until tomorrow night I can post frames from the anime that I referenced earlier along with other high motion tests.

And lastly, I think I owe you an apology. You have forced me to review all my data on deinterlacers, and I must say that fielddeinterlace did better than I thought on most sources. Still, most of the times it was runner-up, but to different winners. And as usual I (as well as many others) tend to forget the runner-up. I promise I will much more clearly state why I recommend something and why I don't recommend something else.

[hakko504]

And the AVI's from this DVD ended up with these sizes:
field 1271164
TMC 1172184
Smooth 1244632
Greedy 1159894

[hakko504]

@neuron2

You're right, I have on some occasions recommended TomsMoComp without reservations, and this is clearly a mistake from my side. In many of these cases fielddeinterlace should have been considered as an alternative, and in YV12 it should have been the first hand suggestion. My sincere apologies for this.
:stupid:

I hope I haven't scared you away from writing new filters or improving old ones. You are a very good coder and have done marvellous things for the AviSynth community. Especially the IVTC part of Decomb, I haven't failed an IVTC yet with that. I admit I have been hard on fielddeinterlace, too hard sometimes, and some of it haven't always been justified. Still deinterlacing is not trivial, and the different methods for doing this will appeal to people in different ways.

I will try to make a homepage where I can make a longer statement on what deinterlacing methods are available, what the pros and cons are of the different methods as well as a general conclusion based on my preferences. Don't expect it on this side of christmas though.

Oh, and the sizes in the previous post were in kbytes, not bytes in case anyone wondered.

[trbarry]

Hakko -

I've been avoiding asking because I really don't want to get back to working on TomsMoComp yet. ;)

But what is it that you like about Greedy or the others that TMC should be doing? I really don't want to port GreedyHMA to YV12 because it uses a temp data structure that's not really suited to Avisynth. But that means I do want to subsume all it's features in my other filters.

- Tom

[hakko504]

@trbarry

Good question. First of all, like neuron2 pointed out, it smooths the picture very much, especially parts that shouldn't be deinterlaced, to the point that you're loosing detail. Greedy does retain more detail producing a better picture. It seems that Smoothdeinterlacer as well as fielddeinterlace tries to only deinterlace the parts of the picture that are noted as jagged, and without checking the code I'd say that Smooth is using some form of bicubic interpolation where field uses linear. Smooth also seems to delay the picture one frame. Not sure why, but it could very well be that it compares the picture both to current and next frame before interpolating.

[Guest]

I'm going to post this before I read the few posts above. :) Then I'll come back. Here is a clear case where FD clobbers TMC. I've made the point before: FD works on a single frame and so can avoid artifacts due to inter-frame comparisons. The frame attached is deinterlaced with TMC. The one in the following post is with FD.

Another point I want to make is that you forget that FD has some interesting features that no other deinterlacer has, e.g., ability to not touch uncombed frames, manual overrides, etc.

[Guest]

Here is FD. Notice that the moving text is rendered properly and the white dots are not mutilated. I used a fairly high theshold and could have done better in some areas of the picture with a lower threshold, but that would start affecting non-combed areas more. At least with FD, the user can make these choices.

[Guest]

@hakko

All I ask is that you not go around posting stuff like "FD is not good, avoid it". Present your evidence and then let people draw their own conclusions.

It takes a lot more than that to scare me. ;)

[madoka]

Another question before all the knowledgeable people leaves this thread :)

I noticed that VirtualDub's "field bob" doesn't double the frame rate, nor increase the length of the source material. This is completely different from what I (thought I) know about Bob.

The answer's probably trivial, but as I said before many things are still a mystery to me, and they remain so until someone explains them to me. -_-

[hakko504]

@madoka
Yup, the answer is trivial: VirtualDub filters cannot modify video length in any way. They MUST obey a 1 input => 1 output frame relation.
There are ways of changing number of frames, but they seem to process video ahead of any filtering

@neuron
That was a very good example of when not to use TMC. Have you tried Smooth deinterlacer or Greedy on that material? And am I right in thinking that it originally comes from a swedish source, namely 'Sondagsoppet' in SVT1? I think I actually saw that program when Lene Marlin was guest there.

[Richard Berg]

VDub's "field bob" is really an "anti-bob". That is, it's designed to remove the half-pel up & down movements (aka "bobbing") caused by what we're referring to here as bob-deinterlacers.

[trbarry]

Here is a clear case where FD clobbers TMC. I've made the point before: FD works on a single frame and so can avoid artifacts due to inter-frame comparisons. The frame attached is deinterlaced with TMC.

Hi Donald -

Any way I could get about 10 frames of that clip?
(input, not output)

- Tom

Edit: and what SearchEffort value was used?

[Guest]

Originally posted by trbarry
Anyway I could get about 10 frames of that clip?
(input, not output) and what SearchEffort value was used? Sure, Tom. You can get it here:

http://shelob.mordor.net/dgraft/misc/clip.zip

I used TomsMoComp(0,5,0).

This is one of my standard torture clips for testing. It really challenges inter-frame deinterlacers. :devil:

There is a thread in the Gordian Knot forum where I defended TMC. Please don't get the idea I am bashing it. Here, I was just defending FD. :D

[trbarry]

The link seems to be dead.

- Tom

[Guest]

Originally posted by hakko504
Have you tried Smooth deinterlacer or Greedy on that material? And am I right in thinking that it originally comes from a swedish source, namely 'Sondagsoppet' in SVT1?Haven't tried it with those filters, no. But I posted the clip if you'd like to experiment.

Yes, you are right about the source of the clip. I originally got it from Gunnar Thalin, who invented the intra-frame method that FD uses.

[Guest]

Try again, Tom. I forgot Linux cares about upper and lower case. :)

[madoka]

Originally posted by hakko504
@madoka
Yup, the answer is trivial: VirtualDub filters cannot modify video length in any way. They MUST obey a 1 input => 1 output frame relation.
There are ways of changing number of frames, but they seem to process video ahead of any filtering

If this is the case, then how does VirtualDub reduce the frame rate? If it drops frames, then the deinterlacing phase is completely wasted. If it blends frames, then it would be just like a regular deinterlacer.
Originally posted by Richard Berg
VDub's "field bob" is really an "anti-bob". That is, it's designed to remove the half-pel up & down movements (aka "bobbing") caused by what we're referring to here as bob-deinterlacers.

I see. Two more questions though. First, why would it be necessary since most Bob deinterlacers do this automatically. Second, oblivious to this fact I ran the filter through interlaced source, and the output appears to be de-interlaced. So if "field bob" does nothing but nudge pixels up or down, how does this happen?

[Guest]

Originally posted by madoka
If this is the case, then how does VirtualDub reduce the frame rate? If it drops frames, then the deinterlacing phase is completely wasted. If it blends frames, then it would be just like a regular deinterlacer.VirtualDub *filters* cannot change the actual number of frames passing through the filter chain. You can set decimation, and you can change the frame rate set in the AVI file, through the Video/Frame rate menu. But we are talking about a filter.

To use the field bob filter properly, you are expected to separate the frames into fields first. You can do it using Avisynth's SeparateFields() filter for any clip, or you can use the VirtualDub extended open options *if* you have an MJPEG clip encoded as fields. Then you would set one field to be shifted up and the other field to be shifted down. Finally, you would resize to full height.
I see. Two more questions though. First, why would it be necessary since most Bob deinterlacers do this automatically. Second, oblivious to this fact I ran the filter through interlaced source, and the output appears to be de-interlaced. So if "field bob" does nothing but nudge pixels up or down, how does this happen? It's necessary for the same reason it is necessary for the other filters. :) Some people use VirtualDub exclusively for this. How would they do the nudging without this capability in the filter?

Did you select the Smooth radio buttons? If so you just blurred away the combing.

[onesoul]

A question about smooth deinterlace: it output video with the double fram rate can only be viewed with computer? or can it be played at a dvd player?
Sorry, I am just a n00b

[Guest]

Originally posted by onesoul
A question about smooth deinterlace: its output video with the double frame rate can only be viewed with computer? or can it be played at a dvd player? The DVD player feeds to a TV, which can display only single frame rate video. There are double rate TVs and players, but I doubt that you have them. :)

[natami]

hakko said up there that "Smooth will give best quality, but requires a high bitrate. TomsMoComp is the most compressable and still has a quite good picture quality. Greedy ends up somewhere in between, better picture than TMC, but not as good as Smooth, and it requires less bitrate than Smooth, but higher than TMC"

i was wondering what constitutes a 'high' bitrate for this scenario...my current project is using a b/r of ~1530, is that high enough?

(avs->2pass sbc)

[hakko504]

Originally posted by natami
i was wondering what constitutes a 'high' bitrate for this scenario...my current project is using a b/r of ~1530, is that high enough? Run a compression test. If you hit 60-80% then you are in the clear. There is no other way of telling if you have correct bitrate.

[onesoul]

The DVD player feeds to a TV, which can display only single frame rate video. There are double rate TVs and players, but I doubt that you have them. :)


You're right, I don't have them. :)