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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> wrote:
> > Forgot to attach the file... Sorry
> >
> >
> >
> > On 7/19/07, Eugen-Andrei Gavriloaie < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > > > okay, Thanks.
> > > > and Good luck in your exams.
> > > >
> > > >
> > > >
> > > > On 7/1/07, Eugen-Andrei Gavriloaie < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > how can I help or contribute ?
> > > > > >
> > > > > > thanks,
> > > > > > Ibrahim
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 6/3/07, Eugen-Andrei Gavriloaie <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > > > > > Mobile:+40722537658
> > > > > > > _______________________________________________
> > > > > > > osflash mailing list
> > > > > > > [EMAIL PROTECTED]
> > > > > > >
> http://osflash.org/mailman/listinfo/osflash_osflash.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andrei Gavriloaie
> > > > > ____________________________________________
> > > > > Programmer
> > > > > SQSG ( www.sqsg.ro)
> > > > > e-Mail: [EMAIL PROTECTED]
> > > > > Mobile:+40722537658
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Andrei Gavriloaie
> > > ____________________________________________
> > > Programmer
> > > SQSG ( www.sqsg.ro)
> > > e-Mail: [EMAIL PROTECTED]
> > > Mobile:+40722537658
> >
> >
> >
> > --
> > Andrei Gavriloaie
> > ____________________________________________
> > Programmer
> > SQSG ( www.sqsg.ro)
> > e-Mail: [EMAIL PROTECTED]
> > Mobile:+40722537658
> >
>
>
>
> --
> Andrei Gavriloaie
> ____________________________________________
> Programmer
> SQSG (www.sqsg.ro)
> e-Mail: [EMAIL PROTECTED]
> Mobile:+40722537658
> _______________________________________________
> osflash mailing list
> [EMAIL PROTECTED]
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
>

_______________________________________________
Red5 mailing list
[email protected]
http://osflash.org/mailman/listinfo/red5_osflash.org

Reply via email to