Forcing keyframe with x264

[[Toff]]

Hi,
I was wondering if there is any tool to force keyframes at specified position when encoding with x264 ?
Ideally those frame position would be stored in a simple text file as a list of timestamps.

If there is no such a tool, would it be correct to modify the stats file by just changing the frame type to "I" ?

[foxyshadis]

Stats files are reinterpreted on the second pass, they're only guides, not rules. (In fact, you'll notice it swaps p and b decisions constantly.)

Have you tested zones? I can't recall whether they start on keyframes or not.

[Guess I was entirely wrong here, ignore.]

[akupenguin]

Yes, you can modify the statsfile, and it will use your modified frame types. Though if you do that too much, the 2nd pass will think that those I-frames are cheap, and could confuse bit allocation. (If this is a problem, a 3rd pass will fix it)
Zones do not force keyframes.
libx264 does have an interface to force frametypes of some frames during the 1st pass, but none of the frontends do so.

[charleski]

This would be quite useful: seeking in mp4s seems to be heavily dependent on I-frames, more so than in mp2 or ASP. Getting frame-accurate chapters requires being able to specify I-frames as well, doesn't it? (I haven't played around in chapters in x264 streams).

[bond]

This would be quite useful: seeking in mp4s seems to be heavily dependent on I-frames, more so than in mp2 or ASP. seeking is always dependant on i-frames, cause you can only seek to i-frames in any container (and than seek to the frame you want)
how good frame-accurate seeking is done depends on the parser

Getting frame-accurate chapters requires being able to specify I-frames as well, doesn't it? (I haven't played around in chapters in x264 streams). having chapterpoints as keyframes definitely helps with weak parsers. normally chapters are at scenechanges so they are i-frames anyways normally

but being able to force idr-frames (not i-frames) at chapterpoints would be a nice thing imho

[Manao]

seeking in mp4s seems to be heavily dependent on I-frames, more so than in mp2 or ASP.Not really, but almost all mpeg2 have a 15-frames GOP, and ASP is faster to decode ( hence, seeking to the end of a GOP is fast, 4 or 5 times faster than h264 i'd say )

[charleski]

According to a white paper published by Conexant, the real issue is 'trick-play' modes - fast forward and reverse. In MPEG-2 this can be done by dimply decoding and decimating. As the speed increases you can fall back to decoding only I and P frames, and then decoding I frames only at the fastest speeds. Since any frame can be a reference in AVC, you can't use the same tricks (such as simply discarding B frames) that you can in earlier formats.

Trying this out in Nero Showtime, a file that plays with a CPU load of 40% reduces to a nasty slideshow at any speed higher than 2x. it would be nice to have the option to trade-off filesize against seekability.

[[Toff]]

Well i've tried to make something.
If someone is interested the code is here (feel free to use it) :
http://www.matroska.org/~toff/x264.c
I've added a new parameter --forcekf <file>
The file must be in the format :
format=1
4054
10230
or
format=2
fps=25.0
00:10:36.096
00:24:21.778

Though, it doesn't works with adaptive bframes which is enabled by default.

[stephanV]

According to a white paper published by Conexant, the real issue is 'trick-play' modes - fast forward and reverse. In MPEG-2 this can be done by dimply decoding and decimating. As the speed increases you can fall back to decoding only I and P frames, and then decoding I frames only at the fastest speeds. Since any frame can be a reference in AVC, you can't use the same tricks (such as simply discarding B frames) that you can in earlier formats.

This can also be done with h264. I can't think of any case where a b-frame would be used as reference for a p-frame, so all b-frames can be discarded when seeking. Skipping p-frames with seeking would be useless unles you have a really bad seeking mechanism. If you are seeking, you normally start decoding with the closest, previous I-frame. Anything else would be weird.

h264 requires just a lot more power to decode, hence the slower seeking.

Reverse play (and to a lesser extend FF) issues are just the cause of the GOP-size, Which normally is 10 to 20x higher in AVC. So if you want better seekability, you shouldn't insert key frames at random, but just narrow the key frame distance.

[Manao]

stephanV : you can create streams with only i & bframes. bframes can reference two past frames.

[bond]

']Well i've tried to make something.
If someone is interested the code is here (feel free to use it) :
http://www.matroska.org/~toff/x264.c
I've added a new parameter --forcekf <file>
The file must be in the format :
format=1
4054
10230
or
format=2
fps=25.0
00:10:36.096
00:24:21.778

Though, it doesn't works with adaptive bframes which is enabled by default.wouldnt it be better to integrate this into the zones option, like xvid does it?

[stephanV]

stephanV : you can create streams with only i & bframes. bframes can reference two past frames.
In which case you could still skip all b-frames when seeking. :p

You just could never seek to a b-frame though...

But is such a scenario a real motivation to not allow to seek with skipping b-frames?

[charleski]

After doing a few tests, current players don't seem to be able to handle decimation in AVC files at all. This means the only way they can fast-forward is either by simply decoding everything and then speeding up or by skipping along the IDRframes. Rewind is even worse, libavcodec (Nov 3 build) simply crashes after skipping back a few GOPs. Showtime handles it without crashing, but is just doing an IDR slideshow. So yeah, you're probably better-off just decreasing the keyint to get better seekability. Forcing IDR frames at chapter stops is vital.

Obviously these issues are pretty relevant to the industry, since consumers will expect good-quality trick-mode play etc after having become used to it in MPEG2. Any rumours of how they're dealing with it? (It may be that they'll just fall back on saying that the first-gen players won't be able to do trick-modes that well :/.)