REQ: Custom chapters

[WhosAsking]

I am making this request because I am running into two scenarios where automatic chaptering fails:

1. The source material is something like an AVI file for which chapter information does not exist.
2. The source DVD material is a cheap or otherwise lousy DVD for which the chapter layout is very poor (or nonexistent).

In both scenarios, there is no information with which for Handbrake's automatic chaptering to work. Therefore, I wish to propose a new feature--custom chapter support. This could be supplied in a manner similar to that used for chapter titling: a CSV table that lists chapter followed by either the timecode or (I think this would be preferred for accuracy) frame number that represents the start of that chapter.

PS. If this feature has been requested before, I apologize, but none of my search efforts turned up anything.

[nightstrm]

If you're on a Mac, Subler can add custom chapters to an encode.

http://code.google.com/p/subler/

[WhosAsking]

If you're on a Mac, Subler can add custom chapters to an encode.

http://code.google.com/p/subler/

What about Windows users like me?

[nightstrm]

If you're on a Mac, Subler can add custom chapters to an encode.

http://code.google.com/p/subler/

What about Windows users like me?

No idea.

[tlindgren]

What about Windows users like me?

For MKV the standard mkvtoolnix suite includes a chapter editor (in mkvmerge), http://www.bunkus.org/videotools/mkvtoolnix/

For MP4 content it's a bit more complicated, but apparently YAMB will handle it if you have a chapter file in correct (OGG) format, this format is described in several places including the mkvtoolnix suite. http://www.doom9.org/index.html?/mp4.htm and http://yamb.unite-video.com/

Note that while all of these methods allow you to place a chapter at any place it might not work that great on less powerful players (such as set-top boxes). The problems is that all other frames you need to start at an earlier I frame to be able to decode them properly, so it either has to decode (but probably not show) all earlier frames from the previous I frame before starting to show content or seek to the next I frame instead.

I have a Popcorn hour A110 and while manual chapters often works fine it sometimes takes a while before the video start again. The reason it often works is because all video encoders tends to try to insert a I frame when they detect a "scene change" and often it makes sense to put manual chapters close to scene changes anyway On the computer seeks are always fast, it has vastly more CPU/GPU power.

