Hi Adriano, If your finished product (like am mp3 file or a FLV) can be downloaded and played back in real time on a broadband connection, then the default "progressive streaming" option would probably work fine for your needs. This works over HTTP, first reading the META data of the file, buffering it for some preset duration of time, and starting to play it as soon as possible, while the rest of the file is downloaded via HTTP. The assumption made here is that the client will receive the data in a shorter time than the actual playing time of the enitre media file. So in effect, it will appear to be "streamed" to the client in real time without delay.
One distinction of using Red5 or FMS is the ability to seek to and stream from any particular point in a media file, without the perception of any sort of delay, or having to download the entire media file first. Also, one advantage to using the default "progressive streaming" option, which does not require Red5 or FMS (hence it is "free" in a sense), is that the entire file can be cached on the client side in their web browser, so they can play it over and over, seeking to whatever point they wish (assuming the user interface provides such controls, and enough cache is allocated to keep the entire file on disk) and the files are reasonably sized so that they will download quickly and completely over a broadband connection without having to stop to buffer data to create a "real time" experience. When you get into much larger and longer kinds of media files - or things created and delivered live-on-the-fly, then it might make more sense to stream that data on demand. Red5 apparently cannot presently (but should in the future) be able to cache any incoming stream data on the client side through the web browser, the benefit being that data doesn't need to be sent to the client again should they request it (assuming they already have a copy). So once they have it locally, they don't need to demand it again remotely - although I don't know exactly how this would work out. The point is that Red5 or FMS makes it possible for people to jump around (read: seek to and play from any point in a media file) as they wish without the formality of waiting for the entire file to download and play back in a somewhat linear time frame - but that data isn't cached, so each time it is requested, it must be sent again from scratch. Your "progressive download" allows for data to be cached, assuming the entire file is received the first time it is requested, therefore you can save on outbound bandwidth when the client already has a copy of the media file in their cache and is likely to "repeat" the performance. Hope that helps, and even makes a bit of sense. =) -Nathan On Fri, 26 Jan 2007, Adriano Bonat wrote: > Hello, > > I'm in a project where users can listen to musics (mp3s and other > formats) using a music player in flash, since I'm not a flash > developer, my question is what is the advantage of use Red5 instead of > just convert the songs to flv (in the cases that flash don't support > the song's format) and use the default streaming capability that flash > have. > > Thanks in advance, > -Adriano Bonat _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
