Motion based curve modulation

[movmasty]

let me ask a newbie question (i know that "someone" will smile at this point)

if i use Motion based curve modulation,

do i have to set the default curve compression too ?

or the use of motion based curve compression make the compression based on frame size unuseful ?

[movmasty]

?

any help will be really appreciated :)

[LotionBoy]

as far as I'm aware, you should use both. CC adjusts the bitrate so that your filesize is going to be correct. Then MBCM steps in a slightly adjusts that value so that low-motion frames get more bits. I've never had problems using both of them together.

LotionBoy

[movmasty]

ok thanks, this is something.

[poopity poop]

Boo on motion based curve modulation. If you are making a high enough quality encode like a 230mb/episode anime episode, use 0/0 for motion based, and curve compression to help stress those high action scenes. But only if you have plenty of bits to go around.

This is very much disputed unfortunatly, but it works great, TRUST ME!

[movmasty]

i didnt really thought to have problems using both the normal curve compression and the motion based modulation,
i was asking if the two curve compression sums their effects, so that the bit curve gets compressed twice,
really if curve compression cut bits from large frames and gives to small frames AND the motion modulation cuts bits from high motion frames and gives to lm frames....that could happen.

[poopity poop]

good point...

I thought they summed, but now that I think abotu it...does one cut from hm and give to lm, and the other cut from lm and give to hm?

[LotionBoy]

It's kinda compressing twice, but the two settings do different things. Curve Compression takes the curve and scales the entire thing down around a center point. So low bitrate scenes get moved up and high bitrate scenes get moved down. Well, this kinda sucks because maybe scenes that aren't getting a lot of bits don't need any more, and scenes that really need those bits are being starved. So Asymmetric curve compression was introduced which allowed you to compress certain areas of the curve more than others. This fixed a lot of the problems, especially on 2 CD rips. But problems still remained on 1CD rips with low-motion/high-bitrate scenes not getting enough bits. So MBCM was the solution. This goes through the already compressed curve and removes bits from action scenes and give them to slow scenes. However, it is not recompressing the curve, it is simply adjusting the bits.
To try and make this a little clearer. (numbers are bytes)
1st pass: HighMotionFrame = 300 LowMotionFrame = 1500 total = 1800
Curve Compression (15%): HM = 255 LM = 1275 total = 1530
MBCM(10%): HM = 229.5 LM = 1300.5 Total = 1530

This is really simplistic (and it's a 2 frame movie with motion too :-), but I think it shows the difference between the two. One changes the total file size. The other doesn't

LotionBoy

[movmasty]

in general high bitrate and high motion frames could considered the same, cause a detailed scene that doesnt change gets few bytes after the key.
i was used to use curve compression or set different DRF based on motion as an alternative,
so i dont really know if mbcm takes the place of DRF settings, why i have to use it together with the curve compression.

[LotionBoy]

NO. High bitrate and High Motion are NOT the same thing. Images the move only slightly take more bits to encode otherwise they swim horribly (try encoding someone talking at a low bitrate. Looks like absolute shit). High Motion = Lower Bitrate. because the codec can cheat a lot more and the eye cannot tell the difference. Setting DRFs based on Motion and MBCM are basically the same thing. If you use one, you don't need the other. I prefer MBCM because it is a much simpler operation. If you don't understand why you need MBCM and curve compression, reread my last post. It explains the difference.

LotionBoy

[OUTPinged_]

poop: MBCM is a good thing. it can be used along with motion based drf range too.

it is just the way you encode. for some reason i am getting a better results with a very heavy MBCM usage along with M-B drf range.

just cap drf low enough and no blocks :P

[manono]

I think I'm with poopity poop on this one. Assuming you have enough bits to go around, I like the motion scenes to have the same percentage as the static scenes, and I disable the curve compression. But if you just cap drf low enough , the end result should be pretty much the same.

[poopity poop]

fir average bitrates of above 1100 (usually 2 CD encodes) I usually cap the max DRF at like 8, and the kf DRF at 6.

lotHigh Motion = Lower Bitrate

I can see what you are saying about how the codec can cheat, but if you go frame by frame, the codec really doesn't cheat, it puts in exactly what the eye sees. I'm just confused as to how you think higher motion just uses lower bitrate, that really doesn't make any sense. The higher the motion the higher the bitrate, an the lower the motion te lower the bitrate.

QUESTION FOR EVEYRONE:
Anyone ever esperiment with using high motion DivX 3 at high motion scenes? Are there any advantages/disadvantages to high motion over low motion...I mean we are using nandub which acts like high motion divx.

[LotionBoy]

Alright, let me try and explain this.
You have a face in the frame and it is talking. A nice close-up from your favorite movie. okay? The face is barely moving so you can really focus well on it. So if there is a bad macroblock or a bad frame or something, it is going to jump way out at you. If compression artifacts start swimming across the area right behind his/her head, you are going to see it and it is going to suck. A lot. Now you take a high motion scene. The scene is zooming by, and you cannot concentrate on macroblocks in the background because you do not have time to focus on them. Things can be much blurrier and blockier in a high motion scene because the eye cannot pick them up. So basically, the higher the motion in a scene, the less bits it needs to appear fine to the human eye (when in motion. If you go frame by frame in VDub it is not going to look great, but that isn't the point. THe point is that it looks fine in motion). Of course, there is a limit to how much you can steal from the high motion scenes before the problems become noticable. In a lot of cases, this limit can be a personal thing. That's what MBCM is for, allowing you to find the limit that works for your viewing preferences. If the average bitrate is over 1000, though, you don't need any MBCM, unless it is an insanely hard movie to encode.

Oh, one more thing. Look at how High and Low motion Divx work.
Low motion = DRFs from 2 to 31
High Motion = DRFs from 5 to 31
Why does the High Motion codec not use low DRFs? because high motion scenes need less detail = less bits.

LotionBoy

[OUTPinged_]

poop, i am capping drf range at 2-5 for motion under 200 and 4-6 for motion over 200. imo high motion frames look ok on drf6 in case you are out of bits.

the point for me is to make an encode which plays excellent without postprocessing.

divx3 hi-mo codec doesnt change things for hi-mo scenes at all. it just had more recent build of motion estimation engine (some bugfixes), but it was producing more inverted macroblocks for drf's under 4 (at least that what i got).

lotionboy, poop was referring to the differences they will have when encoding in nandub, and hi-mo codec's drf goes under 2 easy in there.

so MBCM rulez :P

mm.. my recent encode's setup was like drf's-see above, CM =2/25, MBCM=25 =) i gave here most of bitrate to lomo and pannings scenes. drf cap controls compression of himo scenes. turns out looking ok usually. it even works for movies.

[movmasty]

maybe is needed.

@lotion boy, high motion scenes permit more compression, NOT LESS BYTES!

let me explain,
low motion at drf4=50k
high motion at drf4=400k

then
low motion at drf3=67k
high motion at drf6=266k

also if you corrected the compression curve, high motion scenes have
BOTH more compression and more bytes.

[LotionBoy]

yup, you're right. Low motion needs lower DRFs than high motion, but high motion scenes usually use more bits. oops, my bad. apologies all around.

LotionBoy