New IVTC for Avisynth

[Blight]

Nah... now it's time to integrate decimate into telecide so you'd save around "30*Height*Width*16bit/Second" of frame-buffer copies and speed things along further.

[neuron2]

As you know, Decomb 3.6 and before used only blind field matching, and did not consider any prevailing patterns. However, as IVTC4 showed, the field matching can be guided by consideration of the prevailing pattern. Since the author of IVTC4 has chosen not to release his source code, I invented my own implementation of this useful idea.

The idea is that Decomb still uses blind matching unless instructed to use pattern guidance. That means it can still be used for PAL and other pathological telecines. But if your material is known to be NTSC 3:2 pulldown, you can set guide32=true and the prevailing pattern will be used to guide the matching. This means that a predicted match can overrule a calculated match, if the discrepancy is not above a configurable threshold (thresh32). If the discrepancy exceeds the threshold, the pattern is reset.

This feature can make field matching more accurate for some clips. It successfully eliminates the last bad matches that I had in my torture test clip, and should be a useful enhancement for processing NTSC 3:2 pulldown material.

Please get the new version at http://sauron.mordor.net/dgraft/decomb37.zip

[daxab]

I wondered when you were going to come over to the dark side ;)...

[neuron2]

Nice sense of humor, Daxab!

I couldn't get rid of the last few field match failures with blind matching, which I suppose is not surprising. The tweaking came to an end and there were those pesky few frames, laughing at me. Your efforts convinced me that a hybrid approach was valuable, and when I realized that I could add it without abandoning the blind mode for PAL and pathological telecines, well, there was no way to avoid it. I'll still be curious one day to see your implementation, as there are still a few interesting issues. For example, I wait until I see 5 successive frames with a good pattern before I allow overrides. But maybe it is better to try to sync up earlier. I'm conducting experiments on this right now. Another example: how to support random access efficiently.

Congratulations on conceiving this useful idea. Thank you for the inspiration and I'm happy to credit the hybrid approach to you.

[neuron2]

Thought I'd report my results encoding episodes of the anime Lain using the blend methodology suggested by Blight. These episodes have a lot of 30fps content mixed with 24fps content. Here is the script I used:

LoadPlugin "decomb.dll")
LoadPlugin("mpeg2dec.dll")
mpeg2source("Lain.d2v")
Crop(8,0,704,480)
Telecide(chroma=true,dthreshold=13)
Decimate(mode=1,threshold=25)

The result is highly satisfactory! I've watched several episodes at normal speed and never noticed any of the blends.

[Blight]

Does enabling pattern matching slows down decomb? If so, by how much?

[neuron2]

@Blight

The amount of extra processing is insignificant. I doubt whether you could measure it. BTW, I am about to release pattern guidance for PAL.

[Blight]

Actually, in PAL, pattern guidence should work backwards.

It should try pattern guidence first and if it fails switch to blind matching.

The thing with PAL is, that if your video is phase shifted, it's usually phase shifted in the same order till a scene change (or in case of most movies, commercial break), so it's faster to do pattern match.

[neuron2]

I've released Decomb 3.8 to my web site. It adds pattern guidance for PAL. Also note that the syntax for the guide options has changed. Please refer to the help file for details.

As Decomb is now mature, I don't have any plans for new releases unless bugs are found. I plan now to port some VirtualDub filters to Avisynth. I was thinking to start with Hue/Saturation/Intensity. Any other suggestions before I get started?

@Blight

There isn't really any "backwards", because you have to do the full matching on every frame to detect pattern changes. It would be faster to do *only* pattern-predicted recovery, but then you wouldn't be able to detect pattern changes.

[Roginator]

I vote "yes!" on porting hue, saturation and intensity to avisynth.

[Dali Lama]

The Hue/Saturation/Intensity filter is a good idea to port :)

hmm...

I think in order of a lot ot people's importance (including mine):

1. 2D Cleaner Optimized
2. Warp Sharp
3. Smart Smoother Hi Quality
4. Levels

Those are pretty important ones I think, except for levels though, but that is useful in some anime encodes to help 2D Cleaner "clean" the dark areas.

