Add I-frames at chapter start

[galinette69]

Is it possible to force I-frames at chapter starts using megui/x264?
I encode videos for coreplayer, and when browsing through chapters, the player goes back to the first I-frame preceeding the chapter time (which is a few seconds in my case). So you see the last seconds of the previous episode, and in my case, this is very visible and not clean.

Thanks!

Etienne

[martino]

You can modify the first pass generated x264 stats file and change the appropriate line to force an I-frame where you'd like to put a chapter.

[ToS_Maverick]

a nice feature would be, if you could specify in the commandline, where to insert i-frames, because i also thought about chapters.

wouldn't this be possible with frames?

another way would be, if you could point x264 via the commandline to a standard chapter file, where it could get the position of the chapters

[ImmortAlex]

It will be good to have this option like XviD have, in --zones option. It will be even better to have separate option or ability to load chapter file, like ToS_Maverick suggest.
I think it's easy to implement at the same place where --max-key-int is used to force key-frame.
Also I think that changing frame type in stats file is wrong idea since it contains many information about frame, not only its type.

And... where I can read some FAQ about compiling x264 on Windows-machine?

[lexor]

Doesn't x264 always put a i-frame at scene change? As I don't see why you would put a chapter anywhere in the middle of a scene, requiring a manual control of i-frame insertion seems needless. Now if x264 doesn't put an i-frame at the beginning of a new scene, I agree that something should be done about it (though I still say manual control is needless).

[Sagekilla]

Erm, I believe x264 does have a zones option: --zones. Still, it would be mighty handy to have it read a text file with the specific frames comma'd off like so: 3850,8392,15732.

[akupenguin]

Doesn't x264 always put a i-frame at scene change? As I don't see why you would put a chapter anywhere in the middle of a scene, requiring a manual control of i-frame insertion seems needless. Now if x264 doesn't put an i-frame at the beginning of a new scene, I agree that something should be done about it (though I still say manual control is needless).
What about fade-ins or blackness? You have to designate one of the frames as "the" start of the scene for a chapterlist, but there's no reason for the codec's analysis of the content to match the one you/the dvd author picked.

[ImmortAlex]

And even more example. I want to back up three movie on one DVD. They all have the same frame width/height/AR. And I want they will be the same quality and splitted on three files alone.
So I put them in one AVS at the time of encoding (2 pass of cause), get one big file and than want to break it onto three parts. Without specifing explicit I-frames I can not break it at right points, where original movies starts.
I often did such encodings using XviD. More precise, I never used zones in XviD to changing quality, but just for putting IVOPs.

Sagekilla: I know about --zones option in x264 and often use it. I just said that XviD has option for inserting I-frames in --zones, but x264 not. But I prefer I-frames option to be alone.

[lexor]

What about fade-ins or blackness? You have to designate one of the frames as "the" start of the scene for a chapterlist, but there's no reason for the codec's analysis of the content to match the one you/the dvd author picked.

Yeah, I forgot about that. When encode is somewhat bitrate starved, fade-ins start as a blocky hell that stabilizes into solid picture as the brightness goes up. Fades are a scene change though, aren't they always? I did find that initial blockiness annoying and I do wish x264 would put an i-frame as the first non-pitch-black frame, though I don't know if the first frame with visible features can be detected reliably. But you are right, as it is now, not all scene changes get i-frames as first frame.

I still say that if the first frame of scene change can be made to always be an i-frame, we don't need any manual control. Manual control would just be an extra option that people will try to abuse, more so than any other option, once they look up what i-frame means, they'll want to outsmart the encoder and try to raise PQ.

[foxyshadis]

They already do that with stats files, which for all intents and purposes are the manual control at this point.

[dma_k]

I suffer the same problem: during the navigation between chapters I want video to start playing exactly at specified position, and not from nearest key frame. The problem with injecting fake I-frames into the stat file after the 1st pass doesn't work for me, as I already have dozens of encoded videos, which I would like to add chapters to. I think
this topic (http://forum.doom9.org/showthread.php?p=988553#post988553) is about the same thing.

My main qustion is: why in 21st century players still have problems with navigation in H.264 stream? I mean, I can accept that player "thinks" for another second to locate the previous key frame, and "replay" the scene till the specified point, but not the situation, when MPC simply freezes the video for a couple of seconds while audio is playing. And the problem happens not only when navigating the chapters, but when using mouse and navigation bar... I just wonder, if there are any future solutions, at least in theory?

[TheBashar]

I'd like to be able to force I-frames at some locations to support my split & merge operations. When I put TV series on my HTPC, I like to cut out the opening credits that are the same for all episodes and join the front pre-credit part with the post credit part. Because some filters I use do not work well with Trim() and because I can't otherwise garuntee a clean break, I have to go to a lot of trouble to encode the pre and post credit sections as separate jobs. Forcing 2 iframes would be much easier to support splicing.