HandBrake - the "perfect" choice for Linux?

[GLUBSCH]

Greetings to you, folks!

Many people have recommended HandBrake (www.handbrake.fr) as a very good choice for Linux systems.
I´m using OpenSuse (because it abolutely rocks!) and have been recommended to use HandBrake for ripping and encoding as well.
Of course I did try several other good console based tools like h264enc to achive an excellent quality rip, but I somehow got addicted to HandBrake (hopefully developers will include a feature to directly back up VOBs to hard disc)...

To find my PERSONAL "perfect solution" I´m looking for other applications to try: Which other rippers/encoders are around that are cnsidered/proven to be further ahaed ("better") in quality and maintanance than HandBrake? :)

[microchip8]

Quality depends on the encoder options you use. Since HB uses libavcodec which comes from ffmpeg and libx264, it can't really outperform other encoders that use it too. If you use *exactly* the same options, once in HB and once in ffmpeg or mencoder, you'll get *very* similar result (if virtually the same)

you will find your "perfect solution" and quality after you do tests on your own and determine what looks good to *you*. There's no magical setting that will give a quality that looks "perfect" to all

[GLUBSCH]

Thanks for pointing this out. I´m still looking forward for HB to support Blu-Ray and HD-TV encoding one day.
If you are the owner of the repository in your signature, you´re the allmighty microchip8 of OpenSuse. ;) Other opinions are welcome.

[microchip8]

Yes, I'm microchip8 on openSUSE forum ;)

Bluray support will come to MPlayer soon. There's currently a guy implementing it and asking a lot of questions, both on the mailing list and on #mplayerdev IRC channel. I'm not sure how it'll get implemented (built-in for MPlayer only or if he'll move some important stuff to a library one can use for other players/encoders)

[Dark Shikari]

Quality depends on the encoder options you use. Since HB uses libavcodec which comes from ffmpeg and libx264No it doesn't, it uses x264 directly.

[microchip8]

No it doesn't, it uses x264 directly.

Still, the result is the same, no?

[GLUBSCH]

Interesting point. Sadly HandBrake only uses the x264 it brings with it and not the external one. This might be due to the developers so they know that the internal x264 works with HandBrake. They couldn´t provide support for any extern verion. Which one of those two would you expect to be the more advanced tool in the future? As for me, it certainly seems like HandBrake is more ahaed in its development than MEncoder...

[nm]

MEncoder has many video and audio filters that HandBrake still lacks, and it's somewhat more tweakable through the command line. MPlayer/MEncoder has gained a lot of functionality during a decade of development and many talented people have worked on it, along with FFmpeg. However, MEncoder is built for AVI output and it would probably need to be redesigned to fully support modern containers. I expect MEncoder to be replaced by ffmpeg and other libav* frontends as soon as libavfilter gets committed to mainline FFmpeg and some useful MEncoder or AviSynth filters are ported to it. HandBrake(CLI) has lots of potential too, and it's delightfully easy to use.

[microchip8]

Interesting point. Sadly HandBrake only uses the x264 it brings with it and not the external one. This might be due to the developers so they know that the internal x264 works with HandBrake. They couldn´t provide support for any extern verion. Which one of those two would you expect to be the more advanced tool in the future? As for me, it certainly seems like HandBrake is more ahaed in its development than MEncoder...

MEncoder's development is virtually dead and unless someone rewrites it and brings it into the 21st century, it has a poor future ahead which is really really sad. HB itself is (more of) a frontend than a encoder, eg it does not itself do the encoding but uses libavcodec and x264 for that, which do the real work so it cannot be "more advanced" than them as it depends on what they offer

[microchip8]

I expect MEncoder to be replaced by ffmpeg and other libav* frontends as soon as libavfilter gets committed to mainline FFmpeg and some useful MEncoder or AviSynth filters are ported to it. HandBrake(CLI) has lots of potential too, and it's delightfully easy to use.

ffmpeg still lacks direct reading from DVD and decryption of them which is the biggest issue I have with it. And don't get me started on the stupid way one passes options to it... -option -value +option2 -value2 +option3 +value1+value2+value3 ... :p

