As you may know I have been flirting with live broadcasting on Ustream for a while now. While it is a great free service I was not particularly happy about the default webcam stream, which appears to be very low resolution, not much higher than 320×240. Ustream offers high quality streaming using their browser plugin and even high definition-like using the Flash Media Live Encoder from Adobe. Unfortunately, neither of these is available for anything else than Windows.
I wanted to try so much that I even tried the Flash Media Live Encoder under Vista. Well, it was a total fail… My computer froze after broadcasting a few seconds even at VGA-like resolutions. I think I spent a whole Sunday trying various configurations and setting but no luck. Slow computer? Buggy software? Probably both.
Few days ago I learned that Adobe is now in the process of making a Mac version of Flash Media Live Encoder. Hurray! In fact, it is already available for selected beta testers but no timeline for public release. Fortunately, I was able to find a kind soul who has shared the beta package for Mac with the rest of the world (thanks Google search for finding me this) and so I got the opportunity to become an unofficial beta tester.
In the following I summarize the results of my experiments with running the Adobe Flash Media Live Encoder on my iMac 2.93 GHz Intel Core 2 Due with 4 GB memory. The specs are important because even though I had no unnecessary applications running I could not properly broadcast 1280×720 @ 25 fps. Backing down to 854×480 @ 20 fps was on the other hand very good.
The setup
I had a simple studio setup using Camtwist containing a pre-recorded video, a static image and a text overlay. The output from Camtwist was read by Flash Media Live Encoder which was streaming to Ustream. Ustream provides an XML file for the show you are about to broadcast. When you select Broadcast now on your Ustream show page it will automatically detect that you are using Flash Media Live Encoder and you will not be able to select any other video or audio source.
For audio I have created a hardware loopback from the phone out to line in – apparently it works very well.
HD Experiment 1.16
This was my very first attempt on 16 January 2010. I was streaming a pre-recorded video in 1280×720. Since it was my very first attempt I didn’t pay any attention to the statistics and didn’t notice until the end that the broadcast itself was lagging very much behind the encoding – several minutes. I didn’t realize that until I prematurely terminated the broadcast. So this experiment was a complete failure. If you insist you can watch the recording (which is still quite okay) here.
HD Experiment 1.18.1
This was improved attempt at broadcasting in 1280×720 @ 25 fps carried out on 18 January. Bitrate was set to 2000 kbps video and 48 kbps audio. Local recording was turned off to save every possible CPU cycle.
The streaming statistics are shown below. As you can see, many frames were dropped
I noticed already during the broadcast that something was wrong. I tried to monitor the stream using a second computer and it was dropping off all the time at 10-20 second interval. I knew that it couldn’t be my bandwidth since I have 10 Mbps up/down so it must have been the encoding/broadcasting itself.
This time I tried not to terminate the broadcast prematurely. The complete broadcasting took about 18 minutes; however, the actual content length was no more than 12 minutes, see the recording below. You may notice the quality improvement in the embedded player; but try to switch to full screen!
HD Experiment 1.18.2
This was the second attempt on 18 January, where I decided to reduce the resolution to 854×480 and the framerate to 20 fps. I left the bitrate at 2000 kbps for video and 48 kbps for audio. Camtwist was still generating a 1280×720 stream.
With these setting it was much better. I could monitor my broadcast using a second computer without any disruption for the whole duration of the broadcast. The streaming statistics still look a bit disappointing with low average framerate and many dropped frames.
Fewer dropped frames than before though, but you may wonder how come the output framerate is lower than when transmitting 1280×720? Well, my theory is that during the 1.18.1 test I had to let it broadcast for 6 extra minutes because I didn’t want the broadcast to terminate prematurely. This means that the last 6 minutes consisted of a static image, which clearly improves the framerate statistics (doesn’t take much to encode a static image). I think this is why the average framerate at the end is higher than when broadcasting at lower resolution.
And finally, here is the recording at 854×480.
All in all I consider the experiment a success! I now have the setup to broadcast in high quality and even high definition if I get a faster Mac. You better stay tuned for high quality live broadcast anytime soon!