|
I was thinking about this recently. Yes, TCP is reliable protocol, so RTMP is not the best solution for real-time streaming. But if you dig into Red5 sources you will see that it calculates a number of pending (not sent via network from Red5 to consumer) video packets and drops frames when there are pending video packets. Red5 does frame dropping for video only. Audio and data packets are sent "as is" to clients (consumers). But since video bandwidth is much larger than audio or data bandwidth, it works well in practice. One more thing that we can see with RTMP: if you compare "audio only" broadcasts with "audio+video" ones, you will see that in the case of "audio+video", the delay after saying something and hearing it at the consumer's side is bigger than in the case of "audio only". I think this is because RTMP protocol always transmits a "mixed" stream of video, audio and other packets. Quantity of video packets is much bigger than quantity of audio packets, so when sending via network, consumer should wait more time before "grabbing" these audio packets from network. That is video and audio is synchronized in RTMP. Victor Srinivas Palthepu wrote:
|
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