[Selur]

yup, ffmpegs lack of filters and DVD input really is the main bummer for me too. :)

[GLUBSCH]

ffmpeg still lacks direct reading from DVD and decryption of them which is the biggest issue I have with it. And don't get me started on the stupid way one passes options to it... -option -value +option2 -value2 +option3 +value1+value2+value3 ... :p

Just a small hint here: HandBrake uses libdvdcss to access an encrypted DVD if it is installed on your system (please gather further information about the legality in your country BEFORE using it). As for me, HandBrake clearly lacks ONE thing: The possibility to back up VOBs to the hard drive. Many other encoders are able to do so - but why the hell not HandBrake?

Anyhow, which tool do you recommend for Linux to back up those VOBs in the first place? See, I prefer to back up the VOBs completely, merge them and then encode as HandBrake doesn´t have to access the DVD drive all the time and scratch around on the DVDs.
Hey, a simple command to accomplish this task via console would do. :)

[multimediaman]

Anyhow, which tool do you recommend for Linux to back up those VOBs in the first place? See, I prefer to back up the VOBs completely, merge them and then encode as HandBrake doesn´t have to access the DVD drive all the time and scratch around on the DVDs.
Hey, a simple command to accomplish this task via console would do. :)

How about vobcopy (further information in stickies) ;)

[nm]

Anyhow, which tool do you recommend for Linux to back up those VOBs in the first place? See, I prefer to back up the VOBs completely, merge them and then encode as HandBrake doesn´t have to access the DVD drive all the time and scratch around on the DVDs.
If the disc doesn't have additional copy protection schemes (ARccOS, RipGuard, ...), you can simply copy the VIDEO_TS directory to a hard drive. Or dump the whole disc image with "dd if=/dev/dvd of=image.iso". HandBrake handles both as DVD input.

If a copy protection scheme prevents this, you'll need to run some Windows-based DVD ripping tool with Wine.

[microchip8]

Just a small hint here: HandBrake uses libdvdcss to access an encrypted DVD if it is installed on your system

And so does MEncoder and MPlayer, albeit internally so no need to install libdvdcss for it. I don't know what's your point here

[GLUBSCH]

How about vobcopy (further information in stickies) ;)

Thanks, that´s truly what I was looking for.

[nm]

Note that vobcopy doesn't work around extra copy protection either (only CSS), so for HandBrake input, it's the same as simply copying the files over.

[GLUBSCH]

Note that vobcopy doesn't work around extra copy protection either (only CSS), so for HandBrake input, it's the same as simply copying the files over.
Simply because there doesn´t exist such software for Linux. Running apps design for win would probably help out.

[Major_Kong]

Simply because there doesn´t exist such software for Linux. Running apps design for win would probably help out.

Or 'windows minded' linux devs building new software.

[GLUBSCH]

For example... (please insert applications here).

[JohnAStebbins]

HandBrake has one feature that few (if any) other open source transcoders have. It creates variable frame rate video. Most DVD sources (especially those with CGI sequences) are innately VFR. "Babylon 5" is a prime example. Producing a video that plays smoothly and maintains audio sync from such sources seems to be challenging for other encoders.

Regarding copying VOBS, that's not planned for HandBrake. HandBrake has a pretty small number of developers. We make a conscious effort to keep the feature set focused and prune out the cruft that would add maintenance overhead.

[microchip8]

HandBrake has one feature that few (if any) other open source transcoders have. It creates variable frame rate video. Most DVD sources (especially those with CGI sequences) are innately VFR. "Babylon 5" is a prime example. Producing a video that plays smoothly and maintains audio sync from such sources seems to be challenging for other encoders.

Regarding copying VOBS, that's not planned for HandBrake. HandBrake has a pretty small number of developers. We make a conscious effort to keep the feature set focused and prune out the cruft that would add maintenance overhead.

You a HB dev? :)

if so, may I ask why HB devs refuse to add quality-based Vorbis encoding?

About VFR, yes its tough to do it but personally I don't care for VFR so if an encoder doesn't offer it, it doesn't really matter to me.

