Diary Of An x264 Developer

05/29/2008 (9:32 am)

Working at Avail Media

Filed under: avail,development,x264 ::

As some of you know, this summer I am living in Kalispell, Montana and working at Avail Media, a relatively small broadcast/IPTV company that caters primarily to smaller telecomms looking to set up IPTV and VOD services for reasonable prices. What’s unique about Avail, however, is that they don’t use hardware encoders; they use x264! They’re definitely not the only company using x264–other notable users include Google and Facebook–but I know of nobody else using x264 for live HD television. As the company which Loren Merritt (pengvado) worked for, they are responsible for quite a number of x264′s broadcast-related features, such as its interlaced encoding support.

Of course, broadcast has its own difficulties that make it much more of a challenge than ordinary offline encoding. For one, encoding has to run in realtime, quite a challenge when dealing with 1080i input. This is assisted by a patch written by Loren and improved by me, “speed control,” which automatically reconfigures x264′s settings on the fly to run at exactly the specified speed. It even communicates with the encoding/muxing frontend to know exactly how much time it really has left.

Another major issue is that of the VBV; the stream must strictly obey the buffer size or else packets might end up being dropped, corrupting the video stream. This is a hard problem, considering that x264′s VBV, especially in 1pass mode, is not very compliant. This has been a repeated subject of research by me even before I came here. Gabriel from Joost has also spent quite a bit of time on it in the form of his 2pass VBV patch, which in its latest form also improves 1pass VBV ratecontrol.

The biggest issue is the quality of the sources one comes across in broadcast–or better stated, the lack thereof. Much input is in the form of 18 megabit CBR MPEG-2 streams which are of such low quality that motion search above DIA/HEX is nearly useless. This is because in any scene with sufficient motion to require a complex motion search, the stream has already gone completely blocky. Re-encoding to 6-7 megabit H.264 doesn’t make it much better, either! This mess of input also results in a very large percentage of intra blocks in the output, which makes ratecontrol that much more difficult. Add this to the relative inefficiency of x264′s interlaced encoding and things get even worse.

Yet despite the difficulties of broadcast, Avail has managed to get it to work; quite an amazing accomplishment, proving once again that x264 isn’t just for ordinary offline 2pass encoding.

6 Responses to “Working at Avail Media”

  1. bobby Says:

    I am working on a real-time compression project and I’m looking into X264.

    The “speed control” is is very interesting.
    How do you access this “speed control”?
    What do you put in the configuration?

    I have the x264-snapshot-20080514-2245
    is it avaiable in this release?


  2. Dark Shikari Says:

    It is an internally developed patch, though we may make it public at some point. It isn’t in x264 trunk. Its quite easy to use–the API exposes a speedcontrol_sync function which can be used by the program calling libx264 to update x264′s buffer information, and a “speed” factor is set in params to imply a specific fraction of realtime encoding speed.

  3. brunogm Says:

    I’m working with broadcasting in Brazil for the DTV system that requirements are L4.0 20mbps 1080i. After consulting with Ateme ant 20k tag. really appreciate some tips on using x264 for realtime 1080i.

  4. skittle Says:

    kalispell ehh? Skittle lives in bozeman!
    Hope the whether is nice up there. We just got 2 more inches of snow.

  5. Leo Says:

    Amazing work, Dark Shikari!
    Are you using x264 as a DS filter?
    Do you also perform the real-time muxing in software only?

  6. Dark Shikari Says:

    Yes, muxing is done in software.

    All the servers run Gentoo, so no DirectShow here–we call libx264 as a library.

Leave a Reply