HandBrake

Can someone please explain to me how capture structure work in an H.264 encoded file for an iPod/iPhone?
Such as documentation on how it is stored in the actual files.
Is it stored in the ATOM structure of the file? or am I mistaken on this?


Greg Caulder

Fully documented in Apple's technotes.

Rodney

It is plan to have pictures associated with chapters on the next version ?

Not that I've read or heard.

Rodney

Colonel.Cool wrote:It is plan to have pictures associated with chapters on the next version ?

I assume you mean where there is a thumbnail for each chapter. No, no plan to whatsoever.

rhester wrote:Fully documented in Apple's technotes.

Rodney

And can you post back the link to the exact documentation, I looked but I don't find the exact info that I'm looking for.

Specifically for creation of chapters.

G

Sample code from Apple:

http://developer.apple.com/samplecode/q ... ing14.html

Unfortunately, it's a little (OK, a lot) QuickTime API-centric, so a better example is probably HandBrake's own source code or the libquicktime source code (that does handle chapter tracks).

Long story short, chapter tracks are timed text tracks synchronized with the first audio track. They are not atoms and are considerably more difficult to implement. To date, nobody has managed to do so post-mux outside of Apple.

(Moving thread to Development as this has nothing to do with the Windows port of HandBrake.)

Rodney

rhester wrote:Sample code from Apple:

http://developer.apple.com/samplecode/q ... ing14.html

Unfortunately, it's a little (OK, a lot) QuickTime API-centric, so a better example is probably HandBrake's own source code or the libquicktime source code (that does handle chapter tracks).

Long story short, chapter tracks are timed text tracks synchronized with the first audio track. They are not atoms and are considerably more difficult to implement. To date, nobody has managed to do so post-mux outside of Apple.

(Moving thread to Development as this has nothing to do with the Windows port of HandBrake.)

Rodney

Thanks for the info.

What source file or section in the source does the encoding of the chapters? IF you could email me the document and tell me what file to look it, that would help out a lot.

Greg

gregcaulder wrote:What source file or section in the source does the encoding of the chapters? IF you could email me the document and tell me what file to look it, that would help out a lot.

It's not that easy...

There are several different components, and most of them are in different source files
- Grabbing chapter marks from the DVD ifo. (I'd imagine dvd, read, or scan.c)
- Locating those times in the actual video and adjusting them to match up with keyframes. (read or dvd.c ?)
- Adjusting the times in response to features like b-frames and VFR. (render and muxmp4.c)
- Correcting the frame-type decisions of the encoder. (encx264.c)
- Interleaving text-track samples into the mux. (muxmp4.c)

...and after reading all that you'll realize it's mere implementation and the hard part is handled through patches to the mp4 muxing library.

You also can't look at a single revision -- there have been, like, a dozen different changes since Cyander's first commit.

jbrjake wrote: There are several different components, and most of them are in different source files
- Grabbing chapter marks from the DVD ifo. (I'd imagine dvd, read, or scan.c)
- Locating those times in the actual video and adjusting them to match up with keyframes. (read or dvd.c ?)
- Adjusting the times in response to features like b-frames and VFR. (render and muxmp4.c)
- Correcting the frame-type decisions of the encoder. (encx264.c)
- Interleaving text-track samples into the mux. (muxmp4.c)

Actually, I think adjusting them to match the keyframes is done during decode, since that is when the MPEG-2 frame type becomes available.

jbrjake wrote: ...and after reading all that you'll realize it's mere implementation and the hard part is handled through patches to the mp4 muxing library.

For the lifting and adding the samples yeah, but I would say that the pipeline of carrying around this breaks is tricky to get right, especially with how many fixes it needed after I thought I had gotten the worst of the behavior fixed. So it depends on how you define hard.