Page 1 of 1

[DOC] HandBrake Architectural Guide

Posted: Mon May 24, 2010 6:50 am
by davidfstr
I've written up all of my notes that I took while learning HandBrake. I imagine they will assist new would-be contributors to the project. May also be useful reference for regulars. Embedded links: See any errors?

What would be the best way to post this? Convert to Trac?

Re: [DOC] HandBrake Architectural Guide

Posted: Mon May 24, 2010 6:55 am
by s55
Source Code Layout:

* build/
o contrib/ (External libraries that HB depends on)
* gtk/ (Windows GUI)
* libhb/ (HandBrake Core)
* macosx/ (Mac GUI)
* qt4/ (Linux GUI)
* test/ (Command Line Interface)
WinGui is in the Win/C# Folder, not GTK.
GTK is the Linux GUI
GT4 is an abandoned Linux GUI that hasn't been updated in a very long time.

Re: [DOC] HandBrake Architectural Guide

Posted: Mon May 24, 2010 2:36 pm
by jbrjake
Wow, nice. Yes, this should go in the Trac, on this page: http://trac.handbrake.fr/wiki/HandBrakeDesign

Adding new Trac users might still be broken, though, so it might have to go through an existing user.

Re: [DOC] HandBrake Architectural Guide

Posted: Mon May 24, 2010 2:57 pm
by JohnAStebbins
1/90000 sec ticks were chosen because this is the timebase defined by the mpeg spec for timestamps in program streams and handbrake was originally only for transcoding DVD's which are program streams.

Thanks for the docs :D

Re: [DOC] HandBrake Architectural Guide

Posted: Mon May 24, 2010 3:03 pm
by dynaflash
wow, nice. I also like it. Especially the pic of the hand written notes !

Re: [DOC] HandBrake Architectural Guide

Posted: Tue May 25, 2010 1:58 am
by eddyg
Good stuff, thanks for that.

As for libsamplerate - it's used (no big surprise here) for changing the sample rate of the audio :)

This is when the input sample rate (in khz) is different to what you need it in the output, I use it to upsample flash video audio for kids snippets from 22Khz up to 48Khz, which (to my ear) sounds better due to some clever interpolation that libsamplerate does.

Cheers, Ed.

Re: [DOC] HandBrake Architectural Guide

Posted: Tue May 25, 2010 4:43 am
by davidfstr
s55 wrote: WinGui is in the Win/C# Folder, not GTK.
Well now I feel sheepish. For some reason my copy of the source that I use for browsing didn't have the win/ directory checked out. :roll:
JohnAStebbins wrote:1/90000 sec ticks were chosen because this is the timebase defined by the mpeg spec for timestamps in program streams and handbrake was originally only for transcoding DVD's which are program streams.
Updated.
eddyg wrote:As for libsamplerate - it's used (no big surprise here) for changing the sample rate of the audio :)
Updated.
jbrjake wrote:Wow, nice. Yes, this should go in the Trac, on this page: http://trac.handbrake.fr/wiki/HandBrakeDesign

Adding new Trac users might still be broken, though, so it might have to go through an existing user.
Trac is broke? Would be cool to fix it, as I wouldn't be able to directly update any docs I create when they (inevitably) become out of date.

Re: [DOC] HandBrake Architectural Guide

Posted: Wed Jun 02, 2010 7:21 am
by davidfstr
Have Trac access now. (Thanks jbrjake!)

So I'll work on integrating this into the Trac in the next day or two.

Re: [DOC] HandBrake Architectural Guide

Posted: Thu Jun 03, 2010 7:55 am
by davidfstr
Finished converted the guide to Trac. After a good 2 hours of work...

Reachable via: A tad deep. Would it make sense to surface this directly on the "Technical Documents" page?
Update: Nah. It's probably fine.

Re: [DOC] HandBrake Architectural Guide

Posted: Sat Jun 05, 2010 12:35 am
by Deleted User 11865
Minor issue I noticed: http://trac.handbrake.fr/wiki/HandBrake ... VIMicrooft

cfr means constant framerate, not constant bitrate (and AVI requires constant framerate).

Unless that's also part of what should amuse us? :-)

Re: [DOC] HandBrake Architectural Guide

Posted: Sat Jun 05, 2010 10:31 pm
by davidfstr
Rodeo wrote:cfr means constant framerate, not constant bitrate (and AVI requires constant framerate).
Fixed.
Rodeo wrote:Unless that's also part of what should amuse us? :-)
Hehe. Speaking of amusements, I'll be adding some actual excerpts from the code soon - to cater to our users who wouldn't otherwise look.