Hi Guys,

  In red5 source code I found that channels are assigned by one per stream.
The audio and video of one stream is mixed in one channel. In slow network
the problem of this strategy is that a big video packet (as I saw the
typical video size is around 20k for a key-frame) will block small audio
packets (usually 60 bytes).

  This is a dump of packets I get from a published stream:

  Video size: 19777 dt 268
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Video size: 2876 dt 219
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30
  Audio size: 69 dt 30

 So you see video and audio are quite different, video packets are big and
less. In a live stream the subscriber care less about the continuous of the
video, instead he may be more interested in seeing the most recent image.
For audio the subscriber cares the continuous of the audio, he want to hear
the audio all the time, missing 1~2 seconds audio badly hear the
understanding of the subscriber. A delay less than 2 seconds is always
acceptable as long as the delay is pretty much fixed.

 Any idea on this?
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org

Reply via email to