Thanks for your work and I tested the latest version of Decomb with the pattern matching. It works on that anime clip that it didn't do so well before.

Bye,

Dali

[Blight]

There already is a levels filter...

I vote for WarpSharp, a native YUY2 version should speed things up.

[DDogg]

Well in the "for what it is worth" category:

The one thing nearly all users of AviSynth have in common is compression. We have filters like TS that help via adjacent frame random noise reduction, but I wonder if a filter with a fuller holistic approach towards maximizing "compressability" without distortion might pay big dividends to the creator and this community? Perhaps there is nothing more that can done? I only bring this up because, to my knowledge, nobody has ever addressed this subject directly with a concerted effort.

DD

[Blight]

Actually, the codec writers themselves apply pre-filtering, and I'm not talking about the DivX5 stuff.

For Example, try encoding a non-anti-aliased text and encode that, you'll see that it's slightly blurred. All encoders (be it MPEG1/2/4) seem to do some sort of FIR filter to knock-out the high frequency ranges which make it harder to compress video.

It's not really anti-noise, but they all seem to do it to some degree.

[DDogg]

Blight, you know I have never been bashful about saying I am just an advanced tool user and not much on theory like you guys. I am always cheerful to admit I may be full of beans :), but:

For conversation purposes let's take the two extremes of bicubic 0.00,0.75 and something like bilinear with TS 2,1. Of course the latter produces a softened, and many would say distorted, image but the ability to compress is drastically better.

So, my thinking is a filter designed to resize with some type of integral specialized noise reduction targeted toward maximizing compression with the least amount of distortion could, perhaps, do a better job [and faster] than the individual bits and pieces we have now.

Does that make any sense to you guys? If it were possible, it would make a very large impact on both the Mpeg and the Divx community.

Edit: Actually DG was talking about converting existing filters to AviSynth so I guess I am way off topic the off topic with the suggestion of a new filter. If so I apoligize.

[Mentar]

I wanted to strongly second what DDogg wrote. What I'm always looking for is a filter which is created in order to remove noise and mpeg artifacts out of an imperfect source in order to achieve optimal compressability. Especially for encoding of anime this would be the perfect too. Decomb was a massive improvement in this area (my biggest kudos to Donald :D), this would be the biggest entry on my wish list.

I'm aware that I'm dreaming into the blue here - noise reduction, artifact reduction, and please keep the picture from blurring out too much ... sounds like the uber-filter.

Well, one can dream ...

[Blight]

ddogg:
I don't think there's a point.

When you scale, you sub-sample pixels, which blurs. The way bicubic scaling looks better is because it actually sharpens, and sharpen image has higher frequencies which are harder to compress.

The more the image is soft/blurred, the easier it is to compress as there are less high frequencies. But that's less pleasing to the eye.

There's no way you can make a sharp image that compress well.

If you're talking noise reduction, there are plenty of available filters, if you run them prior to scaling, you get a little less blurring than running them after scaling, but that's pretty much it.

[Mentar]

Blight: I see your point, but I respectfully disagree. There are tons of sources who are very sharp and still compress well. Unfortunately, running current smoothing filters over mediocre sources with noise and small artifacts tends to blur the picture much more than it's good for the picture.

So my dream would be to have some kind of "smart" noise/artifact filter which identifies areas with very sharp contrasts (for example lines in anime) and only smooths the contents within the areas encompassed by these lines, while keeping the lines fully intact. Most of these areas are either single-coloured or have a very slow progression, so it should be possible to identify noise and artifacts by having just very few pixels out of "base colour", and those are usually bound to "blink" on the time axis too.

So some kind of hybrid of normal smoother which also checks suspected noise on the time axis would be the dream of all anime fans. Like a blend of SmoothHIQ and Temporal Smoother.

Dreaming again :D

[Blight]

There already is a noise cleaner that is perfect for anime and pretty much does what you describe. There's a link to in on graft's page, don't recall it's exact name.

It's for virtualdub though.

[DDogg]