If the list of chapters is known during encoding the encoder can insert an I frame at that point so the player can easily seek to it, I think at least HB+x264 does this (not used ffmpeg but it wouldn't surprise me if it does the same).

Also, don't try to get too fancy with the more advanced chapter structures allowed with mkv, I've never seen anything that can handle sub-chapters nor multiple chapter "editions" (most just ignore everything except the first "edition"). Note that mkvmerge actually generate the later if you merge two files with chapters! So to get all chapters into a format that worked I had to export it to xml, merge the "EditionEntries" (with an text editor) and then load it back into the mkv file with mkvmerge

[WhosAsking]

What about Windows users like me?

For MKV the standard mkvtoolnix suite includes a chapter editor (in mkvmerge), http://www.bunkus.org/videotools/mkvtoolnix/

For MP4 content it's a bit more complicated, but apparently YAMB will handle it if you have a chapter file in correct (OGG) format, this format is described in several places including the mkvtoolnix suite. http://www.doom9.org/index.html?/mp4.htm and http://yamb.unite-video.com/

Note that while all of these methods allow you to place a chapter at any place it might not work that great on less powerful players (such as set-top boxes). The problems is that all other frames you need to start at an earlier I frame to be able to decode them properly, so it either has to decode (but probably not show) all earlier frames from the previous I frame before starting to show content or seek to the next I frame instead.

I have a Popcorn hour A110 and while manual chapters often works fine it sometimes takes a while before the video start again. The reason it often works is because all video encoders tends to try to insert a I frame when they detect a "scene change" and often it makes sense to put manual chapters close to scene changes anyway On the computer seeks are always fast, it has vastly more CPU/GPU power.

If the list of chapters is known during encoding the encoder can insert an I frame at that point so the player can easily seek to it, I think at least HB+x264 does this (not used ffmpeg but it wouldn't surprise me if it does the same).

Also, don't try to get too fancy with the more advanced chapter structures allowed with mkv, I've never seen anything that can handle sub-chapters nor multiple chapter "editions" (most just ignore everything except the first "edition"). Note that mkvmerge actually generate the later if you merge two files with chapters! So to get all chapters into a format that worked I had to export it to xml, merge the "EditionEntries" (with an text editor) and then load it back into the mkv file with mkvmerge

Last I checked, YAMB's chaptering isn't iPod compatible. Handbrake's is. Also, when Handbrake does a chapter, it conscientiously makes sure that chapter start frame is an I-frame (chapters always start on I-frames), and I-frames aren't always a given (sometimes, chapter markers occur on fades and other non-cut transitions where I-frames aren't guaranteed). BTW, x264 (the CLI encoder itself, not the one built into HB) doesn't allow for custom I-frame insertion last time I looked.

[rhester]

x264 (the CLI encoder itself, not the one built into HB) doesn't allow for custom I-frame insertion last time I looked.

Actually, I think it does, but you have to feed it a text file indicating which frames should be forced.

Rodney

[WhosAsking]

x264 (the CLI encoder itself, not the one built into HB) doesn't allow for custom I-frame insertion last time I looked.

Actually, I think it does, but you have to feed it a text file indicating which frames should be forced.

Rodney

Interesting. That's been a feature request and one reason I wanted to keep away from vanilla x264 at the time. Everywhere I look, the only keyframe option I could find has been the ol' force keyframe gap option, which doesn't help in my case. The only kludge I could work out was to make separate encodes that I would then cat together with mp4box, but it's a right mess. Perhaps you could provide further information on this feature, because Google has not been my friend here.

[rhester]

-qpfile. It's been there for quite some time. See --longhelp for (some) details.

Rodney

[WhosAsking]

-qpfile. It's been there for quite some time. See --longhelp for (some) details.

Rodney

That? That's intended to manually fine-tune the frame types and quantizers for every single frame of the movie. From what I've read, you can't just specify a qpfile that contains a few key frames you want in a certain way and let the rest run on auto--every frame must be represented or the file fails. As for the --zones parameter, that (unlike Xvid) doesn't allow you to force a keyframe at the start of a zone. There's an unofficial patch floating around that can create keyframes for chapterpoints, but that was over a year ago, and x264 has moved on a bit since then without integrating it.

[rhester]

How on earth would x264 know what a "chapter point" even is in order to put an I-frame into one?

Rodney

[WhosAsking]

How on earth would x264 know what a "chapter point" even is in order to put an I-frame into one?

Rodney

The same way Handbrake's modified x264 core does it--you tell it in advance. Once it knows the frame number of the chapter point, it can make sure that that particular frame is to be both an I-frame and the beginning of a new GOP. These are the two qualifications for a proper MPEG-4 AVC keyframe (and chapterpoints are best done on keyframes). Now, AFAIK, HB's keyframe forcing modification has never been incorporated into the vanilla x264 builds, and there are no other elegant options for achieving the feat. There are only two I know of, and both are irksome: you can make multiple discrete encodes with frame ranges and so on and then splice them with mp4box; or you can use a qpfile that has all the frames laid out in it and then modify the keyframes as needed.

Meanwhile, HB gained more functionality with the ability to encode from sources beyond just DVDs. So now there's a possibility to solve the problem from another direction. Not to mention be able to do the same thing for some of those cheap DVDs I have that have lousy or nonexistent chaptering.

[dynaflash]

The same way Handbrake's modified x264 core does it--
...
Now, AFAIK, HB's keyframe forcing modification has never been incorporated into the vanilla x264 builds, and there are no other elegant options for achieving the feat.

Um which patch in /contribs/x264 do you think modifies our x264 lib in svn ?

[WhosAsking]

The same way Handbrake's modified x264 core does it--
...
Now, AFAIK, HB's keyframe forcing modification has never been incorporated into the vanilla x264 builds, and there are no other elegant options for achieving the feat.

Um which patch in /contribs/x264 do you think modifies our x264 lib in svn ?

I don't know how you do it internally, but you do something easily vanilla x264 doesn't, and that's insert a custom keyframe; I can see that in your CLI output (I frame inserted" and the like). There is, plain and simple, no easy way to do it with vanilla x264; I've looked...thoroughly, and since I own a Classic, it's become rather an essential for me to be able to search my movies by chapter--even if it means having to come up with my own chaptering for those movies that don't have chaptering. You may use a custom qpfile or the like, but the point is that you make simple what the vanilla program makes too complicated for practical use (I'm not an expert on GOP structure so wouldn't know how to make a custom qpfile that didn't end up looking terrible).

[jbrjake]

The same way Handbrake's modified x264 core does it--
...
Now, AFAIK, HB's keyframe forcing modification has never been incorporated into the vanilla x264 builds, and there are no other elegant options for achieving the feat.

Um which patch in /contribs/x264 do you think modifies our x264 lib in svn ?

I don't know how you do it internally, but you do something easily vanilla x264 doesn't, and that's insert a custom keyframe; I can see that in your CLI output (I frame inserted" and the like). There is, plain and simple, no easy way to do it with vanilla x264; I've looked...thoroughly

You didn't look that thoroughly. The patch HB used to use to force I-Frames was deprecated half a year ago when x264 finally implemented the same capability in its API. It most certainly is in vanilla x264 builds and it is quite easy to do with standard x264 API like so:

Code: Select all

 if( in->new_chap && job->chapter_markers )
571	    {
572	        /* chapters have to start with an IDR frame so request that this
573	           frame be coded as IDR. Since there may be up to 16 frames
574	           currently buffered in the encoder remember the timestamp so
575	           when this frame finally pops out of the encoder we'll mark
576	           its buffer as the start of a chapter. */
577	        pv->pic_in.i_type = X264_TYPE_IDR;
<snip>
585	    }
586	    else
587	    {
588	        pv->pic_in.i_type = X264_TYPE_AUTO;
589	    }

[WhosAsking]

The same way Handbrake's modified x264 core does it--
...
Now, AFAIK, HB's keyframe forcing modification has never been incorporated into the vanilla x264 builds, and there are no other elegant options for achieving the feat.

Um which patch in /contribs/x264 do you think modifies our x264 lib in svn ?

I don't know how you do it internally, but you do something easily vanilla x264 doesn't, and that's insert a custom keyframe; I can see that in your CLI output (I frame inserted" and the like). There is, plain and simple, no easy way to do it with vanilla x264; I've looked...thoroughly

You didn't look that thoroughly. The patch HB used to use to force I-Frames was deprecated half a year ago when x264 finally implemented the same capability in its API. It most certainly is in vanilla x264 builds and it is quite easy to do with standard x264 API like so:

Code: Select all

 if( in->new_chap && job->chapter_markers )
571	    {
572	        /* chapters have to start with an IDR frame so request that this
573	           frame be coded as IDR. Since there may be up to 16 frames
574	           currently buffered in the encoder remember the timestamp so
575	           when this frame finally pops out of the encoder we'll mark
576	           its buffer as the start of a chapter. */
577	        pv->pic_in.i_type = X264_TYPE_IDR;
<snip>
585	    }
586	    else
587	    {
588	        pv->pic_in.i_type = X264_TYPE_AUTO;
589	    }

Fine. My last download's a bit older than that addition. Now how do I reach this darn thing from the command line? I can't find any documentation whatsoever on the feature. And last I read, the qpfile requires an entry for every frame. Has this requirement changed to only require those frames which you want custom treatment? If it has become the case that the qpfile only need specify specific frames and not every frame, then I will concede that a suitable device exists in vanilla x264 from the command line, and I will withdraw my request.

[dynaflash]

At this point, you are best off approaching #x264 on irc or asking on doom9. This has become an x264 question and not a handbrake question. The old patch to x264 has been provided. Use of the x264 executable is a x264 issue.

[WhosAsking]

At this point, you are best off approaching #x264 on irc or asking on doom9. This has become an x264 question and not a handbrake question. The old patch to x264 has been provided. Use of the x264 executable is a x264 issue.

The qpfile has been simplified and no longer requires a line for every frame. This enables me to set IDR frames at will and is now a satisfactory solution. My request is hereby withdrawn.