PS: the decomb filter is pretty sweet though. I wish MEncoder had it too

[Major_Kong]

For example... (please insert applications here).

Something like MeGui or, as we're talking about copying dvds, something like DVDdecrypter would be useful... basically stuff to make things a little bit easier.
I could be completely wrong here, as i'm not an old linux user, but linux devs and most linux users strike me as having too high of a tolerance to solutions that in a way suffice but in another way are somewhat lacking.

[JohnAStebbins]

You a HB dev? :)
if so, may I ask why HB devs refuse to add quality-based Vorbis encoding?


You make it sound like we have an obligation to jump at every feature request that users dream up. I feel no such obligation. Speaking for myself, I code things that I have a personal interest in. I'm sure it's much the same for the other developers. None of the regular developers has been interested enough to spend the time on quality based vorbis encoding. An interested user started working on a patch and I spent a good bit of time coaching him through it: HandBrake forum thred (http://forum.handbrake.fr/viewtopic.php?f=26&t=8440&p=57438&hilit=vorbis#p57438). But then they vanished without a trace.

[stax76]

may I ask why HB devs refuse to add quality-based Vorbis encoding?

Because they are Mac users and only Linux users use Vorbis?

[JohnAStebbins]

Because they are Mac users and only Linux users use Vorbis?

That's a more compact way of saying it :)
I'm the one and only linux handbrake dev. And I prefer to pass through the original AC3 or DTS audio, so I don't have much use for vorbis. I used to use vorbis for my CD collection, but flac is better for that now. So for me anyway, vorbis is pretty pointless.

[microchip8]

Because they are Mac users and only Linux users use Vorbis?

lolwut? And Mac users don't use Vorbis? Sure, most don't but I bet my $$ on that some do

@John

No need to be so hostile ;)
It was just a question as I wondered why it doesn't support it (yet)

For example, I also don't use Vorbis for encoding (prefer AAC myself) but my scripts support it and if a user comes with a feature request, I'll usually do it if it's possible and makes sense to me ;)

and guess what? My users DO use quality-based Vorbis ;)

[JohnAStebbins]

No need to be so hostile ;)
It was just a question as I wondered why it doesn't support it (yet)
Honestly, I was just having a little fun by using the same tone that the question was presented in. "may I ask why HB devs refuse" is a pretty inflammatory way to start a question. Figured someone who dishes it out could take it.

[microchip8]

Honestly, I was just having a little fun by using the same tone that the question was presented in. "may I ask why HB devs refuse" is a pretty inflammatory way to start a question. Figured someone who dishes it out could take it.

I wrote it like that because a while ago one of my users said to me that he asked for this and was met with hostility by the HB devs, so I figured it hasn't changed much since then ;)

Those were his words "HB devs refuse to add quality-based Vorbis encoding and so I won't use HB at all"

[JohnAStebbins]

I wrote it like that because a while ago one of my users said to me that he asked for this and was met with hostility by the HB devs, so I figured it hasn't changed much since then ;)

Those were his words "HB devs refuse to add quality-based Vorbis encoding and so I won't use HB at all"

*shrug* some users need better fire retardant clothing. As far as I can remember, every request for this particular feature has been met with a "Patches are welcome" response. Usually the user then gets huffy and demands a reason for our "refusal" to implement it ourselves. They don't really want to hear the answers. They just want to vent and argue.

[microchip8]

Yep, it's perfectly possible. That's why I asked more clarity from a HB dev in the first place. Oh well, you can't really satisfy all users. That's impossible

[GLUBSCH]

@John: THANK YOU for putting your effort into coding such a great tool. I LOVE IT! :)

Considering that HB has a huge load of features right now, its das that the "expected" feature of copying VOBs won´t be supported.
Anyways, I´ve been reading through the whole sub-forum for decrypting and as it seems, that all these programs are coded for win. NOTHING equivalent exists for Linux. Certainly using those decrypters through WINE would be an "option" - I prefer to use true linux applications though. And here comes my tricky question: Are there any other libraries than libdvdcss that might work together with HB to challenge newer copy protections than CSS?

[JohnAStebbins]

