suggestion for new x264-parameter

[akapuma]

Hello,

I have a suggestion for a new x264-parameter.

Example: I've the following parameters:
--scenecut 40 --keyint 300

The first frame be an I-frame. Now, P- and B-frames are following. If the scene change is less then 40%, no further I-Frame is set. If there are 300 frames, an I-frame is set, independed from the percental scene change at this frame. Depending on the movie there are up to 50% I-frames set at the value, specified with --keyint.

We suppose that the percental scene change of all frames is less then 20%, except frame 295. The percental scene change of frame 295 is 35%. But x264 sets the I-Frame at position 300. I think, it's more clever to set the I-frame at position 295 instead of position 300.

Now my suggestion for a new parameter, for example "--scenecut-cutback":

--scenecut 40 --keyint 300 --scenecut-cutback 250,10
x264 uses the scenecut value 40 up to frame 250. From frame 250 to 300, the scenecut value is decreased by 10 to 30.

Or another syntax:
--scenecut 40 --keyint 300 --scenecut-cutback 250
x264 uses the scenecut value 40 up to frame 250. From frame 250 to 300, the scenecut value is linear decreased to zero.

And now my favourite syntax:
--scenecut 40 --keyint 300 --scenecut-cutback 250,10
x264 uses the scenecut value 40 up to frame 250. From frame 250 to 300, the scenecut value is linear decreased to 10.

Goal is to reduce the number of I-frames set at the position --keyint, because the scene change value of this frame may be low.

Best regards

akapuma

[akupenguin]

First, you mean increase scenecut value as it nears keyint. It already does that, though the increase is linear, starting at 0 immediately after the previous keyframe and sloping up to the scenecut at keyint. Yes, maybe some shape other than linear would be slightly better.
But if you're thinking about improving it, why not go for the optimal solution? Don't enforce keyint at all on the 1st pass, then the 2nd pass can insert keyframes wherever it needs to to minimize the bitrate cost while satisfying keyint. e.g. assume keyint 300 and it turns out that there was a good scenecut at frame 350, then the 2nd pass can pick any frame between 50 and 300 to become the extra keyframe.

[Selur]

It already does that, though the increase is linear, starting at 0 immediately after the previous keyframe and sloping up to the scenecut at keyint

Okay, now I'm confused.
Could you explain how keyint, minkeyint and scenecut interact?
I suspect that both akapuma and me misunderstood the interaction.

I assumed it would work like this:
Current frame is compared to the last frame before it, if it differs more than scenecut precent a scenecut is detected and if we are more than minkeyint frames away from the last idr-frame an idr-frame is set, otherwise an I-frame is set. If the distance to the previous idr-frame is reaching keyint, an idr-frame is enforced.

But since there's nothing growing at all, this must be wrong.

---

But if you're thinking about improving it, why not go for the optimal solution? Don't enforce keyint at all on the 1st pass, then the 2nd pass can insert keyframes wherever it needs to to minimize the bitrate cost while satisfying keyint. e.g. assume keyint 300 and it turns out that there was a good scenecut at frame 350, then the 2nd pass can pick any frame between 50 and 300 to become the extra keyframe.

Is there a way atm to tell x264 to do this?

Cu Selur

[akupenguin]

Originally Posted by Selur

Could you explain how keyint, minkeyint and scenecut interact?

encode current frame as (a really fast approximation of) a P-frame and an I-frame.

if ((distance from previous keyframe) > keyint) then
    set IDR-frame
else if (1 - (bit size of P-frame) / (bit size of I-frame) < (scenecut / 100) * (distance from previous keyframe) / keyint) then
    if ((distance from previous keyframe) >= minkeyint) then
        set IDR-frame
    else
        set I-frame
else
    set P-frame

encode frame for real.

Is there a way atm to tell x264 to do this?

no

[Selur]

thx

[check]

Originally Posted by akupenguin

