Diary Of An x264 Developer

10/23/2011 (12:09 pm)

The neutering of Google Code-In 2011

Filed under: development,GCI,google,x264 ::

Posting this from the Google Summer of Code Mentor Summit, at a session about Google Code-In!

Google Code-In is the most innovative open-source program I’ve ever seen.  It provided a way for students who had never done open source — or never even done programming — to get involved in open source work.   It made it easy for people who weren’t sure of their ability, who didn’t know whether they could do open source, to get involved and realize that yes, they too could do amazing work — whether code useful to millions of people, documentation to make the code useful, translations to make it accessible, and more.  Hundreds of students had a great experience, learned new things, and many stayed around in open source projects afterwards because they enjoyed it so much!

x264 benefitted greatly from Google Code-In.  Most of the high bit depth assembly code was written through GCI — literally man-weeks of work by an professional developer, done by high-schoolers who had never written assembly before!  Furthermore, we got loads of bugs fixed in ffmpeg/libav, a regression test tool, and more.  And best of all, we gained a new developer: Daniel Kang, who is now a student at MIT, an x264 and libav developer, and has gotten paid work applying the skills he learned in Google Code-In!

Some students in GCI complained about the system being “unfair”.  Task difficulties were inconsistent and there were many ways to game the system to get lots of points.  Some people complained about Daniel — he was completing a staggering number of tasks, so they must be too easy.  Yet many of the other students considered these tasks too hard.  I mean, I’m asking high school students to write hundreds of lines of complicated assembly code in one of the world’s most complicated instruction sets, and optimize it to meet extremely strict code-review standards!  Of course, there may have been valid complaints about other projects: I did hear from many students talking about gaming the system and finding the easiest, most “profitable” tasks.  Though, with the payout capped at $500, the only prize for gaming the system is a high rank on the points list.

According to people at the session, in an effort to make GCI more “fair”, Google has decided to change the system.  There are two big changes they’re making.

Firstly, Google is requiring projects to submit tasks on only two dates: the start, and the halfway point.  But in Google Code-In, we certainly had no idea at the start what types of tasks would be the most popular — or new ideas that came up over time.  Often students would come up with ideas for tasks, which we could then add!  A waterfall-style plan-everything-in-advance model does not work for real-world coding.  The halfway point addition may solve this somewhat, but this is still going to dramatically reduce the number of ideas that can be proposed as tasks.

Secondly, Google is requiring projects to submit at least 5 tasks of each category just to apply.  Quality assurance, translation, documentation, coding, outreach, training, user interface, and research.  For large projects like Gnome, this is easy: they can certainly come up with 5 for each on such a large, general project.  But often for a small, focused project, some of these are completely irrelevant.  This rules out a huge number of smaller projects that just don’t have relevant work in all these categories.  x264 may be saved here: as we work under the Videolan umbrella, we’ll likely be able to fudge enough tasks from Videolan to cover the gaps.  But for hundreds of other organizations, they are going to be out of luck.  It would make more sense to require, say, 5 out of 8 of the categories, to allow some flexibility, while still encouraging interesting non-coding tasks.

For example, what’s “user interface” for a software library with a stable API, say, a libc?  Can you make 5 tasks out of it that are actually useful?

If x264 applied on its own, could you come up with 5 real, meaningful tasks in each category for it?  It might be possible, but it’d require a lot of stretching.

How many smaller or more-focused projects do you think are going to give up and not apply because of this?

Is GCI supposed to be something for everyone, or just or Gnome, KDE, and other megaprojects?

07/24/2011 (3:28 pm)

Summer of Code (in space)

Filed under: development,SOCIS ::

There’s apparently another Summer of Code in town.  x264 has been accepted into the ESA Summer of Code in Space.  Just like Google Summer of Code, work on x264 over the summer and get paid!  Watch out though; only some countries are allowed, so check first if you’re allowed to participate.  The application deadline is July 27, 11AM (UTC); sorry for the short notice this time around!

04/02/2011 (11:33 pm)

You should apply for x264 Google Summer of Code

Filed under: development,GSOC,x264 ::

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!)

12/05/2010 (3:35 pm)

Direct from the Blu-ray disc

Filed under: blu-ray,x264 ::

A MediaInfo from the Warner Brothers’ Blu-ray “The Town“:

General
Complete name : 00020.m2ts
Format : BDAV
Format/Info : Advanced Video Codec
File size : 528 KiB
Duration : 900ms
Overall bit rate : 4 745 Kbps
Maximum Overall bit rate : 15.0 Mbps
Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : 27
Duration : 1s 1ms
Bit rate mode : Variable
Bit rate : 5 000 Kbps
Maximum bit rate : 24.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.101
Stream size : 611 KiB
Writing library : x264 core 104 r1683 62997d6

(Yes, it’s just a menu. But good things start small!)

11/25/2010 (8:35 pm)

Announcing TMPGEnc 4: now with x264!

Filed under: commercial,japan,licensing,x264 ::

A few months ago, we announced a commercial licensing program so that even companies unable to use GPL software in their products have a chance to use the open source x264 instead of proprietary alternatives.  The system worked on two basic concepts.  First, all licensees would still be required to give their changes to x264 back to us: x264 must forever remain free, with no useful contributions kept hidden from the community.  Second, all the profits would go directly back to x264, primarily to the developers who’ve made the most significant contributions to x264 over the years, but also to funding future development, bounties for new features, as well as contributing to other related projects (e.g. Videolan and ffmpeg).

