Monthly Archives: September 2009

Happy 20,000; New YouTube Engine

FFmpeg crossed the 20,000 commit threshold today. Mans captured the distinction when he submitted an ARM NEON optimization for int32_to_float_fmul_scalar(). Does that warrant a prize? Diego presented the statistics:

It took 7 years to get to r10000, but only two more to get to r20000.
FFmpeg is approaching warp 6 :-)

Today was also the day I noticed that YouTube upgraded their backend conversion system somewhere along the line. Nearly 3 years ago, I started poking at YouTube to see what kind of multimedia files it can convert and cataloged my findings at the MultimediaWiki.

Today, I was clicking around on some of my old videos and noticed that this video which came from an Ogg Theora source now looks correct. Actually, according to the comments (and I receive enough between all my videos that I rarely pay attention to any of them), this was working over a year ago.

It’s interesting to note that this means that YouTube/Google keeps all of the source material that users upload. When it was time to recode, they obviously had to go back to the original material.

I found that CSCD, KMVC, 3iv2, ZMBV, and VP6 video codecs all work; Vivo files, Westwood v2 VQAs, Real files with RV40, and the bastardized FLIC files from The Magic Carpet are all fine as well; Wing Commander III MVE files, id CIN files, and Interplay MVE files all transcode with audio but with either missing or glitched video.

Sorry if I seem a bit sentimental about this but it all still amazes me. When I was writing the bulk of the subsystems for all manner of bizarre formats circa 2001-2003, I never could have imagined that there would be a website that would take the weird video formats as input and convert them to a standard video format for anyone to view.

Optimizing Away Arrows

Google released the third version of their year-old Chrome browser this past week. This reminded me that they incorporate FFmpeg into the software (and thanks to the devs for making various fixes available to us). Chrome uses FFmpeg for decoding HTML5/video tag-type video and accompanying audio. This always makes me wonder, why would they use FFmpeg’s Theora decoder? It sucks. I should know; I wrote it.

Last year, Reimar discovered that the VP3/Theora decoder spent the vast majority of its time decoding the coefficient stream. He proposed a fix that made it faster. I got a chance to check out the decoder tonight and profile it with OProfile and FFmpeg’s own internal timer facilities. It turns out that the function named unpack_vlcs() is still responsible for 44-50% of the decoding time, depending on machine and sample file. This is mildly disconcerting considering the significant amount of effort I put forth to even make it that fast (it took a lot of VLC magic).

So a function in a multimedia program is slow? Well, throw assembly language and SIMD instructions at the problem! Right? It’s not that simple with entropy decoders.

Reimar had a good idea in his patch and I took it to its logical conclusion: Optimize away the arrows, i.e., structure dereferences. The function insists on repeatedly grabbing items out of arrays from a context structure. Thus, create local pointers to the same array and save a bunch of dereferences through each of the innumerable iterations.

Results were positive– both OProfile and the TSC-based internal counter showed notable improvements.

Ideas for further improvements: Multithreading is all the rage for video decoders these days. Unfortunately, entropy decoding is always a serial proposition. However, VP3/Theora is in a unique position to take advantage of another multithreading opportunity: It could call reverse_dc_prediction() in a separate thread after all the DC coefficients are decoded. Finally, an upside to the algorithm’s unorthodox bitstream format! According to my OProfile reports, reverse_dc_prediction() consistently takes around 6-7% of the decode time. So it would probably be of benefit to remove that from the primary thread which would be busy with the AC coefficients.

Taking advantage of multiple threads would likely help with the render_slice() function. One thing at a time, though. Wish me luck with presenting the de-dereferencing patch to the list.

Python Bit Classes

Here’s a little project of absolutely no use to anyone (a specialty of mine, as if you didn’t know): Pure Python classes for writing and reading bitstreams. This was just one of those things where I was sitting around wondering what it would take to accomplish, and a cursory Google search didn’t reveal anything useful (though it’s probably out there, in all likelihood), so I sat down and pounded out the code.

To what end? Oh, I don’t know– reimplement FFmpeg in Python; go crazy. Behold brute force bit banging in Python:

Continue reading →

FATE of BeOS and Haiku

Once upon a time, all the way back in 1998, I remember downloading a demo version of BeOS on some kind of live HD partition hosted under Windows. I booted into it twice and couldn’t find a good reason to do it a third time. However, there is that bustling community of developers developing the clone of BeOS named Haiku. This article at Ars Technica leads me to believe that the Haiku OS has reached some kind of development milestone (R1 alpha1).

Of course, this all reminds me that FFmpeg does have 1 or 2 developers who like to make sure that the application still builds and runs on Haiku. But are there any takers for running FATE continuously on Haiku? I installed the ISO image in a VMware session but was unable to connect to a network. I’m a little surprised Haiku doesn’t at least support the VMware network device (or does it? Perhaps I need to manually configure it somehow).


Haiku terminal and logo

I think I may finally understand the compelling reason to continue supporting gcc 2.95 in FFmpeg: that’s the default one installed in BeOS. This strikes me as odd since BeOS was alleged to be based largely on C++ and gcc’s C++ language support as of 2.95 was known to be less than stellar. Perhaps the OS builders simply limited themselves to a sane subset of the language which could conceivably make Be programming halfway tolerable.

For my part, I’m wondering how to program Haiku/Be in the first place. Haiku is supposed to reimplement Be’s C++ API, but where is that defined? Is O’Reilly’s online Be programming book the last word on the matter? I should check my boxes and see if I still have a giant book of Be that a friend gave me a long time ago for no good reason. He must have gotten the impression I was interested in hacking operating systems or something.