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…