Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 22nd January 2007, 19:37   #1  |  Link
akapuma
Registered User
 
akapuma's Avatar
 
Join Date: Jun 2003
Location: Germany (near Cologne)
Posts: 66
suggestion for new x264-parameter

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
akapuma is offline  
Old 22nd January 2007, 21:38   #2  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
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.
akupenguin is offline  
Old 22nd January 2007, 22:27   #3  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 6,670
Quote:
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.

---

Quote:
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
Selur is offline  
Old 22nd January 2007, 22:42   #4  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
Quote:
Originally Posted by Selur View Post
Could you explain how keyint, minkeyint and scenecut interact?
Code:
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.
Quote:
Is there a way atm to tell x264 to do this?
no

Last edited by akupenguin; 24th January 2007 at 03:15.
akupenguin is offline  
Old 22nd January 2007, 22:42   #5  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 6,670
thx
Selur is offline  
Old 22nd January 2007, 22:51   #6  |  Link
check
phjbdpcrjlj2sb3h
 
check's Avatar
 
Join Date: Sep 2005
Location: Western Australia
Posts: 1,692
Quote:
Originally Posted by akupenguin View Post
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?
check is offline  
Old 22nd January 2007, 23:02   #7  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
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.)

Last edited by akupenguin; 22nd January 2007 at 23:10.
akupenguin is offline  
Old 23rd January 2007, 22:26   #8  |  Link
akapuma
Registered User
 
akapuma's Avatar
 
Join Date: Jun 2003
Location: Germany (near Cologne)
Posts: 66
Hello akupenguin,

thank you for your detailed explanation.

Quote:
Originally Posted by akupenguin View Post
Code:
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
akapuma is offline  
Old 23rd January 2007, 23:09   #9  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
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.
akupenguin is offline  
Old 23rd January 2007, 23:28   #10  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 6,670
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:
Quote:
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:
Code:
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

Last edited by Selur; 23rd January 2007 at 23:38.
Selur is offline  
Old 24th January 2007, 03:16   #11  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
Quote:
Originally Posted by Selur View Post
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
Quote:
so I thought that it is automaticly used by all the people who use more than one thread]
That's what I said.
akupenguin is offline  
Old 24th January 2007, 06:50   #12  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 6,670
Ok, thx.
Selur is offline  
Old 24th January 2007, 13:02   #13  |  Link
akapuma
Registered User
 
akapuma's Avatar
 
Join Date: Jun 2003
Location: Germany (near Cologne)
Posts: 66
Quote:
Originally Posted by Selur View Post
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:
Code:
(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
akapuma is offline  
Old 24th January 2007, 16:39   #14  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
Look at my original post, which is now fixed, not Selur's quote of my post.
akupenguin is offline  
Old 24th January 2007, 19:02   #15  |  Link
akapuma
Registered User
 
akapuma's Avatar
 
Join Date: Jun 2003
Location: Germany (near Cologne)
Posts: 66
Quote:
Originally Posted by akupenguin View Post
Look at my original post, which is now fixed, not Selur's quote of my post.
Thank you.

Best regards

akapuma
akapuma is offline  
Old 24th August 2010, 23:57   #16  |  Link
A.Fenderson
Registered User
 
Join Date: Mar 2009
Posts: 230
Quote:
Originally Posted by akupenguin View Post
Code:
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.
A.Fenderson is offline  
Old 6th March 2011, 17:37   #17  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
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)
Code:
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.

Last edited by wOxxOm; 7th March 2011 at 02:19.
wOxxOm is offline  
Old 20th January 2012, 12:01   #18  |  Link
movmasty
Registered User
 
Join Date: Feb 2002
Posts: 970
Quote:
Originally Posted by akapuma View Post
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
Quote:
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
Quote:
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...
movmasty is offline  
Old 20th January 2012, 12:15   #19  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,221
Why do you reply to a post that is 4 years old?
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:20.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.