And this time they're using x264; it seems like they value their bandwidth!
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.
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:
I pick a constant bitrate of 500kbps. (bitrate=500)
I set the maxrate to 500. (vbv-maxrate=500)
I set the bufsize to 500x2 = 1000. (vbv-bufsize=1000)
If the buffer in the encoder is greater 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).
Another issue to note is latency. Total latency in a connection is as follows:
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.
Actually we don't have any bitrate limitations. I've seen users push 8mb streams before, but most people chose lower bitrates because very few viewers have the bandwidth and CPU required to enjoy those streams.
You make a very good point about VBR, thanks for bringing that up!
Does Justin.tv have a non-Flash way of viewing streams? While creating one without Flash is awesome, it's still annoying to have Adobe's horrible Flash implementation crash (and or bloat) watching two-three hour streams.
We already had several ways to broadcast from Windows and OS X, but no way to broadcast from Linux. Given that, it made sense to make this available as soon as the Linux version was ready, without waiting to work all of the bugs out of the Mac version.
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.
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:
I pick a constant bitrate of 500kbps. (bitrate=500)
I set the maxrate to 500. (vbv-maxrate=500)
I set the bufsize to 500x2 = 1000. (vbv-bufsize=1000)
If the buffer in the encoder is greater 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).
Another issue to note is latency. Total latency in a connection is as follows:
(Encoder-side latency) + (Network latency) + (Decoder buffer size)
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.