Monthly Archives: July 2010

Usurper of FATE

Mans sent a message to the FFmpeg-devel list today:

A new FATE

Mike’s FATE system has done a great job over the last few years. It
is however beginning to prove inadequate in various ways:

[various shortcomings already dissected at length on this very blog]

To address the above-mentioned issues, I have been working on a
replacement system which is now ready to be announced.

Check it out: http://fate.ffmpeg.org/.

Considering that he just obsoleted something I’ve poured a lot of time and energy into over the last 2.5 years, is my first reaction to this news supposed to be unbridled joy? Hey, I’m already on record as stating that I wouldn’t mind throwing away all of FATE if there was a better alternative.

I’m not certain but I’m pretty sure that at this point, the original FATE server is practically obsolete. Mans is already testing all of his configurations as well as the configs I test. As soon as the other FATE installations switch over to the new server, I should be able to redirect fate.multimedia.cx -> fate.ffmpeg.org, sell most of my computers, and spend more time with my family.

Thanks, Mans!

Official RealVideo Specifications

A little birdie tipped me off to a publicly-accessible URL on the Helix community site (does anyone actually use Helix?) that contains a bunch of specifications for RealVideo 8 and 9. I have been sifting through the documents to see exactly what they contain as the different files seem to be higher revisions of the same documents. Here is the title, date, and version of each PDF document:

  • RNDecoderPerformanceARM.pdf: Decoder Performance on StrongARM and XScale; May 12, 2003; Version 1.1
  • rv89_decoder_summary.pdf: RealVideo 8/9 Combo Decoder Summary; October 23, 2002; Version 1.0
  • rv9_dec_external_spec_v14.pdf: RealVideo 9 External Specification; November 7, 2003; Version 1.4
  • rv8_dec_external_spec_v20.pdf: RealVideo 8 External Specification; September 19, 2002; Version 2.0
  • RV8DecoderExternalSpecificationv201.pdf: RealVideo 8 External Specification; October 20, 2006; Version 2.01
  • RV8DecoderExternalSpecificationv202.pdf: RealVideo 8 External Specification; April 23, 2007; Version 2.02
  • RV8DecoderExternalSpecificationv203.pdf: RealVideo 8 External Specification; July 20, 2007; Version 2.03
  • RV8DecoderExternalSpecificationv21.pdf: RealVideo 8 External Specification; September 11, 2007; Version 2.1
  • RV9DecoderExternalSpecificationv15.pdf; RealVideo 9 External Specification; January 26, 2002; Version 1.5
  • RV9DecoderExternalSpecificationv16.pdf; RealVideo 9 External Specification; August 17, 2005; Version 1.6
  • RV9DecoderExternalSpecificationv18.pdf; RealVideo 9 External Specification; September 11, 2007; Version 1.8

Additionally, there is an Excel spreadsheet entitled realvideo-faq.xls that appears to contain some general tech support advice for using Real’s official code. There are also 3 ZIP archives which contain profiling information about the official source code (post processing and entropy decoding top the charts which is no big surprise).

I guess the latest version of each document (the ones dated September 11, 2007) are worth mirroring. Unfortunately, those latest document versions use a terrible font.

Update: Documents mirrored here at multimedia.cx.

Parlez-Vous Binutils?

I found myself in need of some binutils today. What do you suppose it is about this basic Apache file listing page that makes Google Chrome think it’s in French?



Opting to translate doesn’t seem to have any affect, aside from ruining the alignment of the columns.

That quirk aside, the page translation facility is actually quite nifty.

Brute Force Dimensional Analysis

I was poking at the data files of a really bad (is there any other kind?) interactive movie video game known simply by one letter: D. The Sega Saturn version of the game is comprised primarily of Sega FILM/CPK files, about which I wrote the book. The second most prolific file type bears the extension ‘.dg2’. Cursory examination of sample files revealed an apparently headerless format. Many of the video files are 288×144 in resolution. Multiplying that width by that height and then doubling it (as in, 2 bytes/pixel) yields 82944, which happens to be the size of a number of these DG2 files. Now, if only I had a tool that could take a suspected raw RGB file and convert it to a more standard image format.

Here’s the FFmpeg conversion recipe I used:

 ffmpeg -f rawvideo -pix_fmt rgb555 -s 288x144 -i raw_file -y output.png

So that covers the files that are suspected to be 288×144 in dimension. But what about other file sizes? My brute force approach was to try all possible dimensions that would yield a particular file size. The Python code for performing this operation is listed at the end of this post.

It’s interesting to view the progression as the script compresses to different sizes:



That ‘D’ is supposed to be red. So right away, we see that rgb555(le) is not the correct input format. Annoyingly, FFmpeg cannot handle rgb5[5|6]5be as a raw input format. But this little project worked well enough as a proof of concept.

If you want to toy around with these files (and I know you do), I have uploaded a selection at: http://multimedia.cx/dg2/.

Here is my quick Python script for converting one of these files to every acceptable resolution.

work-out-resolution.py:
Continue reading