joel benm · Jan 29, 2011 at 09:26 PM ·
Explaining and fighting RTMP delay?
We need to stream from a secured environment behind a firewall so our only choice is RTMP (no UDP out, only TCP). Client requires that we have to have a delay of around 500ms max. we are working either in rtp-live stream type or live-lowlatency.
From our many tests in the lab, RTMP always carries 1.5 seconds delay for each side. So if we broadcast camera --> encoder --> RTMP --> Wowza --> RTMP --> Flash viewer, we get 3 seconds delay.
If we change the broadcasting side to RTP (camera --> encoder --> RTP --> Wowza --> RTMP --> Flash viewer), delay drops to 1.5 seconds.
If we change viewer to rtp (camera --> encoder --> RTP --> Wowza --> RTP --> VLC viewer) we have almost no delay.
anyone can explain that? how come Skype works so nicely (behind the firewall it resorts to TCP, too) with almost no delay?
Another thing to look at is the video format that you are using. The best for lowest latency but not necessarly quality is the standard format that flash sends video in. In flash, it is Sorensen Spark which under the hood is almost the same format that skype uses (h263). The reason that this is used is because it is fairly easy to encode and decode on most hardware.
When you start using h264, you get a lot better quality for the same bandwidth but the big trade off is the encoding and decoding at each end is very processor intensive.
Vlc and skype are both designed and built to to do specific tasks with video & audio whereas flash is designed to do a lot of other tasks and video is only a recent addition and is added to the other tasks that flash can do. The advantage is that you can do a lot more with flash than you can with skype or vlc.