When you scale, you sub-sample pixels, which blurs. The way bicubic scaling looks better is because it actually sharpens, and sharpen image has higher frequencies which are harder to compress.
Yes, of course. Even I know that :)
The more the image is soft/blurred, the easier it is to compress as there are less high frequencies. But that's less pleasing to the eye.
Again
There's no way you can make a sharp image that compress well. Hmmm...Isn't that out of context? Certainly a sharp image with more of the adjacent frame, random, small radius noise reduced will compress better than without..which leads to:
If you're talking noise reduction, there are plenty of available filters, if you run them prior to scaling, you get a little less blurring than running them after scaling, but that's pretty much it.

So, I think you are saying a couple of things here. Tell me if I got it right. One is you feel there can be no further reduction in adjacent frame random noise over what is available now [that is non-destructive to image quality].

Second, you do not feel an approach combining some type of specialized noise reduction and resizing into one hybrid approach would make much of a difference in compression ability or speed. In other words, are you are saying you don't feel it would be worth the time and effort as the results would not be much, if any, better than what we have now?

Well maybe. Not for me to know as I can't do it, but it just made sense to me that a combination of these elements done together "in process" would be better than done separately.

[Blight]

I think someone could come up with a better noise reduction code, who knows what the future stores. I just don't think that the image scaling will factor into it.

[trbarry]

Someone (not me) should come up with an Avisynth version of Lindsey Dubb's new DScaler Adaptive Noise filter. Or talk him into it.

It's been getting pretty good reviews over on AVS.

- Tom

[DDogg]

I motion we all volunteer Tom to talk with Highspeed, do I hear a second? :)

[High Speed Dubb]

I’ll probably wait on an AVISynth port until summer. Odds are, a conversion of the Gradual Noise filter won’t be too difficult — Adaptive Noise is a different matter.

Hmm... Tom -- do you think a generic “Run this DScaler filter” AVISynth filter would be possible? That might make more sense than porting each one.

Heck if I know how these noise filters will affect compression. Both my noise filters (purposefully) preserve a small amount of noise, which might well increase the compressed size.

I do think there is something to be gained by a joint spatial/temporal noise filter. That should be more efficient (i.e., a better use of the data) than doing both separately.

[Roginator]

If you are brainstorming a filter for animes, how about this idea...

Write a filter that first analyzes the anime. It is allowed to use the colors black, white and "n" other user-specified colors, but no more. How many colors could animators use anyway? (assuming they aren't using blends). You would simply tell the filter to assume up to "n" colors. During the analysis phase it would select the "n" most likely distinct colors.

Let's assume the animators used 12 colors plus black and white. The filter would then examine each pixel and determine which of those 14 was the closest match. You would get perfectly solid colors and lines. If a pixel of noise was surrounded by 8 pixels of another color, it should be easy to assume that pixel should also be the same color as the 8 surrounding ones.

Maybe this is too simplistic.

[High Speed Dubb]

@Roginator

That’s a good idea for any animation which uses only a small number of unshaded colors.

Here’s a formal description of the method

Given a set S of colors (described as a Y, U, V triplet), each s_i in S with frequency F_i, the noise variance, and (incorrectly) assuming independence among pixels, the likelihood of the s_i, F_i is

Probability(Movie data | s_i's, F_i's, noise variance)
=
Product over all pixels of
Sum over states s_i in S of
F_i*Probability(Color at that pixel | s_i, noise variance)

With that equation, you can evaluate the likelihood for each set of parameters{s_i's, F_i's, variance}, choose the s_i, F_i, and noise variance which maximize the likelihood, and at each pixel choose the color which contributes the most to the likelihood.

Problem is, that’s an enormous search space. You could make the math easier by using a 2^16 bucket lookup table of color frequencies, but it’s still a big space. You could probably handle the search with importance sampling, but that isn’t simple stuff.

There’s also the issue of adding and removing members from S. There are ways to deal with that, though.

Maybe there’s some good clustering heuristic for this. But it definitely qualifies as a difficult problem.

If you’re willing to require careful user input, you could have the user manually input the color set. That would make the search much easier.

[Edited to correct the optimization method description]

[DDogg]

I guess Tom works fast. ;)
I do think there is something to be gained by a joint spatial/temporal noise filter. That should be more efficient (i.e., a better use of the data) than doing both separately.
Do you think there could be any benefit adding resizing into the process? I guess I am saying in layman's terms, "Would knowing where you are coming from and where you are going, size wise, be an additional slice of data that could be used to assist the efficiency of the process or the speed of the process of a joint spatial/temporal noise filter?". Gee, that's a mouthful :)