But if you're thinking about improving it, why not go for the optimal solution? Don't enforce keyint at all on the 1st pass, then the 2nd pass can insert keyframes wherever it needs to to minimize the bitrate cost while satisfying keyint. e.g. assume keyint 300 and it turns out that there was a good scenecut at frame 350, then the 2nd pass can pick any frame between 50 and 300 to become the extra keyframe.

Is there a catch with this method, apart from a less playable first pass output?

[akupenguin]

It might have some effects on bitrate prediction, but we all know that 2pass bitrate prediction is very resilient to munging the 1st pass settings, so that shouldn't be too bad. Maybe in the extreme case where there's no scenecuts at all, so there's no I-frames in the first pass (aside from frame #0), then it might have a hard time predicting the size of I-frames.

If it's on top of a 1st pass compressability check / 2nd pass CRF (or the variant thereof that I plan to implement), then there should be no penalty at all. (i.e. the variant doesn't predict size perfectly, but 2pass keyframe selection won't make it any worse.)

[akapuma]

Hello akupenguin,

thank you for your detailed explanation.

Originally Posted by akupenguin

if (100 * (bit size of P-frame) / (bit size of I-frame) < scenecut * (distance from previous keyframe) / keyint)

Is the scenecut-parameter only used in the formula above? Or does he have more effects?

Best regards

akapuma

[akupenguin]

That is the only use of the scenecut parameter. However, that formula also has an indirect effect that might not be obvious: When not using --pre-scenecut nor --threads, if a P-frame after some B-frames triggers the scenecut but a P-frame without any B-frames doesn't, then x264 will use the one without B-frames. Thus effectively the B-adapt threshold is reduced near keyint. This is a bug, I guess, and I advise people to try out --pre-scenecut.

[Selur]

