On 8/29/07, Guillaume POIRIER <[EMAIL PROTECTED]> wrote: > You probably know that FFmpeg is about to get a new MKV muxer since a > MKV muxer has been developed as part of Google Summer Of Code. > This may be a nice alternative to HandBrake's, though I have no idea > what is the value of either of them.
libmkv codebase in an enhancement of mkv muxer found on x264 archives. It is pretty simple and of course not completed, and one of it's advantages is exactly it's simplicity. Regarding ffmpeg. I'm aware of (most of) summer of code ffmpeg projects, and I happily recognize the key role of ffmpeg in F/OSS multimedia field. In fact, I also plan to improve our ffmpeg support by adding libavformat (de)muxers and improve our libavcodec modules. I'm also following libavfilter development with an high degree of interest. Looks like a lot of interesting ideas are floating around libavfilter, and most of them get implemented. But. While I'm interested in improving compatibility with ffmpeg and reusing it's (good) code and infrastructure, I *do not* want to make transcode just another libav* frontend. So third-party, independent implementations like avilib/libmkv are gladly welcome and they are first class citizens in transcode just like libav*. Yes, I'm aware that could lead to code duplication and, often, this will lead to results worse, speed-wise and/or quality-wise, than libav*. Neverthless, that's the way I'll go for reasons outlined above. e.g., I'll happily merge a libavfilter bridge and/or compatibility code to make libavfilter's plugin work with transcode, but I do NOT want to drop our own plugin system. Of course, it must be rewritten almost from the ground up, but that's a different story. :) To summarize: I agree that ffmpeg is THE reference (along with gstreamer) in F/OSS multimedia field, but transcode still reclaim it's place :) Bests, -- Francesco Romani // Ikitt