[High Speed Dubb]

Any process which is really sensitive to noise would potentially gain from being run jointly with noise reduction. To me, that means pulldown detection, noise reduction, and probably deinterlacing would optimally be handled together. The advantage here would be that uncertainty in the noise estimate could be used to inform pulldown and deinterlacing decisions.

In other words, the noise reduction could produce the result “I’m almost certain this brightness value is 23” or it could determine “My wild guess of the brightness value is 23.” Those are very different statements, and a clever pulldown or deinterlacing routine could take advantage of that.

So yes, a scaler could benefit in a similar way. Simple scalers like bicubic interpolation don’t change depending on the uncertainty of the data. But you could design a scaler which did. My hunch, though, is that the payoff wouldn’t be that great.

There is a lot to be said for keeping the steps separate, even when a joint approach would be a better use of the data. (When I said “efficient,” I only meant it in the statistical “best use of the data” sense.) Separate steps are much easier to deal with as a programmer, and will tend to give script writers more flexibility.

[Dali Lama]

I'm just a little confused about Tom's statement, "Someone (not me) should come up with an Avisynth version of Lindsey Dubb's new DScaler Adaptive Noise filter."

Where can I download this new filter. I have never heard of it before. Is it a type of spatial filter, or temporal filter, or static noise reduction filter?

Thanks,

Dali

[High Speed Dubb]

It’s a temporal noise reduction filter.

(What do you mean by static noise reduction? — “static” has two possible meanings in this context.)

[High Speed Dubb]

@Dali Lama

I forgot to answer the other half of your question...

It’s a filter for the DScaler real time video processing program. So it won’t run in AVISynth scripts. A version for DScaler 3.1 is at

http://students.washington.edu/ldubb/computer/Noise_filters.zip

[Lord Sandwich]

I've been having trouble getting perfectly decimated output from a 3:2 pulldown source (specifically, Transformers The Movie). The animation jerks and stutters in a number of scenes, but only when the entire movie is processed. When I trim the footage down to the specific scene before using Decomb, things seem to work fine.

So anyway, I was thinking about this scenario:

ABBCD, ABBC; AABCD, AABCD

This is a Telecided NTSC source, and the semicolon marks a scene change as well as a pattern change. As I understand it, Decimate only searches for duplicates within groups of x frames, as specified by the user. But in this case it means that the third group onwards contains no duplicate frames, because Decimate(5) would process it as:

ABBCD, ABBC|A, ABCD|A, ABCD|A ... and so on.

Thus, Decimate is forced to remove non-duplicate frames, and the animation ends up stuttering until the next pattern change.

Perhaps a solution to this would be some sort of "look-ahead" option, where the fifth frame in one group is compared with the first frame in the next group? That way it can reset the groupings if the two frames are a match.

This make any sense at all? I'm fairly new to this theoretical stuff. :D

[Krajensky]

Using that nearest-to-lookup filter on any sort of anime will result in serious aliasing - the black lines aren't perfectly black, especially if a resize has come before this filter in the script.

There is bound to be some sort of blurring/antialiasing applied beforehand...do we really need to get rid of that?

Krajensky

[trbarry]

Hmm... Tom -- do you think a generic “Run this DScaler filter” AVISynth filter would be possible? That might make more sense than porting each one.

That might make a whole lot of sense if there was interest in the other DScaler filters. That is basically what I did for the first version of GreedyHMA, before I added full IVTC into it.

