بسم الله الرحمن الرحيم
A few days ago, Matt Lee of the Free Software Foundation had asked in the #theora IRC channel for help in making a DVD of the Patent Absurdity documentary. Several people volunteered to help, and I was one of them. I discovered later that this was related to the “Who should see Patent Absurdity?” campaign of the End Software Patents project (an initiative started by Brad Feld, I just discovered!).
Incidentally, we all ran into different kinds of problems, doing what should have been a rather simple task. The sources of the problems ranged from simple bugs to rather weird video formats. In this post I will discussed the various issues that I personally encountered and how, alhamdulillaah, was able to overcome them.
The most straightforward way to make the video was to take an already decent-quality clip, the 1080p-resolution Ogg Theora clip from the Patent Absurdity website, and just run that through ffmpeg with the ‘-target ntsc-dvd’ option to get a DVD-compatible MPEG-2 video stream. While this did actually produce a compliant video stream that I could burn to a DVD, the resulting video actually had some audio synchronization issues as well as some other problems related to ffmpeg’s handling of Theora’s drop frames (segments of video that are basically empty frames because the data does not change at all). So, the resulting video was unacceptable.
My next attempt was to actually go from the original source material that Matt had provided some folks over at Xiph. What’s interesting is that the format was a very odd, 1280×1080 resolution, 4:2:2 chroma-sampled DV-encoded video with a display aspect ratio of 16×9 – that was 25GB in size.. The only application that actually supports this format is ffmpeg, which means, also, it’s more widely supported than one might think. It’s still an oddball format, though. So, I ran it through ffmpeg with the same target settings as above. However, ffmpeg’s ntsc-dvd target does not change the chroma sampling format of incoming video, so it produced MPEG-2 video that had 4:2:2 chroma. I’m not sure if that’s even valid for MPEG-2, but it’s surely not valid for a DVD. So, I manually specified the proper chroma sampling using ‘-pix_fmt yuv420p’ (this means planar 4:2:0 chroma sampling).
Sure enough, this produced a DVD-compliant MPEG-2 video stream, but with one problem. The aspect ratio was not preserved. This resulted in video that was squashed horizontally. And, try as I might, nothing I could do with ffmpeg with the MPEG-2 video stream from this point on could correct the aspect ratio, and using a utility, such as mpgtx, to fix it, would make it incompatible with DeVeDe, the application I’m using to master the DVD Video itself. So, I had to do an intermediate step.
I deduced that the problem was rooted in too many transforms being required at the same time. Part of the problem may very well have been my own inexperience with ffmpeg as well, as perhaps someone may be willing to clarify via comments. Regardless, I decided to tackle the problem by doing the steps separately – rescale the video & resample chroma as one step, and then do the MPEG-2 encoding via DeVeDe, which will know how best to make DVD video it finds agreeable. So, starting with that mutant DV video source clip, I extracted the audio out into a FLAC file (the source was 48k/16b/s PCM, so very high quality). Then I worked on the video – I scaled it down to 720×480 with a 4:2:0 chroma sampling but with an aspect ratio of 16×9, and I encoded it with the lossless FFV1 codec developed by the ffmpeg developers themselves. This gave me a 7GB AVI file – not small, but far more manageable than the original 25GB source file. I downloaded that locally, and then I attempted to remux the video & audio back into the same file. And this is where the next issue occurred.
I first noticed the problem on my server, where I attempted this technique first – that is, remuxing the FFV1 AVI with the FLAC audio into another AVI file, this time with combined video & audio. I noticed my server started to lag tremendously, and even my rsync download of the video to my PC at home had halted (at more than 90%, no less). I managed to kill the ffmpeg process, and upon inspection of the load of my server, it had apparently jumped up to 30 or so during that time. I was confused, but I didn’t piece it together yet.
After the FFV1 AVI file had finished downloading to my PC (I had to restart the rsync, but thankfully, I had [and usually always] used the –partial-dir parameter to save partial downloads for just such an occasion), I attempted the same remuxing operating on my PC. Less than a minute later, I noticed that my PC had frozen. I knew it was still working because the hard drive was thrashing, so I attempted to SSH in to my PC from my laptop, which I happened to have handily next to me. After wait for about 1/2 an hour for the connection to establish and actually be able to get the system to respond, I discovered that ffmpeg’s memory usage had jumped up to 1.3 GB. And, as my PC has only 2GB of RAM and I had numerous bloaty apps open already (Thunderbird, Firefox, Konversation, Pidgen, Gwibber, and, of course, Gnome itself), this mean the system had run out of memory and was thrashing the swap file. I managed to killall -9 ffmpeg, and that brought the system back to the land of the living. I inquired on #ffmpeg why this might have happened, and the response I got was that ffmpeg doesn’t like FLAC in AVI. So I tried other container formats – Matroska & NUT, notable. They both exhibited the same problem, but I was able to kill ffmpeg in a similar fashion much more swiftly. I decided to just suck-it-up and converted the FLAC to WAV and ffmpeg muxed that without any difficult whatsoever. My PC didn’t even break a sweat.
As a side note, following some additional advice from #ffmpeg, I used mkvmerge to mux the FFV1 AVI file with the FLAC audio file, and it worked, but it lost the aspect ratio. I tried to manually specify the aspect ratio, and it gave very odd numbers that were, perhaps approximations of 16×9, but I wasn’t satisfied, so I stuck with FFV1 & raw PCM audio in AVI.
Finally, I can jump into DeVeDe and attempt to make the DVD. As I am quite pedantic about quality (in case you haven’t gathered that by now), I chose the best quality options for encoding the DVD video that DeVeDe gave me – highest rates for audio & video and two-pass video encoding. Matt had specifically said he didn’t want any menu for the DVD – he just wanted it to play, so I removed all menu options. The whole mastering & encoding process took abut an hour and a half, according to what DeVeDe reported at the end, but I just slept through that (I had stayed-up all night, partially because of this, but not solely so). I burnt the ISO that it generated onto a DVD-RW, tested it on different systems (Fedora & Windows), including a consumer DVD player, and, alhamdulillaah, it worked beautifully everywhere I played it.
So, there you have it – the trek to make a DVD about the problems caused by software patents completely with free software. It was a fun experience, and I’m glad that I was able to help with getting this important message out. In shaaʾ Allaah this will have a positive impact on patent reform and strengthen the arguments against the enforcement and even existence of software patents.