And this time they're using x264; it seems like they value their bandwidth!<p>One thing that should be better-documented are Justin.TV-side bitrate restrictions; I assume that they don't want users broadcasting 1-2 megabit DVD-quality streams over their network, but nothing of the sort is listed in the guide.<p>Additionally, there's the matter of constant bitrate requirements: H.264 streaming works under a leaky buffer model based on two parameters, the rate and buffer size. For optimal performance Justin.TV should document what buffer size they set on the viewers' Flash players so that the encoder settings can be set accordingly. For example, let's say that Justin.TV uses a 2 second buffer:<p>I pick a constant bitrate of 500kbps. (bitrate=500)<p>I set the maxrate to 500. (vbv-maxrate=500)<p>I set the bufsize to 500x2 = 1000. (vbv-bufsize=1000)<p>If the buffer in the encoder is <i>greater</i> than that used by Justin.TV, it's possible for the stream to drop out for viewers during local bitrate spikes, so getting it right is important, especially at higher bitrates (at 300kbps you probably don't have to care much).<p>Another issue to note is latency. Total latency in a connection is as follows:<p>(Encoder-side latency) + (Network latency) + (Decoder buffer size)<p>x264's default encoder-side latency is about 40 frames in the latest version; if anyone's interested in how to lower that for a low-latency stream, I can give more information.