decrease frame rate after mvbob

[yup]

Hi folk!
I use mvbob for deinterlacing for DVD source and DV source.
Work fine, but slow. I want make XVID file for see on standalone player, but my player support only ordinary frame rate 25fps or 29.997. also I want make video for mobile phone which support only 15fps. Please advise way for decrease frame rate after mvbob 50fps to 25fps or 15fps. May be can make motion compensated temporal smoothig befor decimating, but how?
With kind regards yup.

[actionman133]

If your source is 50 fps (after MVBob), a simple SelectEven () will drop the framerate to 25 fps for Xvid output.

For your mobile phone, you can just use ChangeFPS (15) which is very fast but rather uneven with motion, or you can use MVConv (15, 1). MVConv is very slow though, especially when used in conjunction with MVBob ().

[yup]

actionman133 thank You for reply.
In my package mvbob only function ConvertMCfps. SelecEven work fine for 25fps, but ConvertMCfps rarely give strange picture for 15fps especially during fast change scene. Now I try choose optimal parameter for ConvertMCfps.
yup.

[chipzoller]

This is not *entirely* related to yup's questions, but for my sake I was wondering if mvbob() is commonly used followed by selecteven() or something to retain maximum fluidity over something like a same frame-rate deinterlacer? This sounds stupid but I'm just curious if something like this is 1.) commonly implemented or 2.) if it's just a total waste of time and CPU cycles? But seriously, WOULD something like this give better picture clarity (in theory)?

[foxyshadis]

Bob+SelectEven is entirely equivalent to "same rate" deinterlacing. They are literally two different ways to look at the exact same behavior. The only differences you'd see would be caused by specialized code (like, slightly blending the two frames instead of returning just one pure frame).

[chipzoller]

But as far as frame quality is concerned, is a bob+SelectEven going to yield better results than having a same-rate deinterlacer interpolate a new line, even if it's not from scratch?

[foxyshadis]

You're connecting two separate things. Bobbing and same-rate deinterlacing are the same thing, first off. KernelDeint was extended to bobbing by simply running it on both fields in turn, for instance.

Whether an individual deinterlacer interpolates a single field of each frame, or changes both fields (like bob() or eedi2()) is part of the algorithm, and entirely unrelated to whether it's a bobber or same-rate. Although the consensus seems to be that it's always better to keep the original field, so most will, whether they output same or double.

Whether they're dumb, working off a single field, or smart, working off multiple fields by some sort of motion compensation, is also unrelated to the output rate.

[Didée]

But as far as frame quality is concerned, is a bob+SelectEven going to yield better results than having a same-rate deinterlacer interpolate a new line, even if it's not from scratch?

As foxyshadis said, it's not a question about double-rate+decimate or same-rate. The question is only about the used methods of interpolating the missing fields.

Generally I'm not a blind fan of synthetic metric numbers, but these here (http://forum.doom9.org/showthread.php?p=902673#post902673) seem spreaded enough to give hint.

[chipzoller]

Didée, thanks for that thread link. It's very helpful.
I think I understand what you two are at.

Also @ Didée: What is your most current MVBob()? Is it still the one in your RAR archive?

So how about this: Does it matter if you use somebober().selecteven() or .selectodd() ? Is there some method which you determine which frames you should take as the final frame count? Should selecteven() be used with top field first material and selectodd() vice-versa?

EDIT: This question was answered starting with this (http://forum.doom9.org/showthread.php?p=893663#post893663) post.

[Didée]

Latest one is this one (http://home.arcor.de/dhanselmann/_stuff/MCBob_v03c.avs) ... I hope that it's finally correct, after having caused some confusion, starting here (http://forum.doom9.org/showthread.php?p=916967#post916967) :D

Theoretically it doesn't matter whether Decimation is done by SelectEven() or SelectOdd(), since both parities are (i.e. should be) same valid.
However the world is full of malformed & mistreated sources, and so of course there might be cases where "something happened" to the source, causing one parity to have lower quality than the other. In such a case it's of course better to select the better one.
(There are even cases where the "better quality" parity is changing between top and bottom (!) - a usual scenario e.g. when source's running time has been altered by artificial fieldblending.)

[zambelli]

Latest one is this one (http://home.arcor.de/dhanselmann/_stuff/MCBob_v03c.avs) ... I hope that it's finally correct, after having caused some confusion, starting here (http://forum.doom9.org/showthread.php?p=916967#post916967) :D
Am I mistaken or do we not have a MCBob dedicated thread yet? FYI, the latest version is still difficult to find - it takes a bit of browsing through 8+ pages of that other thread.

[Didée]

Am I mistaken or do we not have a MCBob dedicated thread yet? FYI, the latest version is still difficult to find - it takes a bit of browsing through 8+ pages of that other thread.

You're not mistaken. Who knows, perhaps this is an inherent property of mo'comped bobbing scripts? MVBob never had a dedicated thread, too ...