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. |
22nd January 2007, 19:37 | #1 | Link |
Registered User
Join Date: Jun 2003
Location: Germany (near Cologne)
Posts: 69
|
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 |
22nd January 2007, 21:38 | #2 | Link |
x264 developer
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. |
22nd January 2007, 22:27 | #3 | Link | ||
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
Quote:
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:
Cu Selur |
||
22nd January 2007, 22:42 | #4 | Link | |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
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:
Last edited by akupenguin; 24th January 2007 at 03:15. |
|
22nd January 2007, 22:51 | #6 | Link | |
phjbdpcrjlj2sb3h
Join Date: Sep 2005
Location: Western Australia
Posts: 1,691
|
Quote:
|
|
22nd January 2007, 23:02 | #7 | Link |
x264 developer
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. |
23rd January 2007, 22:26 | #8 | Link | |
Registered User
Join Date: Jun 2003
Location: Germany (near Cologne)
Posts: 69
|
Hello akupenguin,
thank you for your detailed explanation. Quote:
Best regards akapuma |
|
23rd January 2007, 23:09 | #9 | Link |
x264 developer
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.
|
23rd January 2007, 23:28 | #10 | Link | |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
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:
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)) Cu Selur Last edited by Selur; 23rd January 2007 at 23:38. |
|
24th January 2007, 13:02 | #13 | Link | |
Registered User
Join Date: Jun 2003
Location: Germany (near Cologne)
Posts: 69
|
Quote:
Code:
(100 * (bit size of P-frame) / (bit size of I-frame) > scenecut * (1-(distance from previous keyframe) / keyint)) Best regards akapuma |
|
24th August 2010, 23:57 | #16 | Link | |
Registered User
Join Date: Mar 2009
Posts: 230
|
Quote:
Sorry to resurrect such an old thread, was researching settings explanations and this page is referenced here for --scenecut. |
|
6th March 2011, 17:37 | #17 | Link |
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) 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. |
20th January 2012, 12:01 | #18 | Link | |||
Registered User
Join Date: Feb 2002
Posts: 970
|
Quote:
From MeGUI/x264 Settings wikibooks. http://en.wikibooks.org/w/index.php?...&oldid=2201086 Quote:
http://mewiki.project357.com/wiki/X264_Settings Quote:
|
|||
20th January 2012, 12:15 | #19 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Why do you reply to a post that is 4 years old?
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
Thread Tools | Search this Thread |
Display Modes | |
|
|