Over the past couple of months, we’ve gotten an enormous response; over 40 companies have inquired about licensing, with more contacting us every day.  Due to the sheer volume of interest, we’ve partnered with CoreCodec, the creators of the free Matroska container format and developers of CoreAVC, to make x264 as widely available as possible in the world of commercial software as it is in the world of open source.  All of this is already filtering back to benefiting x264 users, with many bugs being reported by commercial licensees as well as some code contributed.

Today, we announce the first commercial consumer encoding software to switch to x264: Pegasys Inc.’s TMPGEnc.  Expect many more to follow: with x264 now available commercially as well as freely, there are few excuses left to use any other H.264 encoder.  Vendors of overpriced, underpowered proprietary competitors should begin looking for new jobs.

(Pegasys press release: English, Japanese)

11/25/2010 (1:30 pm)

Patent skullduggery: Tandberg rips off x264 algorithm

Filed under: patents,ripoffs,x264 ::

Update: Tandberg claims they came up with the algorithm independently: to be fair, I can actually believe this to some extent, as I think the algorithm is way too obvious to be patented.  Of course, they also claim that the algorithm isn’t actually identical, since they don’t want to lose their patent application.

I still don’t trust them, but it’s possible it’s merely bad research (and thus being unaware of prior art) as opposed to anything malicious.  Furthermore, word from within their office suggests they’re quite possibly being honest: supposedly the development team does not read x264 code at all.  So this might just all be very bad luck.

Regardless, the patent is still complete tripe, and should never have been filed.

Most importantly, stop harassing the guy whose name is on the patent (Lars): he’s just a programmer, not the management or lawyers responsible for filing the patent.  This is stupid and unnecessary.  I’ve removed the original post because of this; it can be found here for those who want to read it.

Read More…

10/17/2010 (6:50 pm)

How to contribute to open source, for companies

Filed under: development,open source,x264 ::

I have seen many nigh-incomprehensible attempts by companies to contribute to open source projects, including x264.  Developers are often simply boggled, wondering why the companies seem incapable of proper communication.  The companies assume the developers are being unreceptive, while the developers assume the companies are being incompetent, idiotic, or malicious.  Most of this seems to boil down to a basic lack of understanding of how open source works, resulting in a wide variety of misunderstandings.  Accordingly, this post will cover the dos and don’ts of corporate contribution to open source.

Read More…

09/30/2010 (7:48 pm)

H.264 and VP8 for still image coding: WebP?

Update: post now contains a Theora comparison as well; see below.

JPEG is a very old lossy image format.  By today’s standards, it’s awful compression-wise: practically every video format since the days of MPEG-2 has been able to tie or beat JPEG at its own game.  The reasons people haven’t switched to something more modern practically always boil down to a simple one — it’s just not worth the hassle.  Even if JPEG can be beaten by a factor of 2, convincing the entire world to change image formats after 20 years is nigh impossible.  Furthermore, JPEG is fast, simple, and practically guaranteed to be free of any intellectual property worries.  It’s been tried before: JPEG-2000 first, then Microsoft’s JPEG XR, both tried to unseat JPEG.  Neither got much of anywhere.

Now Google is trying to dump yet another image format on us, “WebP”.  But really, it’s just a VP8 intra frame.  There are some obvious practical problems with this new image format in comparison to JPEG; it doesn’t even support all of JPEG’s features, let alone many of the much-wanted features JPEG was missing (alpha channel support, lossless support).  It only supports 4:2:0 chroma subsampling, while JPEG can handle 4:2:2 and 4:4:4.  Google doesn’t seem interested in adding any of these features either.

But let’s get to the meat and see how these encoders stack up on compressing still images.  As I explained in my original analysis, VP8 has the advantage of H.264′s intra prediction, which is one of the primary reasons why H.264 has such an advantage in intra compression.  It only has i4x4 and i16x16 modes, not i8x8, so it’s not quite as fancy as H.264′s, but it comes close.

Read More…

07/23/2010 (4:01 pm)

Announcing the world’s fastest VP8 decoder: ffvp8

Filed under: ffmpeg,google,speed,VP8 ::

Back when I originally reviewed VP8, I noted that the official decoder, libvpx, was rather slow.  While there was no particular reason that it should be much faster than a good H.264 decoder, it shouldn’t have been that much slower either!  So, I set out with Ronald Bultje and David Conrad to make a better one in FFmpeg.  This one would be community-developed and free from the beginning, rather than the proprietary code-dump that was libvpx.  A few weeks ago the decoder was complete enough to be bit-exact with libvpx, making it the first independent free implementation of a VP8 decoder.  Now, with the first round of optimizations complete, it should be ready for primetime.  I’ll go into some detail about the development process, but first, let’s get to the real meat of this post: the benchmarks.

Read More…

07/13/2010 (3:06 am)

VP8: a retrospective

Filed under: DCT,speed,VP8 ::

I’ve been working the past few weeks to help finish up the ffmpeg VP8 decoder, the first community implementation of On2′s VP8 video format.  Now that I’ve written a thousand or two lines of assembly code and optimized a good bit of the C code, I’d like to look back at VP8 and comment on a variety of things — both good and bad — that slipped the net the first time, along with things that have changed since the time of that blog post.

These are less-so issues related to compression — that issue has been beaten to death, particularly in MSU’s recent comparison, where x264 beat the crap out of VP8 and the VP8 developers pulled a Pinocchio in the developer comments.  But that was expected and isn’t particularly interesting, so I won’t go into that.  VP8 doesn’t have to be the best in the world in order to be useful.

When the ffmpeg VP8 decoder is complete (just a few more asm functions to go), we’ll hopefully be able to post some benchmarks comparing it to libvpx.

Read More…

Next Page »