As you might know, HANDBRAKE is a a GPL-licensed, multiplatform, multitrhreaded video trancoder and certainly a great application for transcoding videos on OpenSuse as well.
So far I’ve created great results with HandBrake - but still I’m wondering if this is the “best bet”. As for the transcoding tasks under *nix I like to use a GUI and be able to have a comfortable overview over all the settings to manage. Furthermore I like projects that are under constant development and are updated on a regular basis.
Now here are my questions: Which video transcoder do YOU use? Which ones do you strongly recommend? Also, please don’t forget to state WHY you came up with your choice.
there"s no such thing as “best” as per doom9.org forum rules FOR VERY GOOD REASONS
what may be “best” for you may not be “best” for another or for a specific task. HB is certainly on par with other encoders (as it uses libavcodec from FFmpeg) and does its job well, but I’ve also seen it fail on more than one occasions (also, do they still refuse to offer quality-based Vorbis encoding?.. /me shakes head in disbelief)
As for which encoder I use, you already know the answer
There are only a handful encoders for *nix
ffmpeg
mencoder
handbrake
transcode
x264 (the only one which doesn’t use libavcodec)
The chance that a new encoder will come out which does not use libavcodec from FFmpeg is virtually impossible
Thanks for your reply microchip, I knew I’d receive a post from you. The following is the reply of the packman team regarding my request to include Handbrake in their repository:
…
I’ve been working on HandBrake 0.9.3 for two days now, and finally managed to package it locally.
I’m now submitting it to our Build Service instance and expecting a lot of warnings from rpmlint, which I’ll fix before pushing it to the Packman repository. So stay tuned, the packages should be available by Monday.
The reason we didn’t package HandBrake before now is that it is a major pain in the bottom to package. It uses a bizarre build system with lots of in-tree libraries. It already took me 3 or 4 hours of work so far.
Why should we do weekly snapshot builds ?
And why should they do weekly snapshot builds of HandBrake? Certainly because users of their repository prefer to be able to always use the “bleeding edge” of HandBrake.
As this appears to be a rather stressy work I’ve offered to assist (which I would love to do by the way).
Yes, HB is a pain in the @ss to compile and certainly to package. Also, and I don’t know if this is true anymore since I haven’t touched HB in quite some time, but in the past HB used to use a built-in libx264 which means that it restricted you in using the provided libx264 version only as there was no external linking possible. So if you are like me who always recompiles x264 from git whenever a change is made to it or something new is added, you’re stuck in using HB with the built-in version until they update it to latest x264 from git - this is certainly not an option for me as I aways use latest x264 with mencoder. I don’t know if this has changed, as I said, and it may very well be possible now to link HB to external libx264 which can only be a good thing.
As for encoding. A GUI is not a requirement for encoding. It’s only a requirement for clueless noobs who don’t know what they are doing or for people who have been baby fed with GUI interfaces all their lives, like the Windows noobs for example
if you can’t encode from command line, understand all the options and what they do/how they work and know how to handle different types of content, then you’re not an encoding guru
You must see the light before you can talk about “The Art Of Encoding”
Hi
Did you not point at the src rpm, would have possibly saved two days
work for the packager.
One of the major reasons I like handbrake is because of the ‘Bizarre’
feature I can install it as a standalone application without the need
to install any external codecs.
I use packman on this system though for smplayer (watching hdtv) and
the mp4’s from handbrake
Hopefully in the near future (I haven’t checked the forum lately) the
QT interface will be accepted into the build tree.
–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.2 Milestone 6 (i586) Kernel 2.6.31-rc7-4-desktop
up 1:39, 2 users, load average: 0.18, 0.15, 0.10
ASUS eeePC 1000HE ATOM N280 1.66GHz | GPU Mobile 945GM/GMS/GME
IMHO it would be good for malcomlewis’ experience in this to be passed on to the Packman packagers, as often 2 heads are better than one, and I suspect such collaboration, even if there are different approaches, would have a reasonable probability of being well received.
Yes, and that “Bizzare” feature is exactly the one that does not allow you to link to external libs which you can upgrade to offer new functionality and speed improvements, as is the case with x264. Instead you’re forced in waiting whenever the HB devs update x264 internally. For me this is unacceptable. MEncoder does a much better job here. I only need to compile x264 (with shared libs enabled) and MEncoder will directly see and use the new option(s) added to libx264. It parses those directly from it so there’s no need to recompile the whole MPlayer package just to use these new things. Of course, if API changes in x264, I must recompile but luckily this does not happen that often. And I didn’t even mention patches which x264 has and are needed for Bluray compliancy. It’s impossible to patch the built-in x264 in HB with those, not unless you know what you’re doing.
PS: HB uses external libs, it’s just that they are built-in into HB. HB itself does not re-implement H.264 encoding or MPEG4 Part 2, or MPEG2 or whatever other encoding it supports. It uses libavcodec with is not in-house developed but is part of FFmpeg
Of course, HB has in-house developed stuff - the decomb/detelecine filter springs to mind right now which is actually very good. Some filters are also ported from MPlayer, the pp7 deblocker and the yadif deinterlacer for example.
I should also mention that if they use plain mainline then patching its x264 with NAL HRD is easy. If they don’t use mainline x264 and modify it to fit with their encoder then this will become extremely difficult to patch x264 with a mainline patch. But still, you have to compile afterwards the whole encoder just because you patched a lib it uses, unlike mencoder/ffmpeg where you only need to compile your x264 and both ffmpeg and mencoder will happily pick it up with the new options without the need to recompile them too
Hi
Totally agree with you on your posts In my particular application
this is ideal for me as I don’t wish to have the external libraries on
the system, so the appeal of standalone is perfect. I can also live
with not having the latest and greatest.
My main machine is running SLED11, hence this reason. I also use
fluendo codecs for all the multimedia requirements as well, so keeps
the install base pretty clean.
If there are specific applications for this machine, which runs
openSUSE I use packman etc
–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.2 Milestone 6 (i586) Kernel 2.6.31-rc7-4-desktop
up 3:09, 2 users, load average: 0.17, 0.10, 0.10
ASUS eeePC 1000HE ATOM N280 1.66GHz | GPU Mobile 945GM/GMS/GME
Exactly, for those who don’t need such things like me, eg patching, latest x264 version, etc, HB will do just fine. But for those who may need it, it may not be enough, which just proves my previous point I made. There’s no such thing as “best”. Best is relative to the needs of the user
Hi there, here’s a new message of the friendly packager that works on porting HandBrake into the packman repo:
After talking to the handbrake developers, I will indeed build SVN snapshots rather than 0.9.3. Still working on it, but should be available soon. I’ll let you know as soon as it is in the repositories.
I’ll try to keep up with the latest changes there, as time permits.
Furthermore, I’d like to say “Thanks” to oldcpu:
I’ll send malcolm a PM. Maybe we’ll both learn something new.
Yes, yaloki was fairly happy on IRC chat last night that he finally managed to wrestle its build “to the ground” and package it. Right in the middle of our chat my Internet connection went … Its still not back. >:( I went into the office an hour early this morning, to get my internet “fix” and soothe the withdrawal pains. lol!
I had nothing to do with the handbrake packaging, although now that it is packaged I do hope to take advantage of the effort of others and use it. I am very grateful/thankful to pbleser and anyone else who may have been involved for packaging this (and of course thankful to the developers/coders who coded the software in the first place).
Given the commitments on his time as a member of the openSUSE board , I think we are lucky that he still volunteers a lot of his time to package applications.
Mh? Glad you managed your internet connection… what would this community be without ya? heheh…
Totally agreed. I actually do look forward to be able to contribute either with packaging and/or other interesting tasks. Hey, Einstein still loves to learn.
Nice, glad yaloki packaged it. He does a lot of packaging (and is from my country too :P)
I just checked HB, not bad at all and it even allows you to customize in the GUI the x264 options, which are written the exact same way you do it in MEncoder. One big disappointement for me, or rather 2:
it still doesn’t allow quality-based Vorbis encoding
it uses too outdated x264 - core 68 while current x264 is at core 75. This is a pity since newer x264 includes Macroblock Tree which greatly improves the quality and at the same time in most cases lowers the bitrate, which is a so called “double plus” option. And of course, it misses lookahead too, including VBV one
There are also a few “flaws” in its “High Profile” preset.
it enables by default all partition types which means that it enables the p4x4 partition type too. p4x4 brings so little benefit that it isn’t worth using it considering how much it can slow down the encoding for virtually no benefit at all for DVDs.
It does not disable fast P-skipping which can lead in some cases in visible blocks in flat areas (like if you have a sky scene in the movie). Disabling DCT decimation is also a good thing (which HB doesn’t do)
Direct prediction should be set to Auto and let the encoder decide between Temporal and Spatial prediction for motion vectors on a per frame basis
Psy-RD is a bit too strong, IMHO. It should be set to 0.8 and Psy-Trellis should be enabled and set to 0.15 or 0.2. However this is still up for discussion so YMMY and depends on content.
Trellis quantization is not enabled AT ALL in the high profile preset… what???
Of course, one can create in HB his own presets (as is possible in h264enc too :P) and use those
Thanks for pointing this out, microchip8. Maybe you’ll find a minute to send yaloki/pbleser a permalink to your post so that he is able to change the settings appropriately.
I’m still playing to find a preset for the highest Quality possible on DVDs:
Should trellis be enabled all the time or just for the final Macro block?
Which values are to set in “Deblocking” under Tab “Miscellaneus” if DECOMB is already enabled in the picture settings?
Is there even a difference between “Deblock” in the picture settings and “Deblocking” in x264?
these are built-in presets, afaik. So one should talk to the HB devs. Since I don’t care about HB atm, it won’t be me
and since I summed up above the improvements, you can easily create your own preset with the above and save it for future use. As for outdated x264, I still don’t know if HB modifies mainline x264 or includes it as-is. If it modifies it to fit in in HB, that’ll be some work. You can’t just get vanilla x264 and drop it in in HB then compile
The Mask, as microchip8 correctly pointed out, typically this is not something that the packagers like to do. Yes, it is possible for a packager to put in a custom patch to a package, but that makes the maintenance of said package very difficult. From what I understand HB is already very difficult, … to ask more might be asking too much. Hence Yaloki is NOT who you need be talking too.
Rather I agree 100% with microchip that it is far better in such cases to talk to the HB devs and ask them. But be prepared for a good technical discussion if one is going to try to influence how a developer codes their package.
In my particular application