Bismillaahir Rahmaanir Raheem

Alhamdulillaah, I have really been engrossed in using ffmpeg, one of the most amazing a/v command-line tools out there, for my various personal video projects.  However, recently I was experiencing a recurring bug where I could not work with some specific codecs when either the input or the output file was on a particular drive (!).  The drive in question happened to have only one FAT32 partition, so I suspect it may have had something to do with it, as using another drive for both input & output would generally work flawlessly.  The particular action I was trying to perform was to encode a sequence of rather large JPEG files (3072×2304) into a single video file using the outstanding (but still somewhat experimental and/or unstable) FFV1 lossless codec.

So, I visited the ffmpeg website and looked at some of their bugs, but didn’t see anything related to this.  Then, after seeing some of their pre-bug report checklist, I decided to check the version of ffmpeg I had on the system, and found it to be from March.  So, I pulled-down a fresh copy of their trunk via subversion and ran configure & make (I did not run make install).  Running the resulting ffmpeg binary from this compile run worked perfectly, alhamdulillaah.

The lesson is, if you’re running into a bug with either ffmpeg or any other package, then give a shot at running the latest code, if available.  It may seem like common sense, but I had underestimated just how easy it would be.  Surely, other packages may not work as simply, but it really was a piece of cake in this case.  Now I guess I need to learn how to package RPMs so I can help out the Livna project to get this latest code into their repository, which I also understand is not simple task, as many other projects rely on ffmpeg…