[Red5devs] streaming related notes

Wed Jul 5 23:06:34 EDT 2006

lol, wow Kerem!  thanks for sharing this with us, you think you could do the
same exact test when we release rc1 on monday to see what the improvements
might look like?

On 7/5/06, Kerem Hadimli <wastiee at gmail.com> wrote:
>
> well, we've made some tests today, an hour ago. here's my few notes
> about this topic
>
> first of all, we've tested with two trunk versions, r1107 and r1109.
> 1109 seems to have the "live stream stops playing" problem, but it
> doesn't occur in 1107, or maybe occurs much less, i'm not sure,
> anyway, trunk isn't stable yet, so this's not a problem. (it was
> occuring in earlier versions than r1107, but i don't know when it's
> fixed)
>
> Using 1107, and 8 clients connected, each streaming video (at
> 12000bytes/sec) and audio (5khz, 1.3 kbyte/sec i guess), and each
> viewing other 7 participants video. Red5 server was on local lan,
> 100mbps, and the clients were on one laptop, each using the same
> camera and mic
>
> we've run this test for half an hour. after half an hour, each video
> stream on each participant had its own different lag, for example, i
> sit on a chair in front of the camera, and i then watch myself sit
> that chair for 5 minutes on different subscribers and on different
> streams. 7x7 = 49 ones.
>
> Well, the interesting point is. i tested sound, said something at
> 05:13:00 am, these are the times i've listened my voice;
>
> 5 13 40
> 5 16 03
> 5 16 12
> 5 16 21
> 5 16 38
> 5 16 41
> 5 16 47
>
>
> The point is, I was expecting 49 replies (7x7), but i've only received
> 7. This doesn't happen with video, in video, i really receive 49
> different streams (i had 8 tabs opened in firefox, and i was switching
> tabs continuously, and seeing myself just sit down in 2-3 frames in
> each tab every time i switched the tab).
>
> So, i think there happens a lag in both ways in vide; upstreaming the
> video from client, and downstreaming from the server, so i can see 49
> differently timed videos in a 8 client room. But, in audio, there's
> different lag (different for each client i mean), in just one way, not
> both ways.
>
> Either, all 8 clients' microphones' audio packets are received at the
> same time at server side, but they get streamed to each client at
> different lags, so i hear one client play the sound of 7 others at the
> same time; and this happens for 7 times, one for each client.
>
> Or, all 8 clients' microphones' audio packets are received at
> different times at server side (the difference in lags is from client
> to server), and when a client's audio packet is received, it's
> streamed and received from all 7 other clients and played at the same
> time. And server receives 8 client's mic packets at different times,
> so that causes the 7 differently timed replies i've heard.
>
>
> sorry if i was too complicated, slept only 4 hours in the last 40
> hours. i thought it may help.
>
>
> ps: mm, i'm think that the first way is more probable than the second,
> because i've counted 7 replies, not 8. but maybe that's what i should
> count in second way too, not sure, cannot think anymore:) hope this
> information helps.
>
> -kerem
>
>
> On 7/6/06, Steven Gong <steven.gong at gmail.com> wrote:
> >
> >
> >
> > On 7/6/06, Luke Hubbard <luke at codegent.com> wrote:
> > > Hi All,
> > >
> > > I'm working on fixing the VOD streaming, specifically after seek, etc,
> > > the timer not resetting correctly. I think I have worked out the ts
> > > and ping issue once and for all but more on that later hopefully I can
> > > commit something tonight.
> > >
> > > I did some experiments with live streaming to fancycode and found
> > > video lag to be great but audio really started to get behind.. as much
> > > as 10-15s behind after a while.. This is really odd as the packets
> > > should be sent at the same time. Here is my theory..
> > >
> > > At the start of the stream the server sends those pings along with the
> > > statuses, The pings mean reset your timestamps.. Why 3 pings.. well
> > > probably for audio, video, and data channels. After that the first
> > > packet for those channels sends an 1 packet with absolute ts followed
> > > by relative from then on. This could explain the situation im
> > > experiencing with audio as the calculated total ts for video will be
> > > less than that of audio on the client once there are been a few
> > > dropped packet, thus causing the client to delay the audio.
> >
> >
> > Have you found what the 3 pings look like? That makes sense for audio
> lags
> > behind video and if it's true for different pings taking charge of
> different
> > channels, that seems to be the server's responsibility to keep
> > audio/video/data in synch.
> >
> > > So whats the solution how do we drop packets? Well if we dont send the
> > > packet, we could roll over the ts and add it to the next packet we
> > > dont drop going down the same channel. This will keep the absolute
> > > times in sync I hope. I tried sending an empty buffer but this causes
> > > video interference.
> >
> >
> > Empty buffer is ok for synch ts as I recalled to see that in FCS/FMS's
> > output.
> >
> > > Other things I noticed, RTMPMessage seems a bit redundant as its just
> > > acts as a container for the RTMP event. Can we just refactor the event
> > > a little and kill the container, I think its overhead having the
> > > wrapper esp when it has a hashmap that doesn't look like its doing
> > > anything being created for each packet. I want to have methods to find
> > > out relative and absolute ts for any packet. But before making this
> > > change I wanted to check with steven, and perhaps wait for him to
> > > commit his recent work first.
> >
> >
> > The original goal for RTMPMessage is to embed RTMP packet model into
> message
> > model for streaming because we may probably add more attributes to
> messages
> > that RTMP packet need not have so that I add a hashmap for that
> extension.
> > For now, I am considering migrate IMessage to IEvent (whatever the name
> is,
> > we have a top-level interface for everything) so that no redundancy
> there.
> > But anyway I don't think the extra container will affect the performance
> > much so why not leave the refactoring after RC release? And before that
> we
> > could talk it in detail how to better merge IMessage and IEvent taking
> into
> > account any possible issues there.
> >
> > > Will post email about how I got on tomo.
> >
> >
> > Great!
> >
> > > - Luke
> > >
> > > _______________________________________________
> > > Red5devs mailing list
> > > Red5devs at osflash.org
> > > http://osflash.org/mailman/listinfo/red5devs_osflash.org
> > >
> >
> >
> >  BTW: I will commit the code soon (maybe this night, just got some free
> time
> > from now on to weekend)
> >
> > --
> > Best Regards
> > Steven Gong
> > _______________________________________________
> > Red5devs mailing list
> > Red5devs at osflash.org
> > http://osflash.org/mailman/listinfo/red5devs_osflash.org
> >
> >
> >
>
> _______________________________________________
> Red5devs mailing list
> Red5devs at osflash.org
> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>

-- 
John Grden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5devs_osflash.org/attachments/20060705/076c25e7/attachment-0001.htm