Want to do some fun open source work and get paid? You should apply for GSOC. Check out our ideas page and the official Google page.
(And yes, I’ll get around to approving the queued comments and writing more real posts. Eventually! I promise!)
With the announcement of Google Summer of Code 2010 and the acceptance of our umbrella organization, Videolan, we are proud to announce the third x264 Summer of Code! After two years of progressively increasing success, we expect this year to be better than ever. Last year’s successes include ARM support and weighted P-frame prediction. This year we have a wide variety of projects of varying difficulty, including some old ones and a host of new tasks. The qualification tasks are tough, so if you want to get involved, the sooner the better!
Interested in getting started? Check out the wiki page, hop on #x264 on Freenode IRC, and say hi to the gang! No prior experience or knowledge in video compression necessary: just dedication and the willingness to ask questions and experiment until you figure things out.
Thanks to our Google Summer of Code student David Conrad (aka Yuvi), we now have ARM support in x264, along with a significant amount of SIMD acceleration via NEON, available on the Cortex A8 and A9 chips. Yes, that’s right, x264 can now run on an iPhone. Total performance increase from the NEON optimizations (so far) is about 280% on default settings.
With low power becoming more important and ARM chips increasing in speed dramatically (multi-core chips are already hitting silicon), being able to do high quality, high-speed realtime video encoding on ARM chips will become more and more important. Staying ahead of the game as always, x264 will be the premiere encoder on ARM as well.
One situation showing the usefulness of low-power encoding was brought up a month or two ago: a remote-control airplane enthusiast wanted to make his airplane broadcast camera footage over the cell network so that he can remote control it many miles away from his current location. The cell network is generally low bandwidth, so he needs a high-efficiency video encoder. But he can’t afford a powerful system; his airplane is already extremely low power and he needs an encoder that is both low-power and low-weight. The ARM chip is perfect: it uses a fraction of a watt, almost no space, and now, he can run x264 on it.
Special thanks to Mans Rullgard for helping with lots of assembly questions and contributing the NEON deblocking code, originally used in the ffmpeg H.264 decoder.
Want to play with x264 on an ARM? Get a Beagleboard.
“There is nothing like looking, if you want to find something… You certainly usually find something, if you look, but it is not always quite the something you were after.”
– J.R.R Tolkien
About a year and a half ago, I had an idea: what if we made a graph of how each block of the video referenced other blocks temporally and used this graph to increase quality on blocks which are referenced a lot and lower it on those which are referenced less? Clearly this would greatly improve average quality… but when I thought through it, the problem became messier and messier. I decided to put it off to later. I ended up making it a Google Summer of Code project for 2008, but that student disappeared after a few weeks of relative non-work and a hardly-working initial patch. I mostly forgot about it; it was in the same category as explicit weighted prediction and MBAFF: messy things that might help, but I didn’t want to do. This idea in particular got filed away under the name “MB-tree.”
Its been quite some time, hasn’t it? I’ve managed to go a few months without updates here, mostly because of my work at Avail and school also, but also because I’ve been intentionally putting it off. So, I’m going to actually put in some updates.
x264 now supports Predictive Lossless, the new lossless format introduced in the 2007 revision of the H.264 standard. The compression improvement is considerable; about 4-25% depending on source, with numbers generally higher in intra-only compression. There is no significant speed difference; if anything, it is faster, since lower bitrate means less time spent in bitstream coding. The downside is that only a single decoder in the entire world currently supports it correctly: CoreAVC. Not even JM supports it correctly (its i16×16 prediction support is bugged). A patch is available on the ffmpeg mailing list (simply search for Predictive Lossless or similar) to add support in libavcodec for the format. The strategy here is that since the main reason any decoder anywhere supported lossless to begin with is likely because of x264, this change should force the adoption of the much-superior Predictive Lossless profile.
I’ve begun merging much of the Google Summer of Code work; next on the menu will be the rest of Holger’s assembly and Joey Degges’ much improved multi-ref p8×8 partition search algorithm.
I also have acquired access to a pre-release Nehalem machine through Avail Media; this will allow for a series of Nehalem-specific speed optimizations to be committed on the day of Nehalem’s official release, giving a significant speed boost to users of the new processor in addition to the already-enormous benefit it gives.
x264 is now used by Facebook for their internet video; at this point in time, 25% of all new Facebook videos are encoded using x264. This will likely soon increase to 100% as VP6 is phased out in favor of H.264.
x264 is now at revision 999: only one left to 1000, and indeed we have special plans… more on that when it happens!
This year, x264 is participating in Google Summer of Code. We have accepted four applications out of a total of roughly 15 applications (out of Videolan’s roughly 80 applications and 14 slots). The projects are as follows:
Robert Deaton (masquerade): Improve B-frame decision, both in terms of simple numbers of B-frames, direct modes, frame ordering, reference frame using, etc.
Joey Degges (keram): Improve inter mode search and decision and experiment with more psychovisual optimizations
Aki Jäntti (Kuukunen): Use a “macroblock tree” structure to measure the temporal importance of various parts of the image.
Holger Lubitz (holger): General assembly optimizations and speed improvements.
Good luck to all participants!