shouldn't it be a > instead of a < ?
(like if the p-frame get's bigger the probablility of an I-Frame should rise)

about --pre-scenecut, x264 --lonhelp states:

Faster, less precise scenecut detection. Required and implied by multi-threading.

so I thought that it is automaticly used by all the people who use more than one thread

or should it be something like:

if (100 * (bit size of P-frame) / (bit size of I-frame) < scenecut * (1-(distance from previous keyframe) / keyint))

something is wrong or at least confusing

Cu Selur

[akupenguin]

Originally Posted by Selur

shouldn't it be a > instead of a < ?
(like if the p-frame get's bigger the probablility of an I-Frame should rise)

fixed

so I thought that it is automaticly used by all the people who use more than one thread]

That's what I said.

[Selur]

Ok, thx.

[akapuma]

Originally Posted by Selur

shouldn't it be a > instead of a < ?
(like if the p-frame get's bigger the probablility of an I-Frame should rise)

And please look at the right site of the formula:

(100 * (bit size of P-frame) / (bit size of I-frame) > scenecut * (1-(distance from previous keyframe) / keyint))

I think, the right site of the formula must have high values, if (distance from previous keyframe) is low. In the original formula, the right site is near zero if (distance from previous keyframe) is low. I think, near the last keyframe the chance of a new keyframe should be low. And short before the keyint-parameter, the chance of a new keyframe should be higher.

Best regards

akapuma

[akupenguin]

Look at my original post, which is now fixed, not Selur's quote of my post.

[akapuma]

Originally Posted by akupenguin

Look at my original post, which is now fixed, not Selur's quote of my post.

Thank you.

Best regards

akapuma

[A.Fenderson]

Originally Posted by akupenguin

encode current frame as (a really fast approximation of) a P-frame and an I-frame.

if ((distance from previous keyframe) > keyint) then
    set IDR-frame
else if (1 - (bit size of P-frame) / (bit size of I-frame) < (scenecut / 100) * (distance from previous keyframe) / keyint) then
    if ((distance from previous keyframe) >= minkeyint) then
        set IDR-frame
    else
        set I-frame
else
    set P-frame

encode frame for real.

Wouldn't it be faster to perform the first comparison prior to approximating the P and I frames, as those approximations have no bearing on that decision and a TRUE value will skip the entire else block (and all comparisons which do rely on the approximations)?

Sorry to resurrect such an old thread, was researching settings explanations and this page is referenced here for --scenecut.

[wOxxOm]

Byte-size based decision is fast, surely, yet it sometimes misses visually obvious scenecuts while placing I/IDR in a visually same scene with some relative small occasional motion. The log of course shows that missed scenecuts are so visually simple and are being compressed so well that the formula doesn't see it as a scenecut candidate no matter how much one increases --scenecut.

And it happens a lot in anime source I have: maybe half of scenecuts are missed/misplaced.

This does not influence video quality of course, yet seeking would be more comfortable if I-frames are placed at real (for human perception) scene change. Also it spoils automatic snapping of subtitles to scenechanges while manually retiming in Aegisub. The purpose of such snapping is to avoid flickering of text being displayed for a (fraction of a) second just after a scene change occurs.

The only realworld solution I personally have is to generate a qp-file using motion analysis and run it through avs2yuv (for 576p it takes about 5-10% of time comparing to x264 @ veryslow/L3.2 - and of course potential x264 implementation would be *much* faster than avisynth+avs2yuv)

MSCDetection(last,MAnalyse(MSuper()))
WriteFileIf("01.sc", "AverageLuma>100", "current_frame",""" " I" """,false,true)

I wonder if it's possible to have x264 use its internal motion analysis data in scenecuts detection, probably as a separate option?

p.s. also currently frame type set in qpfile is ignored if --scenecut condition is not met, which contradicts 'force frame type' nature of qpfile - it should be treated unconditionally.

[movmasty]

Originally Posted by akapuma

Hello,
If the scene change is less then 40%, no further I-Frame is set.
Now my suggestion for a new parameter, for example "--scenecut-cutback":

--scenecut 40 --keyint 300 --scenecut-cutback 250,10
x264 uses the scenecut value 40 up to frame 250. From frame 250 to 300, the scenecut value is decreased by 10 to 30.

Or another syntax:
--scenecut 40 --keyint 300 --scenecut-cutback 250
x264 uses the scenecut value 40 up to frame 250. From frame 250 to 300, the scenecut value is linear decreased to zero.

And now my favourite syntax:
--scenecut 40 --keyint 300 --scenecut-cutback 250,10
x264 uses the scenecut value 40 up to frame 250. From frame 250 to 300, the scenecut value is linear decreased to 10.
akapuma

Am i wrong or I frames are triggered as scenecut value increases??

From MeGUI/x264 Settings wikibooks.
http://en.wikibooks.org/w/index.php?...&oldid=2201086

scenecut
*Integer: 40*
Sets the threshold for IDR frame placement(read: scene change detection).
x264 calculates a metric for every frame to estimate how different it is from the previous frame.
If the value is lower than scenecut, an IDR frame is used.
The metric is slightly more complex then, but it's a reasonable approximation.
Higher values of scenecut increase the number of scenecuts detected. For more information on how
the scenecut comparison works, see doom9 http://forum.doom9.org/showthread.php?t=121116

From X264 Settings MeWiki
http://mewiki.project357.com/wiki/X264_Settings

scenecut
Default: 40

x264 calculates a metric for every frame to estimate how different it is from the previous frame. If the value is
lower than scenecut, a 'scenecut' is detected. An I-frame is placed if it has been less than --min-keyint frames
since the last IDR-frame, otherwise an IDR-frame is placed.

Higher values of scenecut increase the number of
scenecuts detected. For more information on how the scenecut comparison works, see this doom9 thread
http://forum.doom9.org/showthread.php?t=121116

The thread is this, but the content doesnt match...

[LoRd_MuldeR]

Why do you reply to a post that is 4 years old?