| Author |
 Topic  |
|
redbrad0
Advanced Member
USA
3725 Posts |
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
 Posted - 13 December 2003 : 16:29:26
|
| you need windows media server, which will stream them, that is what the DIPEx site does, it was previously realmedia, but the windows media server is now much better. |
 |
|
|
sr_erick
Senior Member
USA
1318 Posts |
Posted - 13 December 2003 : 16:47:28
|
Yes I agree. You may also want to check this out... http://www.microsoft.com/windows/windowsmedia/9series/encoder/default.aspx
It can work standalone on the server or you can encode on the fly with a machine and transfer it directly to windows media services on the server which then redistributes it. Me and a friend were messing with this last night, he was grabbing video right off his DSS, encoding it, and streaming it over to me. It worked great. |
Erick
Snowmobile Fanatics
|
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 13 December 2003 : 21:25:52
|
| Media Services isn't strictly a requirement as most players will buffer the files anyway giving the impression of streaming to the end user. |
Kiwihosting.Net - The Forum Hosting Specialists
|
|
|
|
sr_erick
Senior Member
USA
1318 Posts |
Posted - 13 December 2003 : 22:14:43
|
| I feel that streaming content that you don't want people to save on thier hard drive is the way to go. Overall I would say it takes up less bandwidth as I have found that streaming files to media player doesn't always work well unless you have a super fast connection and then it is wasted bandwidth when they download the file to thier computer anyways. |
Erick
Snowmobile Fanatics
|
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 13 December 2003 : 22:24:03
|
streaming the video is much better than getting them to download the file.
here is some streaming from one of my servers
mms://winmedia.dipex.org/dipexmedia/media/promo.wmv
just paste the url in your browser, address bar |
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 13 December 2003 : 22:48:22
|
quote:
streaming the video is much better than getting them to download the file.
But it will stream over HTTP as well, most media programs will quite happily do it without the need to use MMS and its not forcing the user to download it either. |
Kiwihosting.Net - The Forum Hosting Specialists
|
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 14 December 2003 : 04:57:57
|
that is streaming over http.
most media progs will quite happily do what ?, since they certainly won't stream without a server. |
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 14 December 2003 : 05:21:19
|
quote:
that is streaming over http.
Lol well yeah, thats why I said "stream over HTTP"
quote:
quite happily do what ?,
Do what I said earlier and buffer the file so as to be able to view it as a "stream" rather than downloading the entire file first.
I basically do it this way for "streaming" videos around the house that I've recorded, just have a page that generates the links click on the link and media player buffers the file so I can watch them on any PC in the house, I played with media server but found this worked equally as well with a little less effot ie I just save the files in a directory on the server. |
Kiwihosting.Net - The Forum Hosting Specialists
|
Edited by - Gremlin on 14 December 2003 05:24:31 |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 14 December 2003 : 07:18:30
|
| that is not streaming, and only works because you have a local network, what you are getting is buffered play, not streaming it is entirely different, don't forget your local network has 100Mb bandwidth, most peoples internet connection has 56K, and just will not play the way your are doing it locally. |
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 14 December 2003 : 07:42:13
|
It works regardless of whether I'm on the local network or not, I can watch them over the Net if I wish as well. I'm not saying its "streaming" in the sense of the server actually managing the stream, becuase it's not, for all intents and purposes it is effectively a download, however Media Player quite happily buffers it so that the user receives the impression that it was "streamed"
Most of my recodes that go on the server are very low bitrates becuase I invariably watch them on my PDA in bed.
I'm just rebuilding the HTPC server at the moment otherwise I'd provide a link to it for you to try and see how it works for you. |
Kiwihosting.Net - The Forum Hosting Specialists
|
Edited by - Gremlin on 14 December 2003 07:44:17 |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 14 December 2003 : 07:50:41
|
| I have a 1Mb connection, so yes it will work, especially if your videos are low bitrate, but it is still not streaming, and will never work like streaming, buffering is an entirely different concept, http has limits as to what it can download. |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 14 December 2003 : 07:51:01
|
Web Server vs. Streaming Server
Streaming Methods: Web Server vs. Streaming Media Server
Abstract
There are two major methods of delivering streaming audio and video content over the Web. The first method uses a standard Web server to deliver the audio and video data to a media player. The second method uses a separate streaming media server specialized to the audio/video streaming task. This paper shows that, while Web server streaming can be an effective interim solution, a streaming server is more efficient and flexible and provides a better user experience.
Introduction
Until recently, audio and video on the Web was primarily a download-and-play technology. You had to first download an entire media file before it could play. It was like pouring milk into a glass and then drinking it. But because media files are usually very large and take a long time to download, the only content found on the Web was short 30-second clips—often even shorter. Even these files could take 20 minutes or longer to download. In other words, it took a long time to pour the milk, and then it would barely quench your thirst.
Watching audio and video files that stream is more like drinking straight from the carton; streaming media files begin playing almost immediately, while the data is being sent, without having to wait for the whole file to download. Other than a few seconds of delay before the file starts to play, you don't have to wait to start watching, no matter if the file lasts 30 seconds or 30 minutes.
As audio and video streaming over the Internet has become more popular, two primary methods for streaming content have emerged. The first method is the Web server approach, in which a standard Web server is used to supply data to the client. The second method is the streaming media server approach, in which a specialized streaming server delivers the data to the client. Both methods have advantages that we will discuss, but first let's take a look at the way each process works.
How the Two Methods Work
Streaming with a Web Server
Posting and Hosting
Deploying streaming media content with the Web server approach is actually only a small evolutionary step away from the download-and-play model. Uncompressed audio and video is first compressed into a single "media file" for delivery over a specific network bandwidth such as a 28.8 kilobits per second (Kbps) modem. This media file is then placed on a standard Web server. Next, a Web page containing the media file's URL is created and placed on the same Web server. This Web page, when activated, launches the client-side player and downloads the media file. So far, the actions are identical to those in the download-and-play case. The difference lies in how the client functions.
Data Delivery
Unlike the download-and-play client, the streaming client starts playing the audio or video while it is downloading, after only a few seconds wait for buffering, the process of collecting the first part of a media file before playing. This small backlog of information, or buffer, allows the media to continue playing uninterrupted even during periods of high network congestion. With this delivery method, the client retrieves data as fast as the Web server, network and client will allow without regard to the bit-rate parameter of the compressed stream. Only certain media file formats support this type of "progressive playback". Microsoft's Advanced Streaming Format (ASF) is one of the most popular.
Web server streaming uses the Hyper Text Transport Protocol (HTTP), the standard Web protocol used by all Web servers (such as Microsoft® Internet Information Server) and Web browsers (such as Microsoft Internet Explorer) for communication between the server and the client. HTTP operates on top of the Transmission Control Protocol (TCP), which handles all the data transfers. Optimized for non-real-time applications such as file transfer and remote log-in, TCP's goal is to maximize the data transfer rate while ensuring overall stability and high throughput of the entire network. To achieve this, using an algorithm called slow start, TCP first sends data at a low data rate, and then gradually increases the rate until the destination reports packet loss. TCP then assumes it has hit the bandwidth limit or network congestion, and returns to sending data at a low data rate, then gradually increases, repeating the process. TCP achieves reliable data transfer by re-transmitting lost packets. However, it cannot ensure that all resent packets will arrive at the client in time to be played in the media stream.
Streaming with a Streaming Media Server
Posting and Hosting
In the streaming media server approach, the initial steps are similar to the Web server approach, except that the compressed media file is produced and copied to a specialized streaming media server (such as Microsoft Windows Media Services) instead of a Web server. Then a Web page with a reference to the media file is placed on a Web server. Windows Media Services and the Web server may run on the same computer.
Data Delivery
The rest of the streaming media server delivery process differs significantly from the Web server approach. In contrast to the passive burst methodology employed in Web server streaming, the data is actively and intelligently sent to the client, meaning that it delivers the content at the exact data rate associated with the compressed audio and video streams. The server and the client stay in close touch during the delivery process, and the streaming media server can respond to any feedback from the client.
While streaming media servers can use the HTTP/TCP protocols used by Web servers, they can also use specialized protocols such as the User Datagram Protocol (UDP) to greatly improve the streaming experience. Unlike TCP, UDP is a fast, lightweight protocol without any re-transmission or data-rate management functionality. This makes UDP an ideal protocol for transmitting real-time audio and video data, which can tolerate some lost packets. As a bonus, because of the back-off policies implicit in the TCP protocol, UDP traffic gets higher priority than the TCP traffic on the Internet. And instead of the blind retransmission scheme employed by TCP, streaming media servers such as Microsoft's Windows Media Services use an intelligent retransmission scheme on top of UDP. Windows Media Services' UDP Resend feature ensures that the server only retransmits lost packets that can be sent to the client in time to get played.
Comparative Analysis
The differences between the Web server and streaming media server solutions translate into clear distinctions in both ease of implementation, ease of management, and quality of user experience. For the remainder of this white paper, the comparison will be between a generic Web server and Microsoft's streaming media server, Windows NT Server Windows Media Services (hereafter referred to as a Windows Media server).
Streaming with a Web Server: the Advantages
There is really only one major advantage to streaming with a Web server rather than with a streaming media server—utilizing existing infrastructure. Because the Web server approach uses only the standard Web server--that presumably already exists in the organization—no new software infrastructure need be installed or managed. The Windows Media server approach, on the other hand, requires the content producer and/or the systems administration staff to install and manage additional server software. This can result in incremental training and staffing costs to learn and manage the more complex, but also more powerful, Windows Media server environment.
It is important to note that the increased load that Web server-based streaming puts on existing Web server infrastructure often results in the need for additional Web server hardware to service the client requests. Choosing Web server streaming over a dedicated streaming media server based on hardware cost alone usually does not result in any financial savings.
Streaming with a Windows Media Server: the Advantages
Designed specifically for the task of delivering live or on-demand streaming media rather than many small HTML and image files, a Windows Media server offers many advantages over standard Web servers.
More Efficient Network Throughput. We've already mentioned one of the main advantages of Windows Media server streaming—the ability to use UDP, the specialized protocol optimized for live and on-demand streaming. The TCP-based transfer used in Web server streaming is designed to repeatedly drive the slowest network link (likely the 28.8 Kbps modem link) to packet loss. This wastes bandwidth by: (i) re-transmitting data to replace the lost packets; and (ii) under-utilizing the network link while re-estimating the throughput that can be supported by the network connection.
The UDP protocol allows higher bandwidth to be delivered to the client (resulting in better video quality), even when assuming the same network connectivity between server and client and the same level of congestion on the Internet. By having a specialized streaming media server, we know what rate the data is going to be consumed, based on headers of the compressed media file. The Windows Media server sends data to the client (Windows® Media Player) only at this required bit-rate, and it doesn't drive the bottleneck network link to loss. Thus the network throughput is better, resulting in better quality audio and video for the client.
Better Audio and Video Quality to the User. Better network throughput is only one of several ways that a Windows Media server delivers superior audio and video quality for users. Here are two more examples:
Because the Windows Media server and the Windows Media Player remain in contact throughout the play interval, the server can dynamically respond to client feedback. If network congestion is allowing only 22 Kbps of data to reach the client (instead of 28.8 Kbps), the server can decide to retain the audio quality but slightly lower the frame rate of the video stream so that it doesn't overshoot the available 22 Kbps. This ability is not possible with the Web server approach. In a Web server scenario, with no feedback from the client and no ability to dynamically prioritize audio over video, the audio/video delivered by a Web server would be stop-and-go at the client, causing the insidious "rebuffering" delays common to early implementations of streaming media. In contrast, the Windows Media server provides a continuous, smooth stream with barely perceptible changes in video frame rate during periods of network congestion.
Streaming with a Windows Media server takes advantage of UDP's inherent higher priority over HTTP traffic to give the streaming audio and video data higher priority than file and Web page transfers. This increases the likelihood of uninterrupted viewing.
Support for Advanced Features. The Windows Media server approach supports such advanced features as detailed reporting of streams played, VCR controls (seek, fast-forward, rewind), live video delivery, and delivery of multiple streams to the client. With Web server streaming such features, if they are even possible, are difficult to implement and inefficient to support.
Cost Effective Scalability to Large Number of Users. In the early days of streaming media, deployments often needed to serve only a small number of users simultaneously, making Web server streaming an adequate solution. But as delivery of audio and video has increased, sites often serve hundreds or thousands of simultaneous users. In these situations, two key capabilities of the Windows Media server provide increasing advantages over a Web server:
Specialization. In the Web server approach, the Web server is used to deliver the media files to the client. Web servers, however, are optimized for delivering lots of small HTML files, not large media files. With high volumes of file requests, a Windows Media server greatly improves performance by optimizing how media files are read from the disk, buffered in main memory, and streamed onto the network. A Windows Media server can easily improve scalability by a factor of 2 to 3 over a Web server.
Multicast Support. One way to get live or stored audio and video to large audiences with minimum network congestion is to use multicast networking technology. Multicast allows a single media stream to be played simultaneously by multiple clients, drastically reducing bandwidth use. Only a specially designed streaming media server, such as a Windows Media server, has this capability.
Protection of Content Copyright. Because Web server streaming creates a local cached copy of every media file played, there is no way to prevent end users from copying the files to a personal directory for later viewing. This hurts content providers who have a pay-per-view business model, or who have an advertisement-based revenue model, as the end users need not visit their site repeatedly. With a Windows Media server, users can only stream data and are prevented from downloading the file directly to their hard disk. As data packets are received over the network, they are delivered directly to the client application with no easy way for the end user to intervene and make a copy.
Multiple Delivery Options. With a Windows Media server, the media may be streamed with the optimal UDP or Multicast protocols when possible, and streamed with the TCP protocol when necessary. This enables corporate users to view Internet content without compromising firewall security and ensures that all users on all networks can access all streaming media content. The Windows Media server implements its own version of the HTTP protocol to enable streaming through a firewall or proxy server while still retaining most of the advantages a Windows Media server.
Windows Media Services support four different protocol configurations, each offering specific benefits.
UDP – As detailed in the Windows Media server section, UDP provides the most efficient network throughput and can have a very positive impact on the user (player) experience. The only downside to UDP is that many network administrators close their firewalls to UDP traffic, limiting the potential audience of UDP-based streams
TCP – As detailed in the Web server section, TCP provides an adequate, though not necessarily efficient, protocol for delivering streaming media content from a server to a client. As customers often open the TCP ports in their firewalls, Windows Media Services can use the TCP protocol enable streaming media to flow through these firewalls, which often block UDP traffic.
HTTP + TCP – The Windows Media server can also support HTTP-based control commands along with TCP-based data delivery. This combination has the benefit of working with all firewalls that let Web traffic through (port 80) and provides much more control (fast forward, rewind, etc) than a standard Web server, but also adds some overhead to the raw TCP stream that decreases scalability.
Multicast – The Windows Media server can also support IP Multicast protocols to allow very efficient delivery of streaming content to large numbers of users. Multicast enables hundreds or thousands of users to play a single stream, but will only work on networks with Multicast-enabled routers. Multicast is becoming prevalent on corporate networks, but is still very rare on the Internet.
The Windows Media server will automatically switch to the appropriate protocol so no client-side configuration is necessary. The server will initially attempt to transmit files using the optimal UDP or Multicast protocols. If unable, the server will then attempt to send first via the raw TCP protocol, then via TCP with HTTP-based control.
Conclusion
This paper has evaluated the two primary methods for streaming media content to users. The first, the Web server approach, uses a standard Web server and the associated HTTP and TCP protocols to request and deliver the content for the client. The second approach uses a streaming media server specialized to the audio/video-streaming task. The specialization takes many forms, including optimized routines for reading the huge media files from disk, the flexibility to choose any of UDP/TCP/Multicast protocols to deliver data, and the option to exploit continuous contact between client and server to dynamically improve content delivery to the client.
The primary advantage of the Web server approach is that it requires one less software component (the streaming media server) to learn and manage. This method can be an effective first step in developing a streaming solution.
The streaming media server approach, using Microsoft Windows NT Server Windows Media Services, has these advantages:
More efficient use of the network bandwidth.
Better audio and video quality to the user.
Advanced features like detailed reporting and multi-stream multimedia content.
Supports large number of users.
Multiple delivery options.
Content copyright protection.
The tradeoffs clearly indicate that, for virtually all providers of streaming media content, the Windows Media server approach is the superior solution.
|
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 14 December 2003 : 17:00:22
|
quote:
Originally posted by HuwR
but it is still not streaming
So whys that info you posted refer to it as streaming then ?  honestly, I understand the difference between HTTP and unicast, multicast or reflective multicast for that matter, and agree 100% that http is not the most efficient way of providing video, but it does work and going back to Brads initial question it is an alternative depending just on the size of video hes offering up and just how many hits he's expecting it to get "Web server streaming can be an effective interim solution".
As for bitrates, I'm talking waaaay lower for my stuff no more than 128kb or so (sometimes I can get away with lower like 96kb) I usually watch it over a bluetooth connection. |
Kiwihosting.Net - The Forum Hosting Specialists
|
Edited by - Gremlin on 14 December 2003 17:01:34 |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 14 December 2003 : 17:49:56
|
quote:
Brads initial question it is an alternative depending just on the size of video hes offering up and just how many hits he's expecting it to get "Web server streaming can be an effective interim solution
And what else his web server is doing.
quote:
So whys that info you posted refer to it as streaming then ?
the media is not being streamed, the client is streaming the download which is a different thing entirely. |
|
|
|
sr_erick
Senior Member
USA
1318 Posts |
Posted - 14 December 2003 : 18:28:50
|
quote:
Originally posted by HuwR
the media is not being streamed, the client is streaming the download which is a different thing entirely.
Exactly, the client is downloading as fast as it can and then streaming it to the player. With streaming it is a much more steady flow. |
Erick
Snowmobile Fanatics
|
Edited by - sr_erick on 14 December 2003 18:29:13 |
|
|
|
Topic |
|
|
|
Topic Locked
