[Red5] Try this patch for jittery/latent video?

Gavriloaie Eugen-Andrei crtmpserver at gmail.com
Mon Jun 22 00:11:50 PDT 2009


OK, there seems to be a problem with the link I gave you. If I click  
it in mail, it doesn't work. If I manually copy the link works but not  
always. So I decided to copy paste it here


[osflash] Audio/Video synchronization research results

Chris Allen mrchrisallen at gmail.com
Fri Jul 20 17:47:16 EDT 2007

Previous message: [osflash] Audio/Video synchronization research results
Next message: [osflash] high quality video
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Eugen-Andrei,

Thanks for the info. In the future you may want to post Red5 specific
stuff on the Red5 mailing list. I'm including it on this response as
this looks like a significant piece of information on how to resolve
some syncing issues.

You can sign up for the Red5 mailing list here:
http://osflash.org/mailman/listinfo/red5_osflash.org

-Chris

On 7/20/07, Eugen-Andrei Gavriloaie <shiretu at gmail.com> wrote:
 > New discoveries:
 >
 > 1. The brand new flash beta player doesn't send any absolute  
timestamps
 > anymore while is publishing a composite audio/video stream. This is  
my
 > opinion, so is not 100% sure, But this is what I've discovered from  
my
 > experiments.
 > 2. I've discovered that flash has a crappy access time to the  
majority of
 > the video sources. Especially webcams (tested with 6 different  
webcams on
 > windows and 2 on linux). AMCAP manages to put them in 640x480 at  
30fps but
 > flash plugin doesn't. To grab a video packet out of a regular USB  
webcam,
 > flash is spending between 30 and 60 milliseconds. Add to this the  
time to
 > grab an audio packet which is between 30 and 40 and you get a value  
around
 > 100 milliseconds spent by flash to get a hold of a complete audio/ 
video
 > frame (is not doing audio/video grabbing in separate threads). That  
is
 > between 9 and 15 (the best case scenario) fps. Crappy! without  
sound, the
 > things are a little bit brighter. Also linux is a little bit faster  
at
 > grabbimg packtes out of the audio video sources.
 > 3. FME works at another level with USB webcams. It manages to  
obtain a very
 > fast access between 0(I've seen that, maybe is something wrong with  
the
 > header sent by the FME) and 20 milliseconds. Verry good. That is  
why FME is
 > capable to achieve high fps rates.
 >
 >
 > Regarding our problem of audio/video sync:
 >
 > Ibrahim . did you managed to look over the red5 sources in
 > src/org/red5/server/stream/consumer/ConnectionConsumer.java?
 > IMHO this chunk of code:
 >
 > if (timestamp < 0) {
 >  log.warn("Skipping message with negative timestamp.");
 >  return;
 >  }
 >
 > is completely wrong. Is executed each time a video or audio packet  
hits the
 > red5 server. It shouldn't! Audio/video frames is supposed to be  
dropped only
 > for the sake of synchronization, but not all the time. Only at the
 > beginning. Like FMS does. after that no frames are dropped  
whatsoever! With
 > the new version of flash player (no more absolute time stamps) red5  
gets
 > lucky, because that condition is very rarely full filled.  But is  
only luck.
 > Unfortunately I don't have time to make a patch as I've promised you
 > yesterday, but I'll implement my algorithm in my c++  
implementation, and
 > I'll make it public for red5 users. So, when you have time, please  
contact
 > me
 >
 > On 7/19/07, Eugen-Andrei Gavriloaie <shiretu at gmail.com> wrote:
 > > Forgot to attach the file... Sorry
 > >
 > >
 > >
 > > On 7/19/07, Eugen-Andrei Gavriloaie < shiretu at gmail.com> wrote:
 > > > Finally I can get back to work! First of all I'll send you the  
results
 > of my research so we can comment on them
 > > >
 > > > You have 2 analyzing results:
 > > >
 > > > 1. traffic between fms and flash
 > > > 2. traffic between red5 and flash
 > > >
 > > > The tests were made as follows:
 > > >
 > > > one client is making a publish on the server (red5 or fms) and  
one
 > client is consuming the stream published by the first client.
 > > >
 > > > The columns starting with a_* are for the publisher. In those  
columns
 > I've putted the packets sent by the publisher to server (red5 or fms)
 > > > The columns starting with b_* are for the player. In those  
columns I've
 > putted the packets sent by the server(red5 or fms) to the player
 > > >
 > > > Some rows have NULL on b_* columns. That is because the  
publisher sent
 > the packet but the server did't sent it further to the player  
because the
 > player wasn't yet connected or whatever reason (including the bug  
in red5).
 > ignore a_id and b_id, they have no meaning in our discution.
 > > >
 > > > The other columns are as follows:
 > > >
 > > > *_content_size is the length in bytes of the payload (excluding  
the
 > header)
 > > > *_message_type is the type of the message transfered (either  
audio or
 > video)
 > > > *_payload are the first 10 bytes from the payload
 > > >
 > > >
 > > > The red5 problem:
 > > >
 > > > If you look at the traffic between fms and flash you can see  