GreedyHMA already contains much of the needed code but DScaler is in the process of changing calling architectures for DScaler R4.0 (to be much more like Avisynth). If this were done it should probably be done with the R4 version in mind but the current version of GreedyHMA out there in the zip still assumes R3.1 calling conventions.

I'm not at all an expert on DScaler filters, I've mostly stuck to deinterlacing. And right now I'm seriously considering trying my hand at some XviD assembly optimization for XviD playback instead, for my HDTV stuff.

Neuron2? You've become pretty much an expert in this area. Any interest? ;)

- Tom

[Nic]

Tom,

I was just going to come looking for you about helping with XviD assembly and I find this.... :)

Cheers,
-Nic

[Divine]

I plan now to port some VirtualDub filters to Avisynth. I was thinking to start with Hue/Saturation/Intensity. Any other suggestions before I get started?


A port of the logo filter would be nice :)

[Divine]

I've tried the filter for some interlaced pal stuff which i have captured from tv/vhs source.
But i cannot seem to get a perfect result out of it.
I have tried Telecide() , which had stuttering left. After that i have tried Telecide(guide=2). That was alot better, but i still noticed some little stuttering.
Ofcourse the stuttering ain't in the original source and i had no frame drops.

Settings:

720x576 @ YUVY uncompressed.

Script:

#LoadPlugin("MPEG2DEC.dll")
Loadplugin("Decomb.dll")
SegmentedAVISource("d:\test\capture.avi")
ConverttoYUY2
Telecide(guide=2)
#TemporalSmoother(2)

Anything i am doing wrong? Or can't decomb handle my stream :)

---
edit:

Well i'm using FieldDeinterlace(blend=false) now, seems to work fine.

[High Speed Dubb]

@Krajensky

Yeah, that’s a very good point. Worse yet, some pixels in an antialiased area might be falsely interpreted as one of the image’s other colors.

[neuron2]

@Divine

Of course, use Telecide() only on progressive (film) material. It is likely that your material is pure interlaced PAL video if Telecide() gives poor results but FieldDeinterlace() works well.

[Brougs78]

Hi!

I've read most of the replies in this topic, but I am not sure how to solve my problem.
I live in 'PAL-Land' :D and I'm a big Seinfeld-Fan so I record mostly every episode. But I've problems to encode it in a proper quality. It seems that the 24fps from the original are telecided up to 30fps and than blended down to 25fps. I tried to use the decomb filter with and without dropping frames. In the first case the filter works very well (according to the high quality of every single frame), but the duplicates result into stutter. The latter with decimate(5) also stutters. It is somehow logical, because I think the only way to handle this kind of movies (to get the 24fps) would be the reconstruction of 30fps and then IVTCing, or am I wrong about this?

So my question now: Do I get the best out of it, if I only use FieldDeinterlace() like you (@ neuron2) suggested Divine? Or is there an other way?

cu,
Brougs78

[daxab]

@Brougs78

That's funny, I'm currently testing with Seinfeld episodes. And I can tell you, they're a mess. I'm in North America so I'm getting 24fps telecines to 30fps. They've done edits after telecining. I wish they wouldn't do that. (I think they produce a film master, telecine it to 30fps on video, and then broadcast that. Later, in syndication, they edit the video to trim out 5 seconds here, 5 seconds there, etc., so they can squeeze in yet another 30 second commercial spot. That's my guess, at least.)

I don't even want to think about working with the 25fps version.

[srwalker]

Brougs78: It sounds like those Seinfeld conversions were done with the same method as the Widescreen Buffy S5 episodes the BBC are broadcasting.
There is no way to undo this. Even if you separate the fields you will find ghosting on moving objects where blending has occurred. Stuttering is another side effect of the conversion.

[Krajensky]

@srwalker:

Could you post about 10 consecutive framegrabs (as jpegs) of this "ghosting" where it is most prominent in the clip (either to a website or to my email account krajensky@myrealbox.com ) I have a scheme that is still in its infant stages that might be able to help, if it still has full frames every once and a while.

Krajensky

[srwalker]

Originally posted by Krajensky
@srwalker:

