Live Streaming from a Notebook

Article Featured Image

Then I reproduced the test using a high motion HD file encoded at 1.5Mbps, counting peaks over 2 mbps and peaks of three or more samples, with the results presented in table 4. Note that Bitrate Viewer crashed when I imported the file produced by EE4, so only the other three encoders are presented in Table 6.

HD File

Peaks over 2Mbps

Total samples

Peaks with 3 or more samples













Table 6. Measuring the data rate consistency of the HD streaming file.

Here we see that Wirecast again exhibits the most issues, with FMLE and Kulabyte about even, and none of the encoders producing peaks longer than three samples.

Next I checked to see if the bitrate histogram in Aviddemux ( could shed any light on the debate, inputting solely the 640x480 file. Note that Avidemux can't read the .ismv files produced by Expression Encoder, so Figure 6 shows only the other three encoders. 

Ozer Notebook Figure 6

Figure 6. Bitrate histograms from Avidemux.

To explain, on the left are the various data rate categories used by Avidemux to analyze the file, which unfortunately aren't the same for the three files. Since the range measured by the tool varies for the three files, the number of categories that contain actual samples is irrelevant. The only piece of hard evidence that we can draw from the tool is that Kulabyte's data rate range is slightly more compact than the other tools (Table 7).


Data Rate Range


130 - 1560Kbps


160 - 1440Kbps


120 - 1560Kbps

Table 7. Data rate range of the files as measured by the Avidemux bitrate histogram.

Still not convinced that I knew which encoder produced the most consistent stream, I connected the three RTMP capable encoders to the RTMP server graciously supplied by Powerstream that I used throughout my tests. Then I broadcast a 20-minute ballet video at 600Kbps, and measured the outgoing bandwidth with NetLimiter. Figure 7 shows the results for FMLE, Kulabyte and Wirecast over a twenty-minute test. 

Ozer Notebook Figure 7

Figure 7. Outgoing bandwidth as measured by NetLimiter3.

The combined audio/video data rate of 600Kbps should put the average just at the 75 KB/second line highlighted in each graph. As you can see, all of the encoders had periods of extremely low throughput followed by bursts that were limited by the outgoing peak bandwidth of between 800-900Kbps. When I compared a data rate graph of the files archived during the event, I saw no correlation, and realized that I was testing the consistency of my outbound bandwidth, not the consistency of the encoded stream.

What to take from all this? First and foremost, recognize that the streams produced by these tools are not a flatline, and you should leave as much headroom as possible between your target data rate and outgoing bandwidth to avoid data rate spikes that stop the stream. Second, you might try a test with NetLimiter before your event to get a sense of the consistency of the outbound bandwidth. If it looks like what you see in Figure 7, I'd be even more conservative regarding my data rate.

Third, it appears that Wirecast may produce a stream that's less consistent than the other tools, so I'd be even more conservative when broadcasting live with Wirecast over limited outgoing bandwidth connections. I'd say the same about Kulabyte, but to a lesser degree, and feel most confident about FMLE's ability to produce a stream that stays at or near the target. 

Output Quality
When it comes to output quality, I had several questions that applied to each tool. First, did stream quality vary based upon the CPU used to produce it; second, for those tools that could produce adaptive streams, did quality vary significantly between streams produced singly, and those produced with other streams. Then, of course, is the overall question about how quality compared between the tools, and finally how quality compared to a hardware encoder.

For the Adobe Flash Media Encoder, I compared the streams produced by the high power 8740w and less powerful 8710w-and I found them visually very similar, and that they shared the same frame rate and data rate. So long as you run the software on a system powerful enough to produce the desired streams without dropping frames, the quality should be as good as it gets.

Incidentally, you can't play archived files produced by the FMLE in their native state, because they're created as "fragments" or "moof atoms." To convert the files into a format you can play, use the intuitive, Windows-only command line tool available here, which worked well in my tests.

I also wondered how files created by Expression Encoder 4 compared between the 8740w and 8710w and found that they shared the same 29.97 frame rate and were subjectively identical in appearance. Importing the files into Premiere Pro on the Mac to run this comparison was again an issue, as Premiere Pro can't read a native .ismv file.

There is a utility called mp3split that supposedly can convert the .ismv file into an .MP4 file that you can track down here, but that didn't work for me. Instead, I loaded the files I wanted to compare subjectively into Expression Encoder 4 and output in VBR quality mode, with quality set to 100, which produced very high quality replicas in .MP4 format for my quality comparisons.

I only tested Kulabyte on the 8740w, so there were no inter-computer quality comparisons needed. Regarding the quality of the adaptive stream, I compared the 640x480 test file produced solo with the 640x480 file created when encoding three streams simultaneously, and found them visually identical. As mentioned, though Kulabyte dropped some frames at the start of both clips, the overall frame rate as measured by MediaInfo and Bitrate Viewer was 29.97. Clearly, Kulabyte was the most powerful and efficient program in the review. 

With Wirecast, I compared the quality produced by all three platforms and found them very, very close. Then I compared the quality of a file produced when encoding a solo stream with that produced when encoding multiple streams, and found some differences in frame rate, but not in visual quality. That is, when I compared the frame quality of a single stream to the identically configured stream created as part of the three-stream adaptive encoding run, I saw no difference.

On the frame rate side, Table 8 tells the tale and is consistent with what we saw in our HD trials; that is, Wirecast tends to degrade the frame rate when the going gets tough, but not visual quality. In our tests, which were reasonably aggressive, the drop in frame rate would be unnoticeable. 

SD Frame rates on 640x480 file

Single stream

One of 3 adaptive streams

HP 8710w



MacBook Pro



HP 8740



Table 8. Effective frame rate when producing single and multiple streams. 

Streaming Covers
for qualified subscribers
Subscribe Now Current Issue Past Issues