About --keyint --min-keyint and --scenecut

[sirt]

Hello,

I have some questions about those parameters :

1) I've read --keyint should be equal to the framerate of the video multiplied by 10. Let's say my video is a 23.976 fps video. In that case should I use --keyint 240 or --keyint 230 ? In contrast, what will concretely happen if I go higher for such video (like 300 or even more) or lower ?

2) --min-keyint seems to have to be equal to the framerate of the video : 23 or 24 in this case. Would you recommand another value in this case and why ?

3) I had some discussions about --scenecut and it appears a value below 40 should result in a higher detection of scene changes while a a higher value will lead to a less accurate detection (less I frames used as references) ; Nonetheless, is there a good reason regarding such and such specific videos (static backgrounds, a large amount of scene changes ect) which could urge me to change the scencut default value ?

4) As from I read, it seems I should always use this for my 24 fps videos :

--min-keyint 24 --keyint 240 --scenecut 40

But, according to you, in so far as I want to adjust those parameters (which is a purely theoretical goal to my mind), what adequate changes would you recommand within the choose of a 24 fps video with a lot of static frames and backgrounds / OR with tones of scene changes / OR with many combed fields and frames (different sequences in a same frame that refer to a different way of acting such as this frame http://www.hiphoprx.com/content/uplo...ood_things.jpg) ?

[Dark Shikari]

There is no reason keyint "should" be any specific value. It's just a tradeoff between seeking speed and compression. Don't muck with it.

min-keyint is automatically decided by the encoder. Don't muck with it.

Scenecut works the opposite of the way you described, and has nothing to do with "using I-frames as references", because all I-frames are used as references. Don't muck with it.

As a general rule, don't mess with any options that aren't in x264 --help without extremely good reason.

[Groucho2004]

Originally Posted by Dark Shikari

There is no reason keyint "should" be any specific value.

Unless encoding according to Blu Ray specs.

[sirt]

Yes I know it should not be adjusted, but it is precisely why I asked "When CAN I change this and this" ; I want to understand what COULD BE an "extremely good reason" as I read there and on a lot of threads.

[detmek]

Originally Posted by sirt

Yes I know it should not be adjusted, but it is precisely why I asked "When CAN I change this and this" ; I want to understand what COULD BE an "extremely good reason" as I read there and on a lot of threads.

Originally Posted by Groucho2004

Unless encoding according to Blu Ray specs.

Or you have a problem with seeking through file. Then you can use lower values for --keyint.
Just remember, --keyint sets maximum distance between two IDR frames but encoder will set IDR frames closer if video content requires for eficient encoding. And it always does.

[Dark Shikari]

Originally Posted by sirt

Yes I know it should not be adjusted, but it is precisely why I asked "When CAN I change this and this" ; I want to understand what COULD BE an "extremely good reason" as I read there and on a lot of threads.

If you want seeking to be faster, you can make keyint lower. But besides specific specs like Blu-ray, there is no reason for any specific value. There is no reason in the world why 240 would be more or less "right" than 239, or 153 more or less "right" than 152.

The idea of setting it to "framerate*10" as if that was somehow "the right value" is pure cargo cult.

[sirt]

In fact it is not like I want seeking to be faster or slower. What I want to know is why it could be faster or slower (according to the type of the video) and how I could decide to change the values. Nevertheless, it looks like I should just trust the encoder but I know that. My purpose is to understand why it decides such and such options (but don't tell me I should read the code source then, because I would to understand in simple words !)

You say min-keyint is automatically decided by the encoder, so let's say I don't touch it in that case whatever the framerate.

As you explained above setting keyint to a certain value such as fps*10 is somewhat superfluous, what if I just put that :

--preset placebo --keyint 1544411 --crf 16 (for my 24 fps video)

This number is purely random. Can that truely affect the encoding process ? In contrast, would it be better just to use that :

--preset placebo --crf 16

or

--preset placebo --keyint 240 --crf 16

You could answer such and such number will imply an agressive or higher decision but it is not the answer I expect in fact. I would like to know what is the probability to demean the video if I set a purely random number for keyint or/and I set scenecut differently from it's default value.

To sum up, it appears that default values are "magical" in so far as they may work well for each video which is still obscur to me.

[Brother John]

Simply put: Most frames in the video aren’t standalone but depend on earlier frames. Only I frames can be decoded completely on their own. If you seek to between two I frames your decoder must find the preceeding I frame and decode from there to the actual frame you wanted because that is the only way to fully decode that particular frame.

Shorter intervals means faster seeking times on average. Downside: more I frames, and I frames are huge. So you’ll end up with a bigger file or lower quality.

Yes, the usual 10*framrate default is completely arbirary. But it’s also safe to assume that any half-decent computer hardware is capable of (near) instantaneous seeking with that default and it doesn’t impact size/quality in a significant way. So why change it?

[nm]

Originally Posted by sirt

You could answer such and such number will imply an agressive or higher decision but it is not the answer I expect in fact. I would like to know what is the probability to demean the video if I set a purely random number for keyint or/and I set scenecut differently from it's default value.

The higher the keyframe interval, the higher quality you get and the less accurate seeking is during playback since the player can only jump to IDR frames. (Or seeking is slower, if you want to seek to a specific location by decoding all frames from the last IDR frame). Quality improvements diminish quickly, so --keyint 1000 or --keyint infinite is usually not significantly better than --keyint 250.

Originally Posted by sirt

To sum up, it appears that default values are "magical" in so far as they may work well for each video which is still obscur to me.

They are just sensible. In case of --keyint, that range is about 50 to 1000 at ordinary framerates, depending on how much you value seeking accuracy/speed.

[Bloax]

Actually, very low --keyint values (15-40'ish) can really improve the quality in some obscene cases. (Like unfiltered, unantialiased gameplay footage.)
At the expected price of quite a boost in size. :p

Though in those cases, some noise calming - or a serious dose of denoising (or both!) are much better medicine. (It'd improve compressibility too, win-win.)
Unless we're talking about extremely fast videos (as in really fast the entire time.) - Or those weirdo cases, I'd go ahead and say just leave them be.

But overall, you may just be better off just reducing the compression. (Or quantization, whatever.)

[nm]

Originally Posted by Bloax

Actually, very low --keyint values (15-40'ish) can really improve the quality in some obscene cases. (Like unfiltered, unantialiased gameplay footage.)
At the expected price of quite a boost in size.

If you compensate the size by using lower CRF, higher keyint gives better quality. When talking about quality effect of a setting, people usually mean quality at a specific bitrate or same file size.

[Brother John]

Another point to mention: --keyint is the maximum interval. x264 will insert key frames earlier if it deems them beneficial, e.g. due to a scene change. From my experience the majority of key frames are in place because of the properties of the video, not because keyint was reached. The larger --keyint is the smaller the impact on overall key frame placement should be.

[Sapo84]

Originally Posted by Brother John

Another point to mention: --keyint is the maximum interval. x264 will insert key frames earlier if it deems them beneficial, e.g. due to a scene change. From my experience the majority of key frames are in place because of the properties of the video, not because keyint was reached. The larger --keyint is the smaller the impact on overall key frame placement should be.

Well, the closer x264 is to the keyint value (meaning if it is encoding frame 230 when keyint is 240) and the more likely it is to insert a keyframe, probably because a keyframe at a random frame hurt compressibility much more than a suboptimal placed keyframe.
--keyint infinite and --keyint 240 may have different keyframe positioning even if the 240 frame limit is never reached.

[sirt]

Then what would recommand : infinit or 240 (in the case I exposed) ?

[Atak_Snajpera]

seeking with infinite may be slower for obvious reasons. You have to decide what works better for you.

[RRD]

Hello. I found this thread when Googling about keyint for 60fps framerate and I do not really understand.

Originally Posted by Dark Shikari

There is no reason keyint "should" be any specific value. It's just a tradeoff between seeking speed and compression. Don't muck with it.
min-keyint is automatically decided by the encoder. Don't muck with it.
As a general rule, don't mess with any options that aren't in x264 --help without extremely good reason.

↑Same person in 2008:

Originally Posted by Dark Shikari

Commandline: x264 […] --keyint 600
Keyint 600 was used because the source is 60 FPS (keyint = 10*framerate).

Originally Posted by Audionut

As a general rule of thumb, keyint should be 10x framerate, and min-keyint should be at framerate.
So for 24fps (23.976 if you want to be pedantic) material, the settings should be 240/24, not 250/23.

https://en.wikibooks.org/wiki/MeGUI/x264_Settings#keyint

Recommendation: Default, or 10x whatever your framerate is. On HD encodes which will be CPU challenging you may want to use smaller values (say 2x - 5x fps).

So if (1) I don't need Blu-ray compliance, (2) I don't care about long seeking times and (3) I have a relatively powerful CPU, what should I put for keyint with HD 60fps videos?

From what I understand: the default value --keyint 250 was arbitrarily adapted for 25fps videos, so with 60fps a --keyint 600 or even higher (--keyint 900?) may slightly improve compression while making seeking & encoding times longer. In all cases, x264 may decide to put keyframes well below the keyint value anyway.

[kuchikirukia]

MeGUI will set framerate * 10 from the default. If you use the default 250 with 60fps material, it will set 600. Setting 500 will go to 1200.

From what I've seen there are only a couple bytes difference using huge keyints. Basically at the default 10*framerate you're mostly to the point where the encoder is choosing the placement, not the keyint.

[foxyshadis]

Originally Posted by RRD

So if (1) I don't need Blu-ray compliance, (2) I don't care about long seeking times and (3) I have a relatively powerful CPU, what should I put for keyint with HD 60fps videos?

Basically the same as asking what preset to use, except it affects decoding instead of encoding. PCs and hardware decoders have become so insanely overpowered that seeking isn't even terribly impacted anymore. On the flip side, the option isn't useful unless you have lots of slow/steady scenes that are longer than 10 seconds.

I've always used 15-20 seconds, because seeking is relatively rare and I figure it'll only be used where it'll do some good anyway.

[benwaggoner]

Originally Posted by sirt

In fact it is not like I want seeking to be faster or slower. What I want to know is why it could be faster or slower (according to the type of the video) and how I could decide to change the values.

--keyint is also only one parameter that impacts random access speed. For a good decoder, larger numbers of B-frames will also improve seeking, as that increases distance between P-frames. Strictly Hierarchical Pyramid enhances this.

And some badly behaved decoders can't seek in Open GOP content worth a darn.

Speaking of which, the quality advantage of Open GOP encoding kicks in as keyint goes down, since you wind up with more IDR frames mid-shot, and Open GOP will help smooth out the transition.