what's the proper way of go back to original frame-rate after bobbing?

[bizz & buzz]

say i deinterlace using TempGaussMC, so now my clip's fps is doubled.
how should i go back to the original frame-rate?
if i insert "SelectEven()" at the end of the script, it means that the encoding app will have only half the available frames to work with, which is sub-optimal in terms of motion compensation etc...
am i right or did i get it completely wrong?

[thewebchat]

You did indeed get it completely wrong. In fact, TGMC (and all other bobbers) did not change your framerate. It took your 60 fields/second clip and changed it to a 60 frames/second clip. If anything, it has upscaled your clip 2x in the vertical direction. If you want to get 30 frames/second out of the 60 frames/second source, the only possibilities are to either drop every other frame (SelectEven) or average every pair of frames (Merge(SelectEven,SelectOdd)). The latter is probably a bad idea.

[bizz & buzz]

ok so basically what i get after bobbing is not a "real" 60 fps clip.
nonetheless, in terms of motion oriented operations made by the encoder app in order to improve quality/compressibility - wouldn't it be better to let it work with all the frames? and only then to drop the unwanted frames somehow?

[Adub]

Yes, but that "somehow" is the problem.

[neuron2]

You can go back keeping all the temporal information with:

separatefields
selectevery(4,0,3)
weave

But then one wonders why you bobbed in the first place since it will be interlaced again. :)

If you want single rate progressive use a deinterlacer, not a bobber. A bobber followed by decimation by two is equivalent to a single rate deinterlacer.

[bizz & buzz]

Adub@ i know. but hypothetically, let's assume there's a tool that can do that - will it's calculations of motion vectors (for example..) would be better, thus improving the quality, even-tough it will encode only half the frames at the end??

neuron2@ you're right - i'm not interested in the bobbing effect (double-rate), but only in making the clip progressive and maintaining it's original rate. only problem is that for me, TGMC gave the most pleasing results, but now i'm "stuck" with a double rate clip.
that's when i would have used "SelectEven()" and feed the result to the encoder, but it got me thinking that's it's kind of a waste (encoder efficiency wise)...

[shoopdabloop]

do you plan on changing the framerate with MVTools/MotionProtectedFPS? because i would keep all the bobbed frames before doing that.

but if you're not, i guess it depends on whether or not you want the filters to work on 30p footage, or 60p.
the former would be faster.

unless you're asking for a single-rate version of TGMC, and i know nothing about that filter..

[bizz & buzz]

shoopdabloop@ keeping the bobbed frames for the use of MVTools etc further down in the script is surly the right thing to do, but this is not my case. after deinterlacing i plan on cropping, resizing, and then straight to the encoder.
and i never heard of a single-rate version of TGMC either :)

come to think about it, it seems the answer to my original question (in the headline) is in fact to use "SelectEven()" at he end of the script. after all, no existing encoder is able to use the "extra" frames for it's benefit, and only then to discard them.
but theoretically, will there be any real benefit in quality or compressibility from such a tool?

[shoopdabloop]

i'm not sure how encoders work when compressing things, but i really doubt it would help much.

[Nite Phire]

The motion estimation that encoders do would not be improved by the data from the extra frames. If anything it might be hurt.

Essentially encoders use motion estimation to just tell if there's a (near-)identical block in consecutive frames. If so, it takes less bits to simply say, "Hey, there's this block in frame X, if we put it here in frame Y, it works," instead of having to save the data for the block twice. Knowing where it was in between X and Y is of no use to the encoder.

[2Bdecided]

if you do tgmc and then selectevery(2,0), wouldn't AVIsynth automatically skip the processing of any frames that it could? Or doesn't it work like that?

Let me put it more generally - say you had an intra-frame denoiser, and then did selectevery(10,0) - would AVIsynth denoise all the frames, and then dump 9-in-10, or would it only denoise 1-in-10 to start with?

I thought there was some intelligence like this built-in ti AVIsynth - but in the case of TGMC I suspect it needs to calculate pairs of frames, even if you dump every other one later.

Cheers,
David.

[Didée]

Dear readers, make yourself this little experiment:

mpeg2source("source.d2v") # whatever you have at hand

temporalsoften(5,22,22,22,2)

# selecteven()

