Download, Play, Stream - someone set me straight

[Jami]

Download, Play, Stream - someone set me straight

Searching and searching and I can't find answers -

I'm looking for Best Practices (some may not be familiar with this term) for offering audio (Voice not music) media files.

I thought streaming was anytime you played the file right off the server without saving it first to your own computer, but there seems to be some difference between 'playing' and 'streaming' and I can't find what that is or its affect on bandwidth usage. My understanding has gotten messed up....

I thought downloading - was just saving a file from a server to my computer, but I read where people mention downloading while listing at the same time - What's this called? And do I get both - a copy on my computer and a listen to the file at the same time?

I believe streaming is something I have to do if I want to offer Live media, and I better use a special host for this service. But what about just allowing visitors to play and listen to a file - does that have to be 'streamed'.

I read on the forum where people don't want visitors downloading their media - I want people to get our media by way of the lowest bandwidth. If that means playing fine, if it means downloading fine. Its all about the best method for making it available - best use of resources is most important.

People talk about compressing files, but which are best mp3 or wma? And what happens if several people are 'playing' the same file at the same time?

Everywhere I look are articles about how to offer media, but no where can I find the best practices for why do it this way or that way.

Can someone set me straight please......? This incomplete understanding is stressing me out - Oy!

[oatesj77]

don't quote me on this i'm not 100% but i think streaming is like flash, media is not downloaded, but loaded into your browser cache and played, and downloading is just that downloading.

[IanS]

Streaming is, as you say, loading the file into an application (could be just the browser) on the target computer and playing it at the same time. Downloading would be where the file was first saved on the target computer and then played.

Streaming means you load the file from the server every time you want to listen to it, if it is downloaded it would be available on the target computer for playing without downloading again.

Streaming eats resources at the server - downloading is not as intensive so is better for the server.

Streaming is useful for live events - many radio stations stream their audio content - or for music videos where the copyright owner wishes to keep control of all the copies and where they're held.

Streaming requires a broadband (DSL or ADSL) or cable connection, downloading can be done slowly via a dial-up connection.
This is my understanding of the differences.

[Rick_E]

There are two kinds of streaming, "real" streaming from a media server and HTTP streaming (sometimes called Progressive Download) from a web server.

With real streaming media from a media server, there is two-way communication between the player and the server. This allows the server to adjust the speed as needed. Streaming media servers give the best possible user experience.

With HTTP streaming from a web site, there is only a one-way progressive download in which the media plays in the browser as it is received. If the user has an Internet connection that can deliver the media fast enough, all is well. But if the user's Internet connection can't keep up, the user's player goes on pause until it can rebuffer and catch up.

Webmasters using HTTP streaming usually encode the video at two speeds for the users to choose from, about 30kbps for dialup users and 250kbps for broadband users.

[Rick_E]

The following, from the Windows Media Encoder help file, explains the difference between streaming from a media server and streaming from a web server...

Comparing Windows Media servers and Web servers You can deliver content from a server running Windows Media Services or from a Web server to a player. The server and player can be either on the Internet or an intranet, and they can be separated by a firewall. Although a Windows Media server is designed specifically for streaming Windows Media-based content, a standard Web server is not. If you decide to use a Web server, you should be aware of the differences in the way the content is delivered, which can affect the quality of the playback.

Windows Media servers A Windows Media server meters the delivery of packets according to feedback information it receives while sending a stream to a player. When a player receives packets in this way, the presentation is much more likely to be smooth. Because bandwidth use is controlled, more users can connect concurrently to your site and receive streams that are free of interruptions.

If you plan to deliver your content as a unicast stream from a Windows Media server, you can encode a multiple-bit-rate (MBR) stream. This provides users with better quality content during times of network congestion. When MBR content is received by a player, only the bit rate that is the most appropriate for network bandwidth conditions is streamed. The process of selecting the appropriate stream is handled by the Windows Media server and the player and is invisible to the user.

When streaming single-bit-rate streams or files, a Windows Media server is designed to handle network congestion smoothly. If congestion occurs during the broadcast, the stream is "thinned", which means that the frame rate is reduced. If this is insufficient, the video portion of the stream is frozen and only the audio portion is streamed.

Web servers A Web server is designed to download as much data as it can, as quickly as possible. This is the preferred method for sending packets containing static images, text, and Web page script, but it is not the best method for sending packets containing streaming media. Streaming media should be delivered in real time, not in large bursts, and the player should receive packets just ahead of rendering them.

Web servers do not support MBR streams. When a file streams from a Web server, the quality of the delivery is not monitored and no adjustment to the bit rate can be made. Web servers cannot use the preferred delivery protocol, User Datagram Protocol (UDP), so the delivery of a stream is more likely to be interrupted by periods of silence while the player buffers data. In addition, Web servers do not support live broadcasts and multicast streams.

[Jami]

Thanks for the information... that helps with my general question and more specifically with how Windows Media Streaming works, since that comes bundled with Windows 2003 server OS its good to know.

And I also know, because I use PlayStream for one of my clients, that streaming servers offer software that copies a file for each person requesting a stream (when clicking on it) this way each person's experience is like they are the only one on the Net. When the stream is done the software deletes the copy. This service at PlayStream is very expensive and my reason for asking for more info here at the forum :o

Thanks everyone!

[muijefr]

IanS, nice contribution to the subject but streaming is not limited to wide band transport. You can stream any internet/PC connection but the quality of the object suffers the lower the baud. 90baud is good for most music types of applications and 24 baud is for low end application (which does not exclude music).

Along about version 9 of Microsoft's multimedia client, they began downloading the content being streamed, rather than the media being rendered without also downloading. So, it is very much a mixed bag depending on the client multimedia doing the rendering and of course the options your web site offers.

I'm not sure a best practice is to be found for the internet. Just some acceptable practices but then perhaps W3 has a correction to this opinion. :D

[Chaz1138]

Hey, everyone, new to this board, but not to forums in general.

So ...

Streaming is similar to playing live content, like off of a webcam or an internet radio station. Powweb frowns on this from their own servers, but provides the ability to stream from a non-Powweb server.

HTTP streaming is what I'll call the "old school" practice of uploading a video or audio file to a given directory in your web site space and you disdplay it on your webpage via <embed> or <object> tags. When someone comes to your site, the embedded file loads from your space on Powweb's disks into the "guest's" browser and plays via the same browser. This Powweb allows as long as you stay within your daily bandwidth allotment.

Downloading is where you provide a clickable link on a web page. Guests can click the link and the file downloads to their computer, it does not display in "real time" and your guest may view it, repeatedly, at their lesiure. Only the initial download counts against the daily bandwidth limit and downloads are not a problem until they reach the daily bandwifth limit

Lastly, if you do not store and reference all your audio/visual/pic files in a MySQL db, guests watching videos, looking at pics or listening to mp3s do not count against PowWeb's 72,000/hr. count request limit.

Have I got this right?