Hi all, I'm working on building some architecture for a live streaming environment. I'm seeing two main issues with the setup that I have built so far. Latency and audio/video being out of sync. The video is about 17 seconds out of sync, and the audio is about another 15 seconds behind that. So I'm hoping someone might have some suggestions on what I could be doing better.
sending out one bitrate of 1500k, of h264 720p video with aac stereo audio running at 44100hz and 192k. FMLE says this comes to a total of 1692kbps output.
That stream goes to server A which is an 8x2.66Ghz softlayer dedicated box with 12GB Ram, running Wowza on Solaris 10u9, running the 'live' application with the following changes made:
Then I have ffmpeg on server B which connects to the stream on server A. Server B is a 16x2.0Ghz
softlayer.com cloud instance with 8GB ram running ubuntu 10.04 lucid. ffmpeg then reads the stream and transcodes 3 streams out, 720p @ 1500kbps, 480p @ 800kbps, and 350p @ 400kbps. All audio streams remain at 44.1/192k. These streams are all sent to server C.
(If you want to see the config/build info and the command line i'm using for ffmpeg, you can refer to the following post:
http://pastebin.com/nNziQ7U1 I'd paste it here, but I don't want to cause a whole ton of clutter in the post, so I thought I'd better reference it externally.)
Server C is an 8x2.66Ghz softlayer dedicated box with 12GB Ram, running Wowza on Solaris 10u9. It accepts the streams from ffmpeg.
Server D, which has the same specs as server C and A, is running apache and hosts a page with the jw player on it. It also hosts an xml file for the stream information. the php page with jw player loads, referencing the xml file for the stream information, and the stream is displayed on the client web browser.
So, that's the setup.
The idea is to keep the setup and configuration easy, and required bandwidth low, for the broadcast side, yet still support multiple streams for dynamic streaming, which will give the end user the best quality and bitrate that their connection will allow. I'm using multiple servers because I've read that it is advisable to separate the ffmpeg transcoding process from the wowza hosting process. I'm also separating the apache hosting process as well.
But again, the issue is that the audio and video streams are not in sync, and the latency is very high. 17 seconds to 35 seconds.
Using a publish-transcode-publish model is going to introduce a lot of extra latency just by sheer necessity, once you aggregate each server's buffer time, as well as the time it takes to actually do the transcoding.
It's also possible to do this with a single Wowza server - publish to server A, transcode with ffmpeg, and publish back to different stream names on the same application. If using it as a repeater origin, you could probably do it on the same box, eliminating some network latency.
With version 3.0, the transcoding will be able to happen internally to Wowza.