Handbrake reaches 1.0.0 milestone after 13 years of development

handbrake_logoChristmas creates a different focus for the average IT guy, spending time with family instead of computers. It was nice. But it’s over and done now, even though the Christmas tree in the corner of our living room is still on fire (metaphorically speaking).

Tonight I have time to write about the latest Handbrake release. It took the developer team “only” 13 years to reach the stable milestone, 1.0.0. Congratulations are appropriate, because it is great software. But still there’s that nagging thought at the back of my mind… why the fuck is its GUI depending on a recent GTK+3 and therefore almost enforcing the use  of a Gnome-based distro? GTK has always been a moving target, theoretically separate from Gnome but in all honesty, the two are bonded with superglue. I can not compile Handbrake for Slackware 14.1 or older, and this GTK crap does not lend itself for static compilation inside the handbrake package. There now, I vomited a little. Why the fuck did they drop the Qt-based GUI? People can make bad decisions out of habit… this was definitely one.
I think we must be glad that we can compile the GUI for Handbrake 1.0.0 at all on Slackware 14.2.

By the way, compiling the command-line version of Handbrake is possible, even on Slackware 14.1 because that does not require GTK+3 as a dependency (although it depends on a lot of other X libraries on Slackware… i.e. the command-line program is unusable on a headless server without X.Org and friends installed).

Enjoy the new Handbrake!

handbrake-1.0.0

Packages for Slackware 14.2 and -current can be obtained from my “restricted” repository. Handbrake employs some software libraries that are under patent dispute (the MP3 and AAC audio encoders) so I can not host the package on the Slackware server in the US. The regular repository does have a handbrake directory but that hosts only the scripts, sources and patches, not the Slackware packages.

Get them here:

Eric

27 thoughts on “Handbrake reaches 1.0.0 milestone after 13 years of development


  1. Addendum: only caveat, overheating here while ripping (97°C) It starts many threads at once, uses a lot of CPU.

    This is on quad core, so hardinfo reports four lines like this:
    Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz 3137,00MHz





  2. The gentoo patch is not relevant for my package.
    The other patches in the Arch handbrake package are not official patches, they are git commits that address a *potential* crash.

    If someone tells me he experiences that particular crash scenario while using my handbrake package, I will apply those two commits as patches to my package.



  3. @steve: this is debatable. Qt4 weighs 470M uncompressed in Slackware (and this doesn’t includes the docs and the demos), GTK+2 53M and GTK+3 67M, thus not all distributions ship Qt in their ISOs. Maybe this was considered in the decision?


  4. That is a bogus argument. Because not all distros ship Qt, let’s drop the Qt interface?
    Also, I highly doubt that the added bytes for a Qt GUI are 8 times the size of a GTK interface layer. Since when does size matter in this online world anyway?


  5. Well, I stand corrected. About the size of Qt4, I see now that I had read it on /var/log/packages but I had rebuilt this package including all docs and the demos. The genuine 64-bit Slackware package weighs just 133420 K installed, according to PACKAGES.TXT Sorry for the noise.



  6. 1.0.1

    VIDEO CHANGELOG

    Fixed a potential crash when using the VP8 or VP9 video encoders
    Fixed a potential crash when using 2-pass ABR


  7. So if I read correct, only 2 patches that are being used are official, or all that’s needed, and the other 4 aren’t needed?

    Also I don’t understand why the empty ‘contrib’ directory?

    Thank you



  8. Sorry I thought what I was saying was clear.

    Actually including diff you have 7 patches and only 3 are being used, these are all I see being used;

    handbrake.static_modules.patch
    handbrake.libdvdread_automake.patch
    handbrake.fribidi_autoconf.patch

    So the directory /gtk and /contrib I assume can be deleted?

    Also these are not being used and can be deleted?

    libffi.includedir.diff
    pango.etc.host.location.diff
    handbrake.fribidi_dso.patch

    Thank you



  9. It’s my understanding these are just your own personal slackbuilds, not like official, or like slackbuilds.org.

    Bothering me is not the concern, I was just trying to figure out if you were still working on this slackbuild, and maybe the reason I was seeing this, is it’s not completed is all…

    So I was only asking if it was ok to remove these and you were done with the slackbuild and they are not needed?

    thank you


  10. Whenever I upload a package and its sources/scripts, I am done working on them and the scripts that I publish will produce the package I uploaded.

    It is no different situation with the handbrake.SlackBuild. The script will use some, not all of the patches in the build/ directory. I don’t understand why you are so obsessed with the other, no longer used, patches which I kept for historical purposes in case someone needs to compile an older version of handbrake. Note that my repository does not just contain a handbrake 1.0.0 package but if you look inside the Slackware directories for 14.1 and older you will find handbrake-0.9.9 packages which require other patches than 1.0.0.


  11. I’m not obsessed or bothered, as I said, I was only trying to figure out why I was just seeing what I was seeing is all.

    Anyhow, you have made it clear now…

    Thanks


  12. I have uploaded a handbrake 1.0.1 package to the restricted repository. For proper form I also added two patches that I am not using in the SlackBuild.

    Hopefully the new package fixes the crashes people report on LQ when trying to access DVD media.


  13. Thanks Eric!
    Right on time (as I was thinking about installing Handbrake ;).

    However, the preview doesn’t work for me, it’s complaining about missing GStreamer h.264 and AAC decoders. I have a full Slackware64 14.2 install. I have the following GStreamer packages installed:
    gst-plugins-bad-1.6.2-x86_64-2_SBo
    gst-plugins-base0-0.10.36-x86_64-2
    gst-plugins-base0-compat32-0.10.36-x86_64-2compat32
    gst-plugins-base-1.6.4-x86_64-1
    gst-plugins-base-compat32-1.6.4-x86_64-1compat32
    gst-plugins-good0-0.10.31-x86_64-2
    gst-plugins-good0-compat32-0.10.31-x86_64-2compat32
    gst-plugins-good-1.6.4-x86_64-1
    gst-plugins-good-compat32-1.6.4-x86_64-1compat32
    gst-plugins-ugly-1.6.2-x86_64-1_SBo
    gst-python-1.6.2-x86_64-1_SBo
    gstreamer0-0.10.36-x86_64-1
    gstreamer0-compat32-0.10.36-x86_64-1compat32
    gstreamer-1.6.4-x86_64-1
    gstreamer-compat32-1.6.4-x86_64-1compat32



  14. The dependency of a command-line utility on X11 drives me nuts too. Have you noticed that the ‘sox’, ie, ‘play’ command now can’t be used without X, thanks to pulseaudio?



  15. tesloid: furthermore, running ./configure –help in the source archive of pulseaudio-9.0 I saw this option:
    –disable-x11 Disable optional X11 support
    So there is no dependency on X of the server itself.


  16. “I can not compile Handbrake for Slackware 14.1 or older, and this GTK crap does not lend itself for static compilation inside the handbrake package.”

    I’m just wondering: given that Slackware 14.1 has gtk+3 (v3.8.2), is the specific problem that this version of gtk+3 is too old? Or is there a gnome-specific dependency somewhere? (From what you write, the problem would seem to be gtk+3.)



Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.