My first thoughts followed the same path Giovanni describes. Use Red5 to
send the 'shareable data' ; make small packets of them and send them
in a timed way e.g. send one packet of 1 kb, wait for the flash-client to
acknowlegde the reception , measure the current bandwidth used at that time
(bytes didived by passed time) then wait if that would exceed your desired
bandwidth, then send the next packet of data and so on.
After reception of the data you can reconstruct the original image and show
it inside the Flash-application.
That way will take a bit of work (but it's straightforward) and also creates
the opportunity to show a nice download-progress-bar.
With an SWF running in the browser it's not possible to save the file to
disk since Flash does not permit that (AIR would, but that doesn't run in
the browser alas) .
However users could always download the files from your server with normal
http-urls after the conversation, if that's desired. If you'd create a
unique subdirectory for each conference-call (e.g.
http://my.server.com/conference/files/session/7dba8d63h3gfs734711/file3.jpg)
then it's pretty safe as well. Ideally you'd let ppl login to your
fileserver (using simple generated or dynamic .htaccess or ordinary
server-sided-session-based security etc).
> Theoratically you could trottle the download of the image and stream
> bit and pieces to the users at the desired bandwidth.
>
> Having a different server would probably help.
>
>
> Best Regards,
>
> Giovanni
>
> On Jul 6, 2009, at 12:34 PM, Ignacio Lopez <
ignacio.lopez@...>
> wrote:
>
>> Hello all,
>>
>> I´m experiencing this behavior in a webconference app and although I
>> suspect that what´s happening is normal and there is not much to be
>> done to cope with it I decided to see if someone has any ideas =)
>>
>> Imagine you have a 400 Kbps link to a server and you are receiving a
>> live stream @ 300 Kbps via RTMP, and suddenly someone shares an
>> image in the webconference app. What happens is that the streaming
>> in the receiving end appears to "stop" while downloading the file
>> via HTTP, and after the file has been downloaded the stream
>> "resumes" from where it was. So then you get a delay of some seconds
>> (depending how long it took your connection to download the file)
>> that is never made up for.
>>
>> The ideal behavior, for me, would be the exact opposite: the stream
>> gets preference and the file is downloaded with the amount of bw
>> left (the file can take a while to download, but the audio and video
>> are not affected, which is for me the desired situation in a web
>> conference).
>>
>> Is there a way for red5 to send images to flash clients without
>> requiring http downloads that compete with the live streaming?
>> Downloading the files from different domains would help?
>>
>> Thanks very much in advance,
>> Ignacio
>>
>> _______________________________________________
>> Red5 mailing list
>>
Red5@...
>>
http://osflash.org/mailman/listinfo/red5_osflash.org>
> _______________________________________________
> Red5 mailing list
>
Red5@...
>
http://osflash.org/mailman/listinfo/red5_osflash.org>
--------------------------------------------------------------------------------
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.560 / Virus Database: 270.12.26/2116 - Release Date: 15-05-09
06:16
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org