return( last )
Run this script. Note the fps you're getting.

Now, what will happen if you activate the "selecteven" line? Expect the processing speed to be doubled?

Try, note what you get, and think about why it is like it is.


Having made that exercise, it should become obvious why there is no same-rate option for TGMC. :)

_____

The crucial point of TGMC's processing is, of course, the temporal filtering that it does.

Surely Avisynth will not request frames that were discarded by any of the Select*() commands. But that is pretty much irrelevant. The later-on discarded frames are fully involved in (and are !essential! for) all the motion compensation etc. stuff before they are discarded.

[bizz & buzz]

Nite Phire@ motion estimation (creating the motion vectors) and motion compensation (the creation of B/P frames) are different.
as you said, MC will obviously not work if at the end frames are being discarded.
but maybe the ME can benefit from more frames? even though they will be discarded at the end?

2Bdecided@ as Didée showed, there is no such intelligence in avisynth, so using the example you posted, what will happen is the first scenario.

[Gavino]

2Bdecided@ as Didée showed, there is no such intelligence in avisynth, so using the example you posted, what will happen is the first scenario.
On the contrary, there is such intelligence in Avisynth, which only processes the frames it needs, no more, no less.
What Didée showed was that frames discarded (eg by SelectEven()) might still have been needed in an earlier step (eg TemporalSoften()) and so were still processed to produce the frames that are not discarded.

[neuron2]

Yes, and just to clarify for those that don't understand this: a filter can internally request frames other than the frame requested by GetFrame(). So just because a SelectEven() does not ever request half the frames, the previous filters may request them internally. Typically, temporal filters must do that.

[Didée]

edit - the post took too long, the 1st part has been covered in the meantime...
-----
as Didée showed, there is no such intelligence in avisynth
That's wrong. Said "intelligence" by all means IS in Avisynth. The point is that it doesn't apply in this case. That's a difference.
-----

but maybe the ME can benefit from more frames? even though they will be discarded at the end?
For all usual practical purposes: No, it can not.

[..breeding..] - no, that's too technical to be explained in short. Basically, it won't help because the potential motion vectors would refer to image data that is no more available after discarding one half of the frames.

There is a theoretical possibility, if you had a codec with motion engine that uses temporal predictors, and that is aware that half of the frames should be discarded.
However there is no such encoder or tool, so there's not much point in discussing this deeply.

[thewebchat]

I would just like to point out that bobbing does NOT double the rate. In fact, "single-rate" deinterlacers HALVE the framerate.

[neuron2]

Huh???

[10L23r]

You did indeed get it completely wrong. In fact, TGMC (and all other bobbers) did not change your framerate. It took your 60 fields/second clip and changed it to a 60 frames/second clip. If anything, it has upscaled your clip 2x in the vertical direction. If you want to get 30 frames/second out of the 60 frames/second source, the only possibilities are to either drop every other frame (SelectEven) or average every pair of frames (Merge(SelectEven,SelectOdd)). The latter is probably a bad idea.

That's what he means.

[bizz & buzz]

Didée@ thanks for answering my far-out-there theoretical question :)

so regarding the way avisynth works:
2Bdecided@ as Didée showed, there is no such intelligence in avisynth,[<-scratch that :p] so using the example you posted, what will happen is the first scenario.

if i said that every filter in the chain is processing what was given to it by it's previous filter (as was portrayed in 2Bdecided's first scenario), then what's the difference between what you say, and what i said?

[neuron2]

Single-rate deinterlacers do not halve the frame rate. That is absurd.

[bizz & buzz]

ok, let me get this straight (sorry if i'm stating the obvious):
say a clip is progressive, and has 100 frames. in the script i put selecteven() and then temporalsoften() - will the temporalsoften() use 50 frames, or 100 frames?

[Gavino]

if i said that every filter in the chain is processing what was given to it by it's previous filter (as was portrayed in 2Bdecided's first scenario), then what's the difference between what you say, and what i said?
Here's what 2Bdecided actually said:
Let me put it more generally - say you had an intra-frame denoiser, and then did selectevery(10,0) - would AVIsynth denoise all the frames, and then dump 9-in-10, or would it only denoise 1-in-10 to start with?
The answer in this case is it would only denoise 1-in-10 to start with. Note that he said intra-frame denoiser, ie one that only processes one input frame for each frame it delivers. So here the selectevery asks for every tenth frame and that's what the said denoiser will process.

