Handbrake drops DivX/OGG

[Sabre]

http://handbrake.fr/

Focus on what we do best
As we've had on our roadmap for quite awhile now, one of our goals for version 0.9.4 was to refocus on HandBrake's key strengths and to remove dead weight. As part of this process, several containers and a codec have been removed from HandBrake.

AVI: AVI is a rough beast. It is obsolete. It does not support modern container features like chapters, muxed-in subtitles, variable framerate video, or out of order frame display. Furthermore, HandBrake's AVI muxer is vanilla AVI 1.0 that doesn't even support large files. The code has not been actively maintained since 2005. Keeping it in the library while implementing new features means a very convoluted data pipeline, full of conditionals that make the code more difficult to read and maintain, and make output harder to predict. As such, it is now gone. It is not coming back, and good riddance.

OGG/OGM: HandBrake's OGM muxer is just as out of date. It hasn't been actively maintained in years either, and it too lacks support for HandBrake's best features. It requires conditionals to work around missing functionality too...only this one gets tested so infrequently the conditionals were never even put in the code, so it just fails when you try to do anything advanced. This one is not coming back either. And yes, we're aware of HTML 5. For patent-free muxing, HandBrake still has Matroska, which is a much better container anyway.

XviD: HandBrake, these days, is almost entirely about H.264 video, aka MPEG-4 Part 10. This makes it rather...superfluous to include two different encoders for an older codec, MPEG-4 Part 2. When choosing between FFmpeg's and XviD's, it came down to a matter of necessity. We need to include libavcodec (FFmpeg) for a bunch of other parts of its API, like decoding. Meanwhile, XviD's build system causes grief (it's the most common support query we get about compiling, after x264's requirement of yasm). Since we mainly use MPEG-4 Part 2 for testing/debugging, and recommend only H.264 for high quality encodes, Xvid's undisputed quality edge over FFmpeg's encoder is inconsequential, while FFmpeg's speed edge over XviD is important to us.

Very interesting. I have to admit, I've been using the MKV container for while and have had no issues. I am sad to see OGG go though.

[schvin]

sounds sane. thanks for posting that up.

[avriette]

Call me a Luddite or a console hippie or even a mac fanboy, but I can't figure out why this is important. What gives, J?

[Sabre]

Call me a Luddite or a console hippie or even a mac fanboy, but I can't figure out why this is important. What gives, J?

A couple of people I know (that are on here) use Handbrake. I'm pretty shocked that they dropped DivX support considering everyone seems to be using it. That's all

[avriette]

Call me a Luddite or a console hippie or even a mac fanboy, but I can't figure out why this is important. What gives, J?

A couple of people I know (that are on here) use Handbrake. I'm pretty shocked that they dropped DivX support considering everyone seems to be using it. That's all

I use handbrake as well as .. what's it called? visual studio or something like that. I don't have anything that will play mkv files on my television, but I agree it's a cool format.

[complacent]

I think it was a smart move. It helps strongly to determine a popular standard for video. The codec works well, has a light footprint with the finished product, scales beautifully to ridiculous bitrates and works on damn near every platform.

I'm sure purists and ricers will complain about the other platforms being removed... but if you want to keep scalable, compact, high-res video for a long time (personal movie collection for one) - h.264 is a smart choice. Handbrake is the de facto standard for creating that content. There have been some interesting attempts using GPUs as opposed to CPUs for transcoding, but the quality isn't there yet.

I've been using handbrake for a while now (at least a few years) and have been very impressed with their devel/upgrade path. Great project.

[avriette]

determine a popular standard for video.
light footprint with the finished product
ridiculous bitrates
works on damn near every platform.
scalable, compact, high-res video
de facto standard

NNnnnggggh. Talk dirty to me!

There have been some interesting attempts using GPUs as opposed to CPUs for transcoding, but the quality isn't there yet.

Are you suggesting the tesla isn't a GPU (which it kinda is and kinda isn't, ya know)? The tesla setup screams. I'm wondering when we're going to have smaller boards for the "computer" (which sort of becomes a browser at that point, if you ask me) and giant graphics interface cards. Our procs are definitely fast enough that very few people need what they want when they buy a $3,000 computer. If I could just have that, and a guaranteed real-time board (with a coprocessor for interrupts), I'd be super-happy. Not likely to happen on the Air, though

I've been using handbrake for a while now (at least a few years) and have been very impressed with their devel/upgrade path. Great project.

+1 it's a fabulous product. It offers you all the granularity and wacky compression and quicktime goodness that you can really do with it what you want. As I understand it, it's a bunch of complex graphic interfaces laid on top of ffmpeg. Which is not a bad thing, given all the flags you'd have to use to do it without the GUI. So it's not the most efficient software design, but I've never had it barf on me or do anything untoward. Great software. I'm waiting to see how the blu-ray stuff works, as I figure the Mac is going to get it soonish. Then it's really going to get its "ready for primetime" trials.

I love me good software!

[OldSouth]

AppGeeker video converter also handles well in video compression.
http://www.ilikemall.com/how-to/convert ... v-mac.html
you can do pretty much anything with a video.