We need to include libavcodec (FFmpeg) for a bunch of other parts of its API, like decoding. When choosing between FFmpeg's and XviD's, it came down to a matter of necessity. This makes it rather.superfluous to include two different encoders for an older codec, MPEG-4 Part 2. XviD: HandBrake, these days, is almost entirely about H.264 video, aka MPEG-4 Part 10. For patent-free muxing, HandBrake still has Matroska, which is a much better container anyway. 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. It hasn't been actively maintained in years either, and it too lacks support for HandBrake's best features. OGG/OGM: HandBrake's OGM muxer is just as out of date. It is not coming back, and good riddance. 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. The code has not been actively maintained since 2005. Furthermore, HandBrake's AVI muxer is vanilla AVI 1.0 that doesn't even support large files. It does not support modern container features like chapters, muxed-in subtitles, variable framerate video, or out of order frame display. As part of this process, several containers and a codec have been removed from HandBrake.ĪVI: AVI is a rough beast. 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.
0 kommentar(er)
