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
