x264不只能用于离线的2pass编码，用于实时编码也同样优秀。

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.

这个夏天我在Avail Meida工作，这是一个较小的IPTV公司，主要为需要架设IPTV和VOD服务的小电讯公司提供有偿服务。Avail独特的一个地方是他们不用硬件编码器，而是
使用x264。当然他们不是唯一使用x264的公司，可是，虽然google和facebook也用，但是他们都没有把x264用于实时高清编码。Avail,正如Loren Merritt所在的公司那样，

正致力于x264中与电视广播相关的特性，比如交错编码。
 
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.

广播用到的编码方式有其自己的难点，使得它比非实时编码更有挑战性。首先，编码必须是实时的，对于1080i的输入，这是具有挑战性的。Loren和我专门为此打了一个补

丁，叫“速度控制”，它会自动配置x264后以制定的编码速度进行编码，甚至可以与前端通信以获知还剩余多少时间可用于编码。

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.

另外一个问题是VBV，编出来的流必须遵循缓冲区的大小，不然就会丢包，损坏视频流。这是一个很难的问题，可以想像一下x264的的VBV，特别是1pass模式时，并不是很符

合要求的。来Avail之前我就研究过这个问题。从Joost过来的Gabriel也花了很多时间来研究他的2pass VBV补丁，他也同时改善了1pass模式的VBV码率控制。
 
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.

最大的问题是视频源的画面质量不好。大多数输入是18兆的恒定码率MPEG-2码率，这样的输入的视频质量较低，以至于无法用DIA/HEX这样的移动搜索算法。这是因为那些需

要充足的运动搜索的画面，来的时候就已经是块状的了。重新编码成6~7兆的h.264码率无法改善画面质量。这些糟糕的输入造成了很多帧内编码的宏块，使得码率控制更加

困难。加上x264在交错编码方面不足的表现，使得这个情况更加糟糕。
 
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.

尽管如此，Avail还是搞定了。我们取得的丰硕成果再次证明x264不只能用于离线的2pass编码，用于实时编码也同样优秀。