Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

Peak Codec

April 19th, 2010 by Multimedia Mike

One day, I saw Suxen drol create a new page on the MultimediaWiki discussing something called the Peak codec. I was about to scold him for not uploading and linking to samples for this codec until I read closer. The Peak codec seems to refer to a theoretical best possible codec. Could such a beast really exist?

Based on everything I’ve read, perhaps On2’s VP8 is the Peak codec of lore: All things to all people.

Posted in General | 3 Comments »

VP8: The Savior Codec

April 16th, 2010 by Multimedia Mike

This past week, the internet picked up — and subsequently sprinted like a cheetah withan unsourced and highly unsubstantiated rumor that Google will open source the VP8 video codec, recently procured through their On2 acquisition. I wager that the FSF is already working on their press release claiming full credit should this actually come to pass. I still retain my “I’ll believe it when I see it” attitude. However, I thought this would be a good opportunity to consolidate all of the public knowledge regarding On2’s VP8 codec.



Pictured: All the proof you need that VP8 is superior to H.264
Update: The preceding comment is meant in sarcastic jest. Read on

The Official VP8 Facts:
Read the rest of this entry »

Posted in HTML5, Multimedia PressWatch, On2/Duck, VP8 | 22 Comments »

Alphabet of Tracing

April 15th, 2010 by Multimedia Mike

So I’m sitting in the tracing discussion at this year’s Linux Foundation Collaboration Summit. One presenter discussed a tracing facility called utrace. This got me thinking of all the different _trace utilities I could name off the top of my head: dtrace, ptrace, strace, and utrace. Then I wondered how many letters of the English alphabet already serve as prefixes to the word ‘trace’ as software utilities. My cursory research indicates 21/26 24/26.

Oh yeah, I looked them all up (and thanks to all who helped me fill in the blanks):

  • atrace: astrange’s raytracer
  • btrace: Tracing for Java
  • ctrace: multi-threaded trace/debug library
  • dtrace: Sun’s comprehensive framework
  • etrace: The Embedded ELF tracer
  • ftrace: Fast traceroute for Win32; also ftrace: function tracer
  • gtrace: Graphical front-end to traceroute
  • htrace: apparently an extension to windbg
  • itrace: not Apple-related (see ktrace); this stands for instruction strace
  • jtrace: Java rewrite of a speech recognition technique called TRACE
  • ktrace: Kernel tracing for certain BSDs including Mac OS X
  • ltrace: Linux utility to monitor library calls
  • mtrace: Memory debugger in the GNU C library
  • ntrace: Tracing for .NET applications
  • otrace: Oracle database tracing
  • ptrace: Process tracing in Linux
  • qtrace: Another traceroute utility
  • rtrace: Ruby-Trace almost qualifies
  • strace: Tracing system calls
  • ttrace: Tracing facility for multithreaded processes
  • utrace: Linux tracing
  • vtrace: System-wide profiling of WinNT or Win2K
  • wtrace: Provides information to debug methods (pertains to Tivoli?)
  • xtrace: Tracing for X servers
  • ytrace: Nothing
  • ztrace: Win32 tracing utility

So, if you must make a new tracing utility, atrace, etrace, rtrace, ytrace, and ztrace all seem to be open.

Thanks for sitting through another of my pointless surveys. Oh, and thanks also to Google for providing Summit attendees with free, unlocked Nexus One phones. I haven’t seen many other mentions of this. Maybe Google does this so often that it barely counts as news anymore.

Posted in General | 6 Comments »

FATE Building Blocks

April 12th, 2010 by Multimedia Mike

For 2 years, I’ve been wrangling with the overall architecture of the FATE system. Right now, there’s a primary fate-script.py program that manages building and testing on FATE installations that is sorely in need of many upgrades. Then there is fate-client.py which is a somewhat lighter-weight testing program. I have long wanted to merge the 2 scripts but could never settle on how to do it. At the base level, should the script assume that it’s operating in continuous build/test mode (a la fate-script.py) or single-shot test mode (a la fate-client.py) by default? Or neither? Should it force the user to specify a mess of command line options?

I had an epiphany recently while reading the documentation for Python’s standard (as of v2.3) optparse module, specifically the section entitled “What are options for?”

Options are used to provide extra information to tune or customize the execution of a program. In case it wasn’t clear, options are usually optional. A program should be able to run just fine with no options whatsoever… Lots of people want their programs to have ‘required options’. Think about it. If it’s required, then it’s not optional!

This led me to consider the possibility of a FATE script that could do something without any options and then build from there.

Default Operation Read the rest of this entry »

Posted in FATE Server | 5 Comments »

« Previous Entries Next Entries »