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.

[Guest]

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]

Originally Posted by bizz & buzz

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.

[Guest]

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.
-----

Originally Posted by bizz & buzz

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.

[Guest]

Huh???

[10L23r]

Originally Posted by 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.

That's what he means.

[bizz & buzz]

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

so regarding the way avisynth works:

Originally Posted by bizz & buzz

2Bdecided@ as Didée showed, there is no such intelligence in avisynth,[<-scratch that ] 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?