If it was a temporal denoiser, selectevery still asks for every tenth frame but in order to deliver those frames, the denoiser now has to process additional surrounding frames as well.

[Gavino]

say a clip is progressive, and has 100 frames. in the script i put selecteven() and then temporalsoften() - will the temporalsoften() use 50 frames, or 100 frames?
It can only see 50 frames since in this (new) case, it comes after the selecteven.

[10L23r]

Single-rate deinterlacers do not halve the frame rate. That is absurd.

he was confusing fieldrate w/ framerate.


The answer in this case is it would only denoise 1-in-10 to start with. Note that he said intra-frame denoiser, ie one that only processes one input frame for each frame it delivers. So here the selectevery asks for every tenth frame and that's what the said denoiser will process.


so abc().selectevery(10,0) is the same as selectevery(10,0).abc(), with abc() as an intraframe denoiser? (I mean in terms of speed)

[neuron2]

he was confusing fieldrate w/ framerate. No, single-rate deinterlacers do not halve anything. The number of output fields and frames is the same as the number of input fields and frames.

[bizz & buzz]

Gavino@ so what you are saying is that some filters, does in fact take into consideration what lies a head in the filter chain, and some don't?

[Gavino]

so abc().selectevery(10,0) is the same as selectevery(10,0).abc(), with abc() as an intraframe denoiser? (I mean in terms of speed)
Yes, that's right. In both cases, only 10% of the source frames will be processed.

[Gavino]

Gavino@ so what you are saying is that some filters, does in fact take into consideration what lies a head in the filter chain, and some don't?
No, generally filters do not know what is ahead or behind themselves in the filter chain. What happens is that each filter simply asks its predecessor in the chain for the frames it needs in order to produce its own output frame. So, for example, SelectEven only asks for every 2nd frame of its input - this means that if the previous filter (which is supplying that input) is a spatial (or intra-frame) one, it also only gets to process every 2nd frame.

You might find it useful to read about the script execution model (http://avisynth.org/mediawiki/The_script_execution_model).

[thewebchat]

Clearly single-rate deinterlacers halve the rate. There were originally 60 temporal elements per second and after "single" rate deinterlacing there are only 30. Therefore the rate was halved.

[neuron2]

In fact, "single-rate" deinterlacers HALVE the framerate. They do NOT halve the frame rate as you claimed. They do indeed reduce the temporal resolution. But that is not the same thing. The frame rate and field rate are UNCHANGED.

Your imprecise talk is dangerously misleading.

[bizz & buzz]

gavino, thank you for the clarification and recommended reading :)

[m3mbran3]

If I deinterlace with TDeint(mode=2,edeint=nnedi2(field=-2,qual=3)) then TDeint is smartbobbed field-matching (same rate output, blend frames from bobbed stream) and NNEDI2 is double rate (alternates each frame), uses avisynth's internal parity value to start. Should this produce any different output than simply using TDeint(edeint=nnedi2(qual=3))?

From my tests, the first code performs better in high motion situations, you can see that on the hand that there is a line from the package in the second image, but on the first it is not there. I have no idea why this is though but assume it has something to do with the interlacing.
http://img199.imageshack.us/img199/1418/interlace.png

[shoopdabloop]

i tried your first script on some 60i dv footage and got the ghosting you would expect from TDeint mode 2.
however, the second one did not cause any weird artifacts like that, and as one would expect, looked clearer than the first.
something's not right.

[m3mbran3]

my source is 25i PAL footage if that makes a difference.

[thewebchat]

Well gee, if you "blend frame from the bobbed stream" of course you'll get ghosting.

TDeint(mode=2,blahblahblah) is the same as TDeint(mode=1,blahblahblah).Merge(SelectEven,SelectOdd). TDeint(mode=0) is (in terms of results) the same as TDeint(mode=1,blahblahblah).SelectEven.

Obviously the high amount of blur from blending two temporally-different frames together would result in higher motion "smoothness" compared to just dropping half the frames.

[2Bdecided]

...and if you want to avoid blur and stutter, go to 50p!

Cheers,
David.