Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Left ARM vs. Right ARM

June 18th, 2009 by Multimedia Mike

MÃ¥ns went and got one of those Sheeva Plugs— the wall-wart form factor computer that is a self-contained ARM-based computer. Of course it’s already in service doing FATE duty. This is an ARMv5TE CPU which is in contrast the the ARMv7 series on the Beagle Board. This is why there are 2 blocks of ARM results on the FATE page.

In other FATE news, I activated 10 new tests tonight: v210, for the V210 10-bit YUV format; and 9 more fidelity range extension H.264 conformance vectors.

Posted in FATE Server | 9 Comments »

New H.264 Tests In FATE

June 17th, 2009 by Multimedia Mike

I have just activated 18 new test specs for FATE. One is a test for one variant of the newly supported DPX format. The other 17 are for various samples in the fidelity range extension suite of test vectors, an extension of H.264 that FFmpeg has supported for some time. It should be noted that more samples from this suite should be forthcoming as soon as I finish downloading the whole thing (something I thought I had done a long time ago).

Posted in FATE Server | Comments Off on New H.264 Tests In FATE

Perceptual Video Testing

June 16th, 2009 by Multimedia Mike

While I have thought a lot about the problem of testing perceptual audio decoders in FFmpeg via FATE, I have put little thought into testing perceptual video decoders. I surmise that my 1-off testing method for perceptual audio decoders is probably not tractable for video decoders. I suspect that, while rounding errors also cause off-by-1 errors in video decoders, compounded errors during multiple frames could stretch the threshold. There’s also the minor matter that it would require a much larger amount of space to store raw video data vs. the audio data required for the perceptual audio tests.

Testing video decoders isn’t such a big deal, though. The FFmpeg devs have had this problem solved via the ‘make test’ regression suite for a long time. There are a few flags to tack onto a command line which will invoke a bit exact inverse discrete cosine transform (IDCT). The trade-off is that optimized IDCT code paths are not exercised.

I’m thinking of a 2-part solution:

  1. As a first pass, enter video decoding tests that leverage the bit exact IDCT.
  2. As a second pass, craft special test cases that decode one frame of video and leverage the default, optimized IDCT. Test the result using the 1-off method.

See Also:

Posted in FATE Server | 2 Comments »

Terminator Salvation Credit Code Snippets

June 15th, 2009 by Multimedia Mike

I saw Terminator Salvation recently. Observers enjoy dissecting the many ways that the entire Terminator franchise fails to add up, logically. I’m certainly not here to defend it.

Terminator Robot (T-800); from Terminator 3 movie trailer
When facing scary-looking creatures like spiders, loud dogs, and humanoid robots, it helps to remember that they’re probably more afraid of you than you are of them. Probably.

However, none of the reviews or analyses I have read so far have mentioned the opening credit sequence for Salvation. Every actor’s name is ensconsed in some nonsensical computer code construct. The average programmer finds himself unable to avoid guessing what language the movie could have been hinting at– C, C++, Objective-C, XML, Python. They looked something like this:

/**Christian Bale;

>> Sam Worthington <

[ Helena Bonham Carter ]

Moon Bloodgood++

<Anton> <Yelchin>

I’m surprised that this hasn’t merited a mention in IMDb’s Crazy Credits section for the movie. Maybe Skynet (the master computer of the Terminator franchise) uses a proprietary language which is a mish-mash of all the computer languages the humans developed.

Posted in Programming | 2 Comments »

« Previous Entries