Diary Of An x264 Developer
Les articles publiés sur le site
-
The neutering of Google Code-In 2011
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?
-
Summer of Code (in space)
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!
-
You should apply for x264 Google Summer of Code
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!)
-
Direct from the Blu-ray disc
A MediaInfo from the Warner Brothers’ Blu-ray “The Town“:
GeneralComplete name : 00020.m2tsFormat : BDAVFormat/Info : Advanced Video CodecFile size : 528 KiBDuration : 900msOverall bit rate : 4 745 KbpsMaximum Overall bit rate : 15.0 MbpsVideoID : 4113 (0x1011)Menu ID : 1 (0x1)Format : AVCFormat/Info : Advanced Video CodecFormat profile : High@L4.0Format settings, CABAC : YesFormat settings, ReFrames : 3 framesCodec ID : 27Duration : 1s 1msBit rate mode : VariableBit rate : 5 000 KbpsMaximum bit rate : 24.0 MbpsWidth : 1 920 pixelsHeight : 1 080 pixelsDisplay aspect ratio : 16:9Frame rate : 23.976 fpsColor space : YUVChroma subsampling : 4:2:0Bit depth : 8 bitsScan type : ProgressiveBits/(Pixel*Frame) : 0.101Stream size : 611 KiBWriting library : x264 core 104 r1683 62997d6(Yes, it’s just a menu. But good things start small!)
-
Announcing TMPGEnc 4 : now with 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.