that after
 > a few audio/video packets are dropped at the beginning, no more  
packets are
 > dropped. In red5-->flash traffic, ALL KEYFRAMES ARE DROPPED!!!
 > > >
 > > > My problem:
 > > >
 > > > I just want to understant the logic behind those timestamps  
and  why
 > some timestamps are relateiv and some are absolute. How should I  
handle
 > them? Any clue?
 > > >
 > > >
 > > > Thank you so much for your interest!
 > > >
 > > > PS:
 > > > You can reach me via gtalk too if you want a more interactive  
discution,
 > or you can tell me what IM client you use along with your ID.
 > > >
 > > >
 > > >
 > > >
 > > >
 > > >
 > > > On 7/4/07, Ibrahim Y <ibwq85 at gmail.com> wrote:
 > > > > okay, Thanks.
 > > > > and Good luck in your exams.
 > > > >
 > > > >
 > > > >
 > > > > On 7/1/07, Eugen-Andrei Gavriloaie < shiretu at gmail.com>  
wrote:
 > > > > > Hi,
 > > > > >
 > > > > > Thank you for your attention! And sorry for the delay! I  
have a few
 > more days to endure my diploma exam and after that I'm free :). I  
will keep
 > you up to date
 > > > > >
 > > > > > Thank you again
 > > > > >
 > > > > >
 > > > > >
 > > > > > On 6/23/07, Ibrahim Y <ibwq85 at gmail.com> wrote:
 > > > > > > Hello,
 > > > > > >
 > > > > > > how can I help or contribute ?
 > > > > > >
 > > > > > > thanks,
 > > > > > > Ibrahim
 > > > > > >
 > > > > > >
 > > > > > >
 > > > > > > On 6/3/07, Eugen-Andrei Gavriloaie <shiretu at gmail.com>  
wrote:
 > > > > > > >
 > > > > > > >
 > > > > > > > Hi,
 > > > > > > >
 > > > > > > > Based on the great work of the osflash contributors, I've
 > managed to develop a RTMP server written entirely in C++. But, like  
you
 > guys, I have some audio/video synchronization problems. So, I've  
started
 > analyzing following flows:
 > > > > > > >
 > > > > > > > Flash->FMS (publishing)
 > > > > > > > FMS->Flash(player)
 > > > > > > >
 > > > > > > > The results of the tests are now safe in the database  
and I
 > assure you they are very useful. They match the Flash->FMS audio/ 
video
 > packets with the FMS->Flash packets side by side. Now I need your  
help guys
 > to get this thing working once and for good. BTW... fms DOESN'T  
drop any
 > frames!!! FMS compute the delays of the video packets from time to  
time. The
 > audio packets remains untouched!!!
 > > > > > > >
 > > > > > > > Please, let's work together on this issue and solve it.  
I'll
 > make a database export and make it available to who is interested  
in this
 > matter.
 > > > > > > >
 > > > > > > >
 > > > > > > >
 > > > > > > > --
 > > > > > > > Andrei Gavriloaie
 > > > > > > > ____________________________________________
 > > > > > > > Programmer
 > > > > > > > SQSG (www.sqsg.ro)
 > > > > > > > e-Mail: shiretu at gmail.com
 > > > > > > > Mobile:+40722537658
 > > > > > > > _______________________________________________
 > > > > > > > osflash mailing list
 > > > > > > > osflash at osflash.org
 > > > > > > >
 > http://osflash.org/mailman/listinfo/osflash_osflash.org
 > > > > > > >
 > > > > > > >
 > > > > > >
 > > > > > >
 > > > > >
 > > > > >
 > > > > >
 > > > > > --
 > > > > > Andrei Gavriloaie
 > > > > > ____________________________________________
 > > > > > Programmer
 > > > > > SQSG ( www.sqsg.ro)
 > > > > > e-Mail: shiretu at gmail.com
 > > > > > Mobile:+40722537658
 > > > >
 > > > >
 > > >
 > > >
 > > >
 > > > --
 > > > Andrei Gavriloaie
 > > > ____________________________________________
 > > > Programmer
 > > > SQSG ( www.sqsg.ro)
 > > > e-Mail: shiretu at gmail.com
 > > > Mobile:+40722537658
 > >
 > >
 > >
 > > --
 > > Andrei Gavriloaie
 > > ____________________________________________
 > > Programmer
 > > SQSG ( www.sqsg.ro)
 > > e-Mail: shiretu at gmail.com
 > > Mobile:+40722537658
 > >
 >
 >
 >
 > --
 > Andrei Gavriloaie
 > ____________________________________________
 > Programmer
 > SQSG (www.sqsg.ro)
 > e-Mail: shiretu at gmail.com
 > Mobile:+40722537658
 > _______________________________________________
 > osflash mailing list
 > osflash at osflash.org
 > http://osflash.org/mailman/listinfo/osflash_osflash.org
 >
 >


Previous message: [osflash] Audio/Video synchronization research results
Next message: [osflash] high quality video
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the osflash mailing list



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090622/ffcf7e7b/attachment.html>


More information about the Red5 mailing list