[Red5devs] [Red5] [Fwd: [Fwd: [Fwd: Re: Red5 Gapless Stream Change]]]
Mikael Kopteff
miku at floobs.com
Thu Apr 17 01:04:04 PDT 2008
Hello again,
I was able to reproduce the momentary pixelation. I have been studying
the red5 code and the sendResetMessage(), but I have not found a way to
fix this issue.
Now the sendResetMessage() is sent in the beginning of each stream
during the play method, but if I "queue" it, how do I know when the
client has 'consumed' all the data in the buffer(or about to consume).
Also, if the reset message is not sent during the first stream at all
(if the buffer is not out yet), it will probably show the pixelation
issue, if I have understood correctly, right?
Current situatuation:
Stream 1 Switching Stream 2
|-R--------------------------| |-R-----------------------|
R = reset message
Solution? Anyone?
Mikael Kopteff
Software Developer
Floobs Ltd.
www.floobs.com
miku at floobs.com
+358 40 545 1645
Sales Department kirjoitti:
> I know if we don't close a video stream before playing the next one from
> the player side, that you can experience a momentary pixelation of the
> video image - kind of like a genlock problem with analog switched video.
>
> Mikael Kopteff wrote:
>
>> Hello,
>>
>> i am doing some stuff regarding serverside streams and we are badly in
>> the need for the gapless playback between streams (so that the buffers
>> are not flushed between swithing of the strams).
>> As a temporary fix I have made my own build for red5, that omitts the
>> sendResetMessage(); so there is no flushing of the buffer and the
>> playback is gapless. What I would like to do now is make a permanent
>> solution and maybe fix this problem, if possible. My first question is
>> what is this ResetMessage actually used for (the API says, that it is
>> for "To notify the client to reset the playing state.") and Stanislaw
>> said that omitting the method "there are some visual issues when the
>> resetmessage isn't sent." But what does this actually mean? What does
>> this affect? If I try to fix it by using a queue, when should the client
>> receive these messages?
>>
>> Best Regards,
>> Mikael Kopteff
>>
>> -------- Alkuperäinen viesti / Orig.Msg. --------
>> Aihe: Re: Red5 Gapless Stream Change
>> Päiväys: Thu, 30 Aug 2007 09:21:37 -0500
>> Lähettäjä: Paul deCoursey <paul at decoursey.net>
>> Vastaanottaja: Stanislaw Fiedor <stfurca at wp.pl>
>> CC: Steven Gong <steven.gong at gmail.com>, sopuli at gmx.net
>> Viittaukset: <013e01c7eb0f$f1c69a70$6600a8c0 at stf>
>>
>> The client does report back to the server with it's buffer time. There
>> is a ping, you can see it in the logs if you have debug enabled for
>> logging. I don't recall which parameter it is, or how to intercept the
>> data. This probably wouldn't give you what you want though, this is the
>> max buffer size, rather than how much is actually being buffered.
>>
>> I think what needs to happen is the reset message needs to be queued
>> rather than sent right away. I'm haven't really had time to look at it
>> too much, but I'm sure there is a way to do this.
>>
>> Paul
>>
>>
>> Stanislaw Fiedor wrote:
>>
>>
>>> Hello Steven,
>>>
>>> I know that you are currently working on clustering and probably have
>>> a lot to do with it, but I thought that maybe you could take a look at
>>> the rebuffering issue after switching the stream.
>>> Repairing that is significant for any TV-like application, therefore I
>>> think that it would be great for Red5 to support it.
>>>
>>> While experimenting with the source files I figured out that it is
>>> probably caused by what Paul has written - Red 'flushes' the buffer,
>>> and it happens during:
>>> sendResetMessage();
>>>
>>> in the play method in ServerStream Class.
>>>
>>> if you comment this line of code, there is no rebuffering.
>>> Unfortunately there are some visual issues when the resetmessage isn't
>>> sent.
>>>
>>> So in my opinion the way to 'repair' it would be to ommit the reset
>>> message in the play method and send it to the client just after he has
>>> 'consumed' all the bytes from the previous stream. (so probably some
>>> scheduldedmessage..) - but I have no idea how to figure out how much
>>> data or better said 'time' has the client in his buffer.
>>>
>>> I'm hoping that maybe you will find some time to take a look at it.
>>>
>>> BR
>>>
>>> stf
>>>
>>> ----- Original Message -----
>>> From: "Paul deCoursey" <paul at decoursey.net>
>>> To: <red5 at osflash.org>
>>> Sent: Sunday, August 19, 2007 12:38 AM
>>> Subject: Re: [Red5] Gapless Stream Change
>>>
>>>
>>>
>>>
>>>> I think I know what the issue is. When you switch streams the
>>>> ServerStream class will flush the buffer. I've been analyzing this
>>>> issue for a few days now trying to find away to fix it yet keep the
>>>> functionality that is required but produces this side effect. Not sure
>>>> that made sense. There is a lot going on and a lot of use cases to
>>>> think about. This may be above my current ability so I'm wouldn't count
>>>> on a patch from me real soon.
>>>>
>>>> Paul
>>>>
>>>>
>>>> Stanislaw Fiedor wrote:
>>>>
>>>>
>>>>> I've also been trying to switch streams without re-buffering, but I
>>>>> guess
>>>>> that its the case of the red5... that it doesn't work like in FMS..
>>>>> I think that maybe Steven gong could say something more about this
>>>>> issue and
>>>>> even create a fix for that;)
>>>>> BR
>>>>> stf
>>>>>
>>>>> ----- Original Message ----- From: "Hannu Leinonen" <sopuli at gmx.net>
>>>>> To: "Red5 Mailinglist" <Red5 at osflash.org>
>>>>> Sent: Saturday, August 18, 2007 5:01 PM
>>>>> Subject: [Red5] Gapless Stream Change
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Hello everyone!
>>>>>>
>>>>>> I'm doing a server-side stream which source can be changed by a flash
>>>>>> client. When playing it, I'm facing an issue when changing the source.
>>>>>> It doesn't play the old stream's buffer to the end, but flushes it and
>>>>>> starts buffering the new stream. So the change of streams is not
>>>>>> gapless.
>>>>>>
>>>>>> Here's how I do the changing of streams:
>>>>>>
>>>>>> SimplePlayItem sourcePlayItem = new SimplePlayItem();
>>>>>> sourcePlayItem.setName(sourceStreamName);
>>>>>> sourcePlayItem.setStart(-1);
>>>>>> IServerStream oldStream = StreamUtils.getServerStream(scope,
>>>>>> newStreamName);
>>>>>> // Remove everything from the stream
>>>>>> oldStream.removeAllItems();
>>>>>> // Add the playitem to the stream
>>>>>> attachSourceToStream(oldStream, sourcePlayItem);
>>>>>>
>>>>>>
>>>>>> Is this an issue on Red5 or am I missing something?
>>>>>>
>>>>>> Yours,
>>>>>> Hannu Leinonen
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>> Version: GnuPG v1.4.7 (MingW32)
>>>>>>
>>>>>> iD8DBQFGxwnPlKdTOEGZkhgRAmnNAJ41+EpCMWNnqjpeYNP2bC/5oDxYUwCeKCwO
>>>>>> aQwwTIQan2AKYbZRIIjbLxQ=
>>>>>> =Z8kH
>>>>>> -----END PGP SIGNATURE-----
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>>>
>>
>> _______________________________________________
>> 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/red5devs_osflash.org/attachments/20080417/209bc001/attachment.html
More information about the Red5devs
mailing list