[Red5] More Investigation Results on SN-60 (was Re: About SN-60)
Lenny Sorey
lrsorey at gmail.com
Thu Sep 20 08:56:56 PDT 2007
Hi Stanislaw,
Basically with this app, I added a ns.BufferTime = 1 just before the
ns.play statement in the Flex app.
Basically the playlist is loaded on the front-end and when one
flv or mp3 ends the next in line ques up and starts playing.
This app is currently rebuffering every 1 second so there exist the
possibility
of some small delay among users viewing the app. So far, the rebuffering has
not
yet had a major impact between users as far as I can tell. At the beginning
of the
next up video or mp3, the app actually resyncs.
At the end of the playlist, the paylist is re-loaded again.
By the way, the honor goes out to Jan Muller AKA "Honza" who actually
composed the original Java source and the Flex 2 source.
I now have loaded an mp3 to play in the tv app. It plays at the end of the
the 3 flvs I have running.
Regards,
Lenny
Regards,
Lenny
On 9/20/07, Stanislaw Fiedor <stfurca at wp.pl> wrote:
>
> Hello Lenny,
> I just saw your tvapp. It works really fine, but I can't find out whether
> there is a gap when switching streams or not? If there is no rebuffering how
> did you managed it?
> And how does your server switching code look like?
> I will appreciate any response.
> Stanislaw
>
> ----- Original Message -----
> *From:* Lenny Sorey <lrsorey at gmail.com>
> *To:* red5 at osflash.org
> *Sent:* Wednesday, September 19, 2007 4:35 PM
> *Subject:* Re: [Red5] More Investigation Results on SN-60 (was Re: About
> SN-60)
>
>
> Steven,
>
> Thanks for your explanations.
>
> Regards,
>
> Lenny
>
>
> On 9/19/07, Steven Gong <steven.gong at gmail.com > wrote:
> >
> >
> >
> > On 9/19/07, Lenny Sorey <lrsorey at gmail.com <lrsorey at gmail.com+>> wrote:
> > >
> > > Hi Steven,
> > >
> > > My responses in red5 below.
> > >
> > > Thanks for your follow-up.
> > >
> > > Regards,
> > >
> > > Lenny
> > >
> > >
> > > On 9/19/07, Steven Gong <steven.gong at gmail.com
> > > <steven.gong at gmail.com+>> wrote:
> > > >
> > > > Hi all,
> > > > I re-start a thread for more investigation results on SN-60. Hope
> > > > someone on the list can help me to do the experiments I mentioned below.
> > > > (1) The streaming algorithm of ServerStream needs enhancing but no
> > > > critical mistake was found in it. This means the streaming SHOULD work fine
> > > > with the current ServerStream.
> > > > (2) It seems that to live stream a VOD is not same as live stream
> > > > from a live source (camera etc.). I hope that someone could help to confirm
> > > > this by testing two scenarios. The first is to put the recorded files from a
> > > > camera as sources for TV sample and the second is to put VOD files (like the
> > > > sample files packaged in Red5). I believe the first should work fine with TV
> > > > sample while you will get problem with the second.
> > >
> > >
> > > LRS> When I use a live recording in the streaming server I had to
> > > inject metadata in my live
> > > LRS> recording in order to get the next VOD to play properly. If I did
> > > not do this, then the
> > > LRS> next video in the playlist would only show a blank although the
> > > audio would work fine.
> > > LRS> You can see an example of a video recorded from my webcam in the
> > > playlist at
> > > LRS> http://red5.fatdot.com/tv1.html
> > >
> >
> > The current ServerSide doesn't properly treat the metadata. In fact, all
> > metadata tags including the one in FLV or auto-generated should be filtered
> > out.
> >
> > (3) If you someone can confirm my statement (2), you can also try
> > > > whether FLV with mp3 audio has any difference from FLV with nelly moser
> > > > audio.
> > >
> > >
> > > LRS> I have not tried mp3's yet but will add that in today to test.
> > >
> >
> > OK. Thanks.
> >
> > (4) The VOD streaming and Live streaming are different in that for VOD
> > > > streaming, the client buffer will set to larger than 100ms even though the
> > > > client set it to 0 while for live streaming, the buffer can be set to 0 to
> > > > avoid delay I guess.
> > >
> > >
> > > LRS> No sure I follow you on this statement. Are you saying to try
> > > Live Streaming with a
> > > LRS> playlist like in the TV example for streaming server?
> > >
> >
> > This is only an investigation result. What I mean is VOD streams and
> > Live streams should be differently handled by server and there's a Ping
> > message to mark this difference. The current problem is that we might need
> > to treat the VOD streams inside the server-side stream as VOD not Live
> > (currently it's treated as Live) so that the client will use the play buffer
> > even if the client sets the play buffer as 0.
> >
> > For the bug in onPing(), the value2 is for stream id so 0 means the
> > > > connection object. And in this scenario, it should be a connection-wide play
> > > > buffer setting. Of course, we need an enhancement to support this.
> > >
> > >
> > > LRS> OK.
> > >
> > > On 9/18/07, Lenny Sorey <lrsorey at gmail.com> wrote:
> > > > >
> > > > > Hi Vasile,
> > > > >
> > > > > Thanks for your response.
> > > > >
> > > > > I was just checking the logs while running the latest
> > > > > from the source.
> > > > >
> > > > > I changed my BufferTime to = 1 and in my log files it was showing
> > > > > the client buffer set to 1000 milliseconds.
> > > > >
> > > > > Maybe I am wrong, but I thought the value2()
> > > > > was referring to the buffertime value.
> > > > >
> > > > > Count 0 1 2 3
> > > > >
> > > > > Unhandled ping: Ping: 3, 0, 750, -1
> > > > >
> > > > >
> > > > > My thinking which can be entirely wrong, is that Value2() is being
> > > > > treated
> > > > > like an array which would start the count at 0 rather than 1. If
> > > > > this is
> > > > > the case, then Value2 would be correct.
> > > > >
> > > > > But hey, I have been wrong before. : )
> > > > >
> > > > > Thanks again for your response.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Lenny
> > > > >
> > > > >
> > > > > On 9/18/07, Vasile Rotaru < vrotaru.md at gmail.com > wrote:
> > > > >
> > > > > > Hi, Lenny
> > > > > >
> > > > > > On 9/18/07, Lenny Sorey <lrsorey at gmail.com > wrote:
> > > > > > >
> > > > > > > Hi Vasile,
> > > > > > >
> > > > > > > I am sorry, I don't follow you on exactly what the error
> > > > > > > message is on the
> > > > > > > description below.
> > > > > > >
> > > > > > > Could you explain a little more?
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Well, I'm not sure what it is really. It is just a sequence of
> > > > > > bytes in the header of an RTMP packet
> > > > > > which the RTMPHandler does not understand and complains about
> > > > > > it. I've changed the
> > > > > >
> > > > > >
> > > > > > case Ping.CLIENT_BUFFER:
> > > > > > if (ping.getValue2() != 0) {
> > > > > > // The client wants to set the buffer time
> > > > > >
> > > > > > to
> > > > > >
> > > > > > case Ping.CLIENT_BUFFER:
> > > > > > if ( ping.getValue1() == 3 && ping.getValue4 ==
> > > > > > -1) {
> > > > > > // The client wants to set the buffer time
> > > > > >
> > > > > >
> > > > > > in the my checked-out sources, but... I wish, I'd knew what I'm
> > > > > > really doing... :))
> > > > > >
> > > > > > And yes, the sound still stutters. Maybe less, but I'm not sure.
> > > > > >
> > > > > >
> > > > > > I'll try to do the same with the new version of Red5, and I'll
> > > > > > report my observations.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regards.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Red5 mailing list
> > > > > > Red5 at osflash.org
> > > > > > http://osflash.org/mailman/listinfo/red5_osflash.org
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Red5 mailing list
> > > > > Red5 at osflash.org
> > > > > http://osflash.org/mailman/listinfo/red5_osflash.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best Regards
> > > > Steven Gong
> > > >
> > > > InfraRed5 Red5 Consultant: http://www.infrared5.com ,
> > > > steven at infrared5.com
> > > >
> > > > Red5 Developer: http://osflash.org/red5, http://jira.red5.org/confluence/display/~steven/Home
> > > >
> > > >
> > > > Modesty is an overrated quality in men of no great
> > > > accomplishment. -- Ricky Jay
> > > > _______________________________________________
> > > > Red5 mailing list
> > > > Red5 at osflash.org
> > > > http://osflash.org/mailman/listinfo/red5_osflash.org
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Red5 mailing list
> > > Red5 at osflash.org
> > > http://osflash.org/mailman/listinfo/red5_osflash.org
> > >
> > >
> >
> >
> > --
> > Best Regards
> > Steven Gong
> >
> > InfraRed5 Red5 Consultant: http://www.infrared5.com ,
> > steven at infrared5.com
> >
> > Red5 Developer: http://osflash.org/red5, http://jira.red5.org/confluence/display/~steven/Home
> >
> >
> > Modesty is an overrated quality in men of no great accomplishment. --
> > Ricky Jay
> >
> > _______________________________________________
> > Red5 mailing list
> > Red5 at osflash.org
> > http://osflash.org/mailman/listinfo/red5_osflash.org
> >
> >
> ------------------------------
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20070920/a1c3e736/attachment.html
More information about the Red5
mailing list