why x264 isn't part of ffmpeg: readability of the code > readability of the svn diff. ffmpeg's defaults suck. they need to be not just revised, but different for each codec. having lots of code shared between codecs is good if you want to support lots of codecs, but it also means that whenever I change something I have to make sure it works in all codecs. I have done many speed and quality optimizations in x264 that I wouldn't have bothered to do with ffmpeg's extra baggage. such as non-mod32 interlacing, which crashes ffh264. I know how to fix it, and I have made the equivalent change in x264, but it's too intrusive into every single ffmpeg codec so I haven't fixed ffh264. maybe this is ffmpeg policy, or maybe it's just psychological on my part, but: whenever ffmpeg has some code|option that does most of what I want but not quite everything (and I can't extend it), I feel compelled to shoehorn my problem into the existing framework rather than ending up with e.g. 3 different incompatible sets motion estimation functions in ffmpeg. while coding x264 as a separate library doesn't actually reduce the amount of code duplication, it does make me happier about it. I like having a small codebase that I can recompile in about a second. I don't maintain binary compatibility between versions. I break source compatibility whenever I feel like it too, though that's less frequent. inertia.