And here comes the tricky question: Are there any other libraries than libdvdcss that might work together with HB to challenge newer copy protections than CSS?

I added libdvdnav support to handbrake a while back. It handles most dvd obfuscation techniques like ARccOS just fine. It's not available in a regular release yet. But if you use our development snapshot (announcement (http://forum.handbrake.fr/viewtopic.php?f=6&t=12009)), you can enable the feature in the advanced preferences.

[GLUBSCH]

Whoa, thats a quality reply. Great to hear an honest answer - I actually expected something lame... Currently I´m using SVN (rev2773) with LinGUI compiled by pbleser of the OpenSuse forums. :) Hey, "JohnAStebbins" - whoever you are, ENJOY your weekend!

[microchip8]

libdvdnav has been supported by mencoder/mplayer for a long time, just FYI

[GLUBSCH]

Thanks your hint. As I couldn´t find how libdvdnav differs from libdvdread, please tell me...
(You´re allowed to post a link to further information as well though.)

[microchip8]

dvdnav supports menu navigation while dvdread provides the functionality to read/access DVDs, just google it or head to wiki

[GLUBSCH]

Let me get this straight: Does that mean that it´s possible to fully copy a DVDs menue? Are you talking about THIS (http://forum.handbrake.fr/viewtopic.php?f=4&t=10474) wiki?

[microchip8]

I don't know what you can or can't copy with it, but dvdnav is used for menu navigation. Without it, you'll manually have to find out the movie title. With it, it just gives you the DVD menu and you click on start and off you go. If you copy a DVD 1:1 (either dump to VIDEO_TS or make an ISO out of it) the menu is still there, unless you somehow strip it off. It also supports decryption. It is primarily a DVD navigation library http://dvd.sourceforge.net/

[GLUBSCH]

I don't know what you can or can't copy with it, but dvdnav is used for menu navigation. Without it, you'll manually have to find out the movie title. With it, it just gives you the DVD menu and you click on start and off you go. If you copy a DVD 1:1 (either dump to VIDEO_TS or make an ISO out of it) the menu is still there, unless you somehow strip it off. It also supports decryption. It is primarily a DVD navigation library http://dvd.sourceforge.net/
Interesting. I wonder if HandBrake still uses lidvdcss after aktivating dvdnav... let´s try. It probably won´t disable anything.

[GLUBSCH]

Installed is libdvdnav4 - but obviously HB quits encoding at 4%. Result is crap.
When browsing I discovered that HB expected a "NAV packet", but none was found. Whats the reason behind it here?

[microchip8]

a bug...

[JohnAStebbins]

dvdnav is more than just menu support. The dvd specification includes a small virtual machine that allows simple navigation and control scripts to be run while playing a disc. dvdread ignores these instructions and reads the disc strictly according to the layout defined in the ifo files. dvd obfuscation methods like ARccOS use the vm to modify the playback sequence which makes dvdread fail to play a disc in the same way that a real dvd player would. dvdnav executes the instructions and plays the dvd like a real player would.

Handbrake does not preserve dvd menus. We are using dvdnav to read the disc in the proper sequence.

[JohnAStebbins]

Installed is libdvdnav4 - but obviously HB quits encoding at 4%. Result is crap.


If your handbrake binary was built according to our build instructions, then you should not need to install libdvdnav separately. It should be statically linked in the binary. If it wasn't built according to our instructions, then you're likely to have any manner of problems that don't exist in our official builds. We have local patches we apply to many of the libraries we use (libdvdnav has several patches we apply).

[GLUBSCH]

dvdnav is more than just menu support. The dvd specification includes a small virtual machine that allows simple navigation and control scripts to be run while playing a disc. dvdread ignores these instructions and reads the disc strictly according to the layout defined in the ifo files. dvd obfuscation methods like ARccOS use the vm to modify the playback sequence which makes dvdread fail to play a disc in the same way that a real dvd player would. dvdnav executes the instructions and plays the dvd like a real player would.

Handbrake does not preserve dvd menus. We are using dvdnav to read the disc in the proper sequence.

Good to hear. Still, when using libdvdread everything seems to work fine. Enabling the new dvdnav-feature makes HB stop encoding at 4%... :mad:
I´ll contact the packman team later today.

[JohnAStebbins]

GLUBSCH,I was curious, so I downloaded and inspected the rpm from http://packman.links2linux.org/package/handbrake which appears to be the packages built by pbleser for suse. It looks like they are linked correctly, so installing libdvdnav separately is unnecessary. I don't know why you would be having a problem. Your welcome to report it on the handbrake forums. Be sure to include an activity log so we can see exactly what you were attempting.

[JohnAStebbins]

GLUBSCH, were you getting errors like the following in the activity log with that dvd that failed when using dvdnav?

[12:12:54] dvdnav: Read Error, Error reading NAV packet.
[12:13:08] dvdnav: Read Error, Error reading from DVD.


If so, I know exactly why it quit. Those errors indicate bad sectors on the disc. Our dvdread support can skip bad sectors, but libdvdnav doesn't have an easy way to recover from a read error. If you try to seek forward past the point where the error was, libdvdnav's seek function has the possibility of actually positioning to a point before the error, thus putting you in an infinite loop. Because of this, our current code does not do error recovery and just quits. I've create a patch to libdvdnav that guarantees that an attempt to seek forward will always move the position forward and added error recovery to handbrakes dvdnav implementation. So the next build should be able to handle such errors.

[GLUBSCH]

Hey John! Right now I´m using the newest version of HB, but dvdnav still doesn´t seem to work with some dvds though.
Please take a second to scroll through this log:


[19:34:39] gtkgui: HandBrake rev0 (2009091599) - Linux x86_64 - http://handbrake.fr
[19:34:39] hb_init: checking cpu count
[19:34:39] hb_init: starting libhb thread
[19:34:39] hb_init: checking cpu count
[19:34:39] hb_init: starting libhb thread
libdvdread: Using libdvdcss version 1.2.10 for DVD access
[19:35:27] hb_scan: path=/media/MOVIEDVD_VOL1/VIDEO_TS, title_index=0
[19:35:27] scan: trying to open with libdvdread
libdvdnav: Using dvdnav version 4.1.3
libdvdread: Using libdvdcss version 1.2.10 for DVD access
libdvdread: Attempting to use device /dev/sr0 mounted on /media/MEDIADVD_VOL1 for CSS authentication
libdvdnav: Can't read name block. Probably not a DVD-ROM device.
libdvdnav: Unable to find map file '/home/glubsch/.dvdnav/.map'

libdvdread: Attempting to retrieve all CSS keys
libdvdread: This can take a _long_ time, please be patient

#SHORTENED#

libdvdread: Elapsed time 0
libdvdread: Using libdvdcss version 1.2.10 for DVD access
libdvdread: Attempting to use device /dev/sr0 mounted on /media/MEDIADVD_VOL1 for CSS authentication
[19:35:27] scan: DVD has 50 title(s)

#SHORTENED#

*** libdvdread: CHECK_VALUE failed in ifo_read.c:1791 ***
*** for pgcit->nr_of_pgci_srp < 10000 ***

libdvdread: Invalid title IFO (VTS_08_0.IFO).
[19:35:27] scan: ifoOpen failed
[19:35:27] scan: decoding previews for title 2
[19:35:27] scan: title angle(s) 1
[19:35:31] scan: audio 0x80bd: AC-3, rate=48000Hz, bitrate=448000 Unknown (AC3) (5.1 ch)
[19:35:35] scan: 30 previews, 720x576, 25,000 fps, autocrop = 2/2/2/2, aspect 4:3, PAR 16:15
[19:35:35] scan: decoding previews for title 4
libdvdread: Ignored size of file indicated in UDF.
[19:35:35] scan: title angle(s) 1
[19:35:36] scan: audio 0x80bd: AC-3, rate=48000Hz, bitrate=224000 English (AC3) (2.0 ch)
[19:35:36] scan: audio 0x81bd: AC-3, rate=48000Hz, bitrate=224000 English (AC3) (Director's Commentary 1) (2.0 ch)
[19:35:36] scan: audio 0x82bd: AC-3, rate=48000Hz, bitrate=224000 English (AC3) (2.0 ch)
[19:35:49] scan: 30 previews, 720x576, 25,000 fps, autocrop = 62/48/2/2, aspect 4:3, PAR 16:15
[19:35:49] scan: decoding previews for title 5
[19:35:49] scan: title angle(s) 1
[19:35:49] scan: audio 0x80bd: AC-3, rate=48000Hz, bitrate=224000 English (AC3) (2.0 ch)
[19:35:49] scan: audio 0x81bd: AC-3, rate=48000Hz, bitrate=224000 English (AC3) (Director's Commentary 1) (2.0 ch)
[19:35:49] scan: audio 0x82bd: AC-3, rate=48000Hz, bitrate=224000 English (AC3) (2.0 ch)
[19:35:50] scan: 30 previews, 720x576, 25,000 fps, autocrop = 62/48/2/2, aspect 4:3, PAR 16:15
[19:35:50] scan: decoding previews for title 6
[19:35:50] scan: title angle(s) 1
libdvdnav: demux error! 42 42 42 (should be 0x000001)
[19:35:50] dvdnav: Read Error, Expected NAV packet but none found.
libdvdnav: demux error! 42 42 42 (should be 0x000001)
[19:35:50] dvdnav: Read Error, Expected NAV packet but none found.
[19:35:53] dvdnav: Read Error, Error reading NAV packet.
[19:35:58] dvdnav: Read Error, Error reading NAV packet.
[19:36:03] dvdnav: Read Error, Error reading NAV packet.
[19:36:05] dvdnav: Read Error, Error reading NAV packet.
[19:36:07] dvdnav: Read Error, Error reading NAV packet.
...(to be continued)

[JohnAStebbins]

GLUBSCH, that's one screwed up disc (or you're having issues with your dvd drive). I've never seen a disc with errors like that (except the one bad disc I created for testing by marking it up with a dry-erase marker). Your log shows read failures during the scan, but you didn't supply the complete log, so I can't tell what handbrake did after completing the scan. There are 50 titles on that disc. Does it eventually complete the scan and present you with the opportunity to encode any of the titles? Please don't shorten the logs when posting them. It really does help to see the whole thing. If it's too long for the forum, put it up on our pastebin (http://handbrake.fr/pastebin/) and provide a link to it.

Do you have access to another dvd drive? It would help to eliminate the drive as a possible source of the errors.

Do you have access to a computer with anydvd or some other good ripper? It would help to know if other programs have issues with that disc.

EDIT: it would also help to know what disc it is (movie title), and if you would also provide a log of a scan with dvdnav disabled for comparison.

[GLUBSCH]

Thanks for replying, John. I´ve repeated the test with libdvdread and experienced similar results. After waiting a while, HB successfully loaded the DVD. By now I completed the backup process those DVDs - each chapter one by one. My conclusion is that the DVDs structure was very different from what I experienced so far - HB showed every title twice, the second always with one chapter more. Just for your information: Those DVDs were really old. After manually selecting and adding the titles to queue everything went the way it should. :)

Here´s another thought to throw in: HB obviously currently doesn´t support decryption of HD-DVDs and Blu-Ray. And while I see you reading this, John, I notice the wrinkles in your forehead... You guessed it: It´s about copy protection. While HB probably never will support decryption of protected sources itself (which is a good thing), other programs will for sure. In order to successfully encode HD-DVDs and Blu-Ray DVDs with HandBrake, one will have to back up those with another program first. I see that libdvdcss won´t be of much benefit here, but do other libraries for decryption (possibly even right in HB) exist or is really another program needed to acomplish this task?

I´ve been reading a lot of good things about AnyDVD-HD in the past few days, but the WineHQ AppDB (http://appdb.winehq.org/objectManager.php?sClass=application&iId=6361) reveals, that the only thing working is installation and uninstallation. As said, I´d LOVE to have a solution that would work right within HB and take care about all of the newer encryption shemes and HD/Blu-Ray DVDs as well. Please share your thoughts and recommendations on this with me, John.