[Red5] Red5: audio and video out of sync resolved!
daccattato at gmail.com
Sat Nov 24 10:05:58 PST 2007
As far as I know, these video/audio packets are intertwined at the interval
that they are recorded at. Also, I would think that the Flash Player
eventually receives all video/audio packets because the connection is over
TCP. So it's not that video frames aren't sent. It's more believable that
the FlashPlayer skips video frames to maintain the framerate. So anyway, I
haven't checked in a while but there are usually a two audio tags for every
video tag that is sent down to the Player. The reason is that the audio
tags are in 64kb chunks as compared to video which comes down in 128kb
chunks. Anyways, I'm not sure if reordering tags would make much of a
difference because the Flash Player buffers all these tags and tries to play
them at the framerate specified. A few things you could try is setting a
larger buffer on the client stream and also make sure other parts of the
application aren't affecting performance. I would imagine that the
performance of the player could affect how many frames of video it can
decode. So I would also assume that a smaller video would need a smaller
buffer. This stuff all seems like common sense though. So, yes I'm also
interested in the same thing Steven asked. How are you managing to change
the packet order. Also, please remember that if you have changed packet
reading code on the server, this code should be donated back to the
On Nov 24, 2007 11:08 AM, Naicu Octavian <naicuoctavian at gmail.com> wrote:
> Alo you must take into account that audio data has a higher priority than
> video data over a rtmp connection.That's why you might get only just a few
> video packets and most (if not all) audio packets over a slow connection.
> Naicu Octavian,
> Project Manager for AVChat
> On 24/11/2007, Oleg Kolokolov <scanwork1 at gmail.com> wrote:
> > Hello Red5 community,
> > It is more like a suggestion for the Red5 developers.
> > We noticed while working with Red5 on our project ( www.blipback.com)
> > that when recording on a slow connection you may get a recorded FLV where
> > audio and video are out sync badly.
> > When such FLV is played back (no matter streamed from some remote
> > location or downloaded and played locally)
> > it looks like audio goes normally but video is very slow and out of sync
> > and sometimes can even stuck for quite a time.
> > We checked and figured out that in the incoming stream in
> > such cases mostly audio packets arrive in the beginning
> > and then video packets arrive with a huge delay.
> > And the problem (as we understand it) is that Red5 just saves this incoming stream in this same order.
> > So when Flash plays back such FLV it gets the packets in the same order.
> > So what it has - mostly audio packets in the beginning and plays back them normally but has no video packets to
> > display and waits until they arrive so we see a frozen first frame or the
> > last that arrived.
> > This can be resolved on the client side (Flash
> > player made so that it can resolve this) but for this the whole stream must
> > be downloaded first. We think in this case Flash player does this reordering
> > of the packets in memory and then plays it back. But this reordering takes
> > time. That's bad because you must first wait until the stream is
> > downloaded and then until it is processed in Flash
> > player (which looks like hanging for a while).
> > What we made in blipBack.com is modification of Red5 to reorder incoming
> > packets in real time and save FLV already fully prepared to playback.
> > May be it makes sense to add this modification to next rev of Red5?
> > I wonder does Adobe Media Server do this? Seems so ...
> > Regards,
> > Oleg
> > _______________________________________________
> > Red5 mailing list
> > Red5 at osflash.org
> > http://osflash.org/mailman/listinfo/red5_osflash.org
> Red5 mailing list
> Red5 at osflash.org
Dominick Accattato, CTO
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Red5