Hey Brian,

I think this can be achieved by setting everybody's buffer to 0 seconds,
including the server (and clients). (Yes 0 seconds! hehe, on a LAN that
could maybe pass, but on the internet I'm not sure)

The quality will be reduced by a lot. This will make the server keep up =
the
good rate, and informing the clients of which frame is displayed at the
moment. If one stream gets lagged, it will eventually re-synch with some
chip monk effect. I might be wrong, correct me if I'm wrong.

*I know it=92s a hell of a challenge to create 2 streams that are in =
synch.
And I find this request very interesting, but as you said it might be a =
hell
of a challenge for them since that would mean lots of stream management.

Best regards,
Fredz./





-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.
org] On Behalf Of Brian =
Lesser
Sent: August 30, 2005 1:54 PM
To: FlashComm Mailing List
Subject: Re: [FlashComm] What FlashCom features do you want in a
futureversionof Flash?

Hi David,
At the risk of beating the same note over and over again, the subject of =

controlling stream buffers came up again today. I was asked how to play=20
two streams in sync with each other. The idea was to compare the two=20
streams side-by-side as they ran. My answer was that it is not possible=20
with the current Flash player. But imagine that a pause (or related=20
methods like seek or some brand new methods..) did not dump the stream=20
buffer. Not only could you let two streams buffer to a certain level,=20
pause them, and start them at the same time, you could also monitor=20
stream time and buffering. If one stream stopped to buffer you could=20
pause both streams and restart when the smallest buffer reached a=20
certain size. Or while both streams are playing and one got more than x=20
milliseconds off in time from the other stream you could pause the=20
stream that got ahead of the other one etc. It's not perfect but it=20
would work well enough for many applications.
From a distance I would guess this is a non-trivial request and that=20
the risk level might be high because you don't want to break streams at=20
all, but I believe success would make a big difference.
Yours truly,
-Brian

Brian Lesser wrote:

> Hi David,
> My wish for the player would be enhanced buffer control. In other=20
> words not dumping the audio/video/data buffer when you pause a stream=20
> and being able to pre buffer without playing a stream automatically.
> For example, in a multi-stream app you should be able to pre-buffer a=20
> second stream in preparation for playing it at a precise moment. It=20
> should be an option to simply hold data in the buffer and not just=20
> play it when the buffer fills to a certain point etc...
> Similarly the buffer should not be dumped if a stream is paused. That=20
> is really inefficient.
> Controlled buffering is not a security/copyright theft problem because =

> you already do client-side in memory buffering.
> Yours truly,
> -Brian
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm



=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm


=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

[ Post a follow-up to this message ]