Could you post about 10 consecutive framegrabs (as jpegs) of this "ghosting" where it is most prominent in the clip (either to a website or to my email account krajensky@myrealbox.com ) I have a scheme that is still in its infant stages that might be able to help, if it still has full frames every once and a while.

Krajensky

I'll upload to some webspace as soon as I can, but I can't connect to the FTP at the moment.

[High Speed Dubb]

It struck me that Roginator’s color reduction idea is algorithmically really similar to the selection of an adaptive palette. The good news is that lots of work has been done on this — The bad news is that it’s NP-Hard. That means an optimal solution in a useful amount of time is right out. A good enough approximate solution might be possible, though.

Here’s an alternative idea for cartoons — Try to identify flat regions. Something similar to Photoshop’s magic wand tool (with a threshold chosen based on the noise level) might do the trick.

[edited for typos]

[srwalker]

ftp is fixed, so here is a sequence of frames saved as jpgs.

http://website.lineone.net/~angelcuts/doom9/

There's a zipfile of all the frames at the top. Total 35 frames, 1.3Mb

Watch Buffy as she crosses the frame. The PAL conversion has been done by blending fields from the NTSC, instead of speeding up a film source or IVTC & Speedup of the NTSC. The artefacts this process produces I think are not removable

Stephen

[kramerdog]

I've been converting TV caps to SVCD for a while now. I've experimented with all the IVTC filters. IVTC4 did a good job, but I came back to decomb after you implemented the guide feature.

I've had excellent results with ...

Telecide(guide=1,gthresh=85)

This seems like an extremly high threshold, but lower values allowed combed frames to sneek through. Closer examination reveiled that the pattern had not changed, but decomb thought that frame was not interlaced, when indeed it was. Setting the gthresh high fixed it. It now looks great.

I know you are always looking for ways to improve decomb, and this isn't really a problem, but I thought you might want to see why the "normal" telecide wasn't working as well.

Its a very nosiy clip and that may be what's throwing it off. Would you like me to send a clip?

Thanks again for all the great software you've developed.

[droolian01]

@srwalker and krajensky

I have noticed this field blending on my '24' caps off bbc2 too. I think it will be impossible to do an 'inverse telecine' of whatever it would be called on this stuff. Seems to me that legitimate telecine/ivtc involve duplicating/discarding fields, the second one is blended then that process is irreversible as data is lost. I had strange ideas of doing a pal to ntsc convertion, then doing an ivtc but if the fields are blended the original progressive film is lost. All you can do is de-comb (or any other equivalent thing), so i agrre with srwalker and think krajensky will only create another de-comb method if he is succesful.

Only just started doing this stuff, and just got sky1 added to my cable package too. I did a cap of buffy 'double meat palace' and although only 4:3 (and has anoying advderts to edit - i love the beeb!) i did notice that there is no field blending, so telecide() should work like a dream when i get around to doing it. Now - does the beeb get the same source as sky, because if it does the beeb will be starting season 6 soon - widescreen and no field blends - could it be true!?

[daxab]

@kramerdog

IVTC4 did a good job, but I came back to decomb after you implemented the guide feature.

I've been working on an new plugin that outperforms IVTC4 on TV caps. Everyone seems pretty happy with what's out there, so I'm taking my time. Also I get the impression that few people do TV caps and many do anime, and I'm not happy with the anime performance yet.

[Divine]

Originally posted by kramerdog
I've been converting TV caps to SVCD for a while now. I've experimented with all the IVTC filters. IVTC4 did a good job, but I came back to decomb after you implemented the guide feature.

I've had excellent results with ...

Telecide(guide=1,gthresh=85)

This seems like an extremly high threshold, but lower values allowed combed frames to sneek through. Closer examination reveiled that the pattern had not changed, but decomb thought that frame was not interlaced, when indeed it was. Setting the gthresh high fixed it. It now looks great.




I have simular problems with decomb and my TV/VHS captures. (they're quite noisy as well)
The IVTC of the video part goes well, but decomb seems to have problems with overlay logo's/text or simular.
I get 'jumpy frames' around some still-TXT or still-LOGOS.
I also have had some sources with moving logos, (they move in a certain range/direction all the time) and they stayed interlaced after ivtc'ing with decomb. (everything else(the video) processed fine, except that logo)

Now you would think these logos have been overlayed after the telecine (23>29) progress, but i don't think thats the case.
Because when i run the source through tmpeg (and then eventually an area based deinterlacer) everything 'seems' fine. There are no jumpy frames or whatsover.

Unfortunately i won't be able to upload any sample.. as i am on a very slow modem connection atm :( (lost my cable connection weeks ago)

[manono]

Hi Divine-

neuron2 is on Sabbatical for awhile, so he won't be able to help. I've never done a vid cap in my life, so I may not be able to help. However, neuron2 added a feature to Decomb recently, designed for your problem. This may help with some, if not all of the problems you describe. Anyway, this is a quote from the Help File included with Decomb:

y0 and y1 (integer, default 0) define an exclusion band for the field matching. If y0 is not equal to y1 this feature is enabled. Rows in the image between lines y0 and y1 (inclusive) are excluded from consideration when the field matching is decided. This feature is typically used to ignore subtitling, which might otherwise throw off the matching. y0 and y1 must both be positive integers and y0 must be less than or equal to y1; if this is violated an exception will be thrown.

And I'm sure there are others that have dealt with this problem first hand and may be able to offer some advice.

[h00z]

I can't thank you enough for making Decomb. I tried it on my own Cowboy Bebop rips and I have to say that it is the nicest rip that I have ever done of the series. Kudos man... I can't wait to see where this ends-up if it's this good already.

[Divine]

Thanks for your reply manono.
I have already played around with these y0 & y1 integers before, but it didn't seem to help in my case :(

[wmansir]

I hate to dig up such an old thread, but I just have one decomb question simple unworthy of it's own thread, and it's on the topic that this thread ended on.

Do the y0 and y1 values start at the top of the frame or the bottom? So is y0=0 (or 1) refer to the top line or the bottom line?

I'm encoding "Ran" and it has hard coded, interlaced subtitles on the bottom 100 lines, as an example could someone give me the y0 and y1 values to exclude this section of the frame?

[neuron2]

Hmmm, maybe that's why it didn't work for Divine. :)

I just checked the code and I don't subtract the values from the frame height. Since I believe y=0 is the bottom line, that would mean it is referred to the bottom. Ooops. I'll double check this on my test files tonight and post again. Meanwhile, can you try an experiment and let me know? Try y0=0,y1=100. If it works, I'll probably just revise the help manual to say it is referred to the bottom. :p

[wmansir]

I haven't tried encoding the movie yet. I noticed the interlaced subs while preparing the source and remembered this feature of decomb, but was unclear how to configure it. However, after some searching I did find a few frames that were incorrectly pulled down because of the interlaced subs and y0=0, y1=100 gave the correct pulldown.

However, just to be sure I tried y0=380,y1=479 and it also gave the correct pulldown on the problem frames I encountered. I checked the results several times, because I don't understand why both settings would work. If anything I would expect the incorrect settings to make a bad pulldown more likely. Here are the instructions I used :

Telecide(post=false)

Telecide(post=false,y0=0,y1=100)

Telecide(post=false,y0=380,y1=479)

All were followed by:
Decimate(cycle=5)

I usually use 3.8, but I also tried these settings with 3.91, with identical results.

[neuron2]

Stranger and stranger! :eek:

Can you make available the part of the source clip that shows this? Thank you.

[wmansir]

You've got PM.

I'm still trying to upload the file to the address provided. I'll send you another PM when it's available.

However, I was surprised at the speed hit from using exclusion, not that I would expect you to optimize for a very infrequently used option like this. I normally get 0.5 to 0.6 RT in CCE with Decomb, but using y0 I'm got 0.23 RT.

I think instead of using the y0 option I will process the sections seperately (since my subs are on a black boarder and do not overlay the video) and then stack vertical. Like this:

top=Crop(0,0,720,380).Telecide(guide=1).Decimate(cycle=5)
bottom=Crop(0,380,720,100).FieldDeinterlace().Decimate(cycle=5)
stackvertical(top,bottom)

With this method I get 0.20 RT, but I don't have to worry about the subtitles triggering unnecessary postproccessing on the video.

[neuron2]

Please do get me the clip, as I'd like to get this capability working properly, even if you do have a workaround. Thank you.

[neuron2]

@wmansir

Please try this test version and let me know how it works. The numbers are referenced to the bottom.

[wmansir]

Did you get the ran clip from my PM?

Using the examples from that clip, it seems you have worked out whatever bug was causing y0 and y380 to give the same results. However, it appears that y=0 is the top line.

Example 1, y0=0,y1=100, version 4.01
http://www.imgmag.com/images/wmansir/Ran_4_Y0_401.jpg

Example 1, y0=0,y1=100, version 4.02
http://www.imgmag.com/images/wmansir/Ran_4_Y0_402.jpg

Example 1, y0=380,y1=480, version 4.01
http://www.imgmag.com/images/wmansir/Ran_4_Y380_401.jpg

Example 1, y0=380,y1=480, version 4.02
http://www.imgmag.com/images/wmansir/Ran_4_Y380_402.jpg

Example 2, y0=0,y1=100, version 4.01
http://www.imgmag.com/images/wmansir/Ran_14_Y0_401.jpg

Example 2, y0=0,y1=100, version 4.02
http://www.imgmag.com/images/wmansir/Ran_14_Y0_402.jpg

Example 2, y0=380,y1=480, version 4.01
http://www.imgmag.com/images/wmansir/Ran_14_Y380_401.jpg

Example 2, y0=380,y1=480, version 4.02
http://www.imgmag.com/images/wmansir/Ran_14_Y380_402.jpg

I had hoped to put those images inline, but it doesn't matter. If you check them out you will see that for each example of the four versions only y0=0,y1=100 version 4.02 gives bad results. The other three are exactly the same, even the p,c,n numbers.

[neuron2]

The clip I downloaded was corrupt for some reason.

Thank you for the results. I'll investigate the numbering issue more but it appears to be working now, no?

[wmansir]

Yes, it appears to be working fine, with y0=0 referencing the top line.

I just dowloaded the clip again and it seems to work fine for me. If it's a RAR problem, it may be because they are 3.0 rars and need Winrar 3.0 or higher to open. The clip uses the Huffyuv 0.2.2 codec available from doom's downloads.

But anyway, thank you for your help.

[reddragon72]

does this work with cce2.5? I cannot get it to load if it does. I have tried several ways and nothing. I don't have enough drive space to create big AVI files so I was triing to frame serve into CCE like I do with avisyth normally, but when I add the lines for this it crashes CCE.

LoadPlugin("c:\windows\system32\mpeg2dec.dll")
LoadPlugin("C:\Program Files\AviSynth2\plugins\Decomblegacy.dll")
mpeg2source("D:\dvdeditedvideo\dvdxcopy\van\van.d2v")
#AVISource("D:\dvdeditedvideo\dvdxcopy\van\van_d2v-vfapi.avi")
#ResampleAudio(44100)
Telecide
Decimate15


thanks for any help.

[scmccarthy]

Why do you have lines that are commented out? Also, trust me, you should always use parenthesis, even when they are empty.

Stephen

[lark]

i agree with the parenthesis.
most probably the avisource is commented out,
because there's already mpeg2source.

don't ask me about the resampleaudio.

regards
t :)

[manono]

Hi-

Before plugging your scripts into CCE and having them crash, you should probably open them first in VDub for testing. Then when they crash (as yours certainly will), at least you'll get an error message to point you in the right direction for fixing them. So, what is this:

Telecide
Decimate15 ? Do you really mean to say:

Telecide()
Decimate(5) ?

[hakko504]

AFAIK you need to uncomment the Resampleaudio line to make CCE accept the .avs

[neuron2]

Originally posted by manono
Telecide
Decimate15 ? Do you really mean to say:

Telecide()
Decimate(5) ? He must have grabbed a REALLY OLD beta from that old thread.