Jun 20 2003

Flash Communication Server MX and RTMP Data Flow

Published by at 11:57 under Wayback Archive

Flash Communication Server MX and RTMP Data Flow Rules, it it something that pops up regularly on mailinglists and in discussions that I have with customers. Pritham Shetty from Macromedia posted some very good information about these Data Flow Rules on the Flashcomm mailinglist. I thought it would be usefull to repeat it here:

Some background before going into the rules.

There are 3 kinds of data flowing over RTMP:

  1. Audio
  2. Video
  3. Data (Netstream.send, Netconnection.call, and SO messages)

Priority of message is as follows (Highest to lowest)

  1. Audio
  2. Data
  3. video

Above priorities are true only for live messages. If you are playing back an FLV file all messages have the same priority.

What is dropped?

  • Live:
    • Data messages are never dropped.
    • Audio messages are dropped based on the stream buffer length set. If audio latency goes over the buffer length set than all messages are dropped to catch up. Default buffer length is 8 seconds in FCS 1.5.
    • Video messages can be of 3 types: key frame, intermediate frame or droppable frames. If we get a key frame and live is behind all video messages in the queue are dropped.
  • Recorded:
    • Audio and data messages are never dropped.
    • Only droppable video frames are dropped if the client cannot keep up.

Also, a NetConnection can have multiple NetStreams. All streams have equal priority but messages within the stream are prioritized as mentioned above.

SharedObject and NetConnection.call messages use a separate stream and the priority of the stream is same as the user created NetStream.

Since data messages are never dropped in a live situation server takes some precautions against data message queues getting very long on the server for a specific client by closing the connection. Decision to close is based on current system memory usage and total bytes in the queue ( greater than 1MB and less than 10MB).

I am confident that this gives you some more insight into the inners of the server and helps you better understand what is going on when debugging your Flash Communication Server MX applications.

No responses yet

Comments are closed.