You can use Media Server to enhance static textual and graphical documents with real-time audio, delivered instantly live and on demand to work within existing computer and network infrastructures.
Unicasting and multicasting clips and live feed:
Media Server lets users play back live audio feeds using Internet Protocol multicast or on-demand access to pre-recorded audio clips. Media Server can unicast or multicast both stored audio clips and live feeds. Unicast is a type of broadcast that delivers packets to a single destination, whereas multicast delivers packets to only a subset of all possible destinations.
Businesses can take advantage of these features to deploy audio-enabled network applications such as:
Multimedia training applications for employees on an intranet and outside partners on the Internet.
Internal and external publications whose visibility and effectiveness are enhanced by audio content.
Broadcast audio briefings over the network to communicate with internal and external partners.
Multicasting is not limited to data captured live from an audio device; you can also loop a stored audio file and serve it as a live feed, a method that can help alleviate network traffic problems on high demand sites.
A theater site could, for example, record a listing of all currently playing movies, along with show times, special offers, and ticket prices and then multicast and loop the file. A customer who tunes in mid-multicast could simply stay tuned until the file starts playing again.
Serving synchronized multimedia presentations:
You can employ Media Server to synchronize audio with HTML documents, Java applets, and JavaScript applications using LiveConnect. The result is a dynamic user experience that integrates text, graphics, and audio to facilitate more effective communication.
A business site could, for example, provide a multimedia presentation of its benefits policies that includes videos with synchronized audio narration. Another alternative would be a motion picture site presenting synchronized audio and video clips from a new movie.
Protocol Using LiveMedia Streaming:
Media Server supports the LiveMedia Streaming Protocol (LMSP). LMSP is a protocol used for on-demand access of multimedia objects such as stored real-time audio files and live real-time feeds.
LMSP is a hybrid protocol that:
Uses Session Control Protocol (SCP) over TCP for control messages and non-real-time data
Optionally uses Real-Time Transfer Protocol (RTP) over User Datagram Protocol (UDP) for real-time data delivery
Connection settings exist that allow you to choose a UDP connection, or request TCP transport or RTP framing.
Creating high-quality audio at low bandwidth:
High-quality digital audio is bandwidth intensive. Short, monaural speeches require megabytes of data, and CD-quality stereo music requires even more. To transmit this information efficiently over a network without loss of quality, you need sophisticated audio compression and decompression modules (codecs). More importantly, to create the best possible listening experience, audio delivery must be optimized for the available network bandwidth.
Multiple codec support:
By supporting muliple codecs, Media Server provides the following benefits:
It encodes audio content at multiple compression ratios to ensure high-quality delivery using available network bandwidth.
- It produces high-quality speech at less than 4.8 Kbps.
- It produces broadcast-quality stereo audio at less than 28.8 Kbps modem speeds.
- It produces CD-quality stereo audio at Integrated Services Digital Network (ISDN) and LAN speeds.
- It allows additional codecs to be utilized by the server.
Creating your audio files:
Media Server supports .av files on Unix, .wav files, and LiveAudio (.la) files, in which you can store compressed (constant or variable bit-rate) audio. You can create LiveAudio files using Media Converter included with Media Server. You can also use the Media Converter to compress .wav files.
Recording audio files:
You can use any recording device appropriate for creating audio files to record audio files to serve with Media Server. When recording your files, you can use Media Converter to optimize the recording format for a specific codec.
You can include Media Player controls for Play/Pause, Stop, and Volume. You can also include a position slider for seeking within an audio file, and an Options button that displays a drop-down menu from which a user can display a Properties dialog box for information about the current clip.
The Media Player controls appear in a rectangular space, which can be a frame separate from your page's other content. You could, for example include a header frame, a main frame with text, images, or video, and a plug-in frame containing Media Player controls. You can also embed multiple sets of controls in a single HTML page so that clients can play multiple audio files.
On a Windows 3.1, Windows 95, or Windows NT system, Media Player functions as an MCI driver that you can also configure through a control panel on your systems.
INTRODUCTION TO CONTINUOUS MEDIA SERVER
Description: Yima is a second-generation scalable, real-time streaming architecture, which enables applications such as video-on-demand and distance learning on a large scale. Yima is consistent with industry standards and can support heterogeneous magnetic disks and achieve fault-tolerance.
Advantages: Compatible with industry standards, such as MPEG-4, MPEG-1, MPEG-2, Quicktime video formats, HDTV and RTP/RTSP network protocols.
It can stream a wide array of media types over IP.
Complete distribution where all nodes run identical software and single points of failure are eliminated.
Efficient, online scalability of disks where disks can be added or removed without stream interruption.
Frame-accurate synchronization of several independent streams of audio and/or video.
Smooth, client-dictated transmission rate control.
Runs on commodity, off-the-shelf hardware (i.e. personal computers, Ethernet.)
Applications :
- Video-on-demand
- News-on-demand
- E-commerce
- Distance learning
- Corporate training
- Scientific visualization
The Yima server is based on a scalable cluster design. Each cluster node is a off-the-shelf personal computer with attached storage devices and, for example, a Fast Ethernet connection. The Yima server software manages the storage and network resources to provide real-time service to the various clients that are requesting media streams.
The Yima clients run on either Windows or Linux and may utilize a hardware or software decoder to display media streams. We can implemented a number of different clients that support a variety of display bandwidths from less than 1 Mb/s to more than 20 Mb/s.
The following media types are currently supported:
" DVD (MPEG-2 video, Dolby Digital (AC3) audio) at 5-8 Mb/s
" HDTV (MPEG-2 video, Dolby Digital (AC3) audio) from 19.4 Mb/s to 45 Mb/s.
" DivX;-) (MPEG-4 video and MP3 audio) at 600-800 Kb/s
" Panoramic video (5 MPEG-2 video channels frame accurately synchronized) at a total of 25 Mb/s
" Multi-channel audio (up to 16 channels of uncompressed PCM audio sample accurately synchronized) at a total of 10.8 Mb/s
RealNetworks, Apple Computer, and Microsoft product offerings fit into the consumer-oriented category while SeaChange and nCube offer solutions oriented toward carrier-class systems. While commercial systems ordinarily use proprietary technology and algorithms, making it difficult to compare their products with research prototypes, we have designed and developed a second-generation (CM) Continuous media server that demonstrates several advanced concepts.
What is yima ?
Yima is a name denoting the first man in ancient Iranian religion.
While Yima has not achieved the refinement of commercial solutions,it is operational and incorporates lessons learned from first-generation research prototypes.1,2.
Yima distinguishes itself from other similar research efforts in the following:
• complete distribution with all nodes running identical software and no single points of failure;
• efficient online scalability allowing disks to be added or removed without interrupting CM streams;
• synchronization of several streams of audio, video, or both within one frame (1/30 second);
• independence from media types;
• compliance with industry standards;
• selective retransmission protocol; and
• multithreshold buffering flow-control mechanism to support variable bit-rate (VBR) media.
SYSTEM ARCHITECTURE
Yima, a scalable real-time streaming architecture, incorporateslessons learned from earlier research prototypes to enable advanced
continuous media services.
Yima is also a complete end-to-end system that uses an IP network with several supportable client types. This feature distinguishes it from previous research that focused heavily on server design.
Figure 1 shows the overall Yima system architecture.
In our prototype implementation, the server consists of:
An eight-way cluster of rack-mountable Dell PowerEdge 1550 Pentium III 866-MHz PCs with 256 Mbytes of memory running Red Hat Linux. Sixteen 36-Gbyte Seagate Cheetah hard-disk drives store the media data and connect to the server nodes via Ultra160 small computer systeminterface (SCSI) channels.
The nodes in the cluster communicate with each other and send the media data via multiple 100-Mbps Fast Ethernet connections. Each server is attached to a local Cabletron 6000 switch with either one or two Fast Ethernet lines.
 |
| Figure1. Yima system architecture. |
The local switch connects to both a WAN backbone for serving distantclients and a LAN environment for local clients. Ourtestbed also includes server clusters at other remote locations, for example, Metromedia Fiber Network in El Segundo, California, and Information Sciences Institute East in Arlington, Virginia.
Choosing an IP-based network keeps the per-port equipment cost low and makes the system immediately compatible with the public Internet.
The current prototype implements clients on standard Pentium III PC platforms, but we could also port them to digital television set-top boxes. The client software, Yima Presentation Player, runs on either Red Hat Linux or Windows NT. Structured into several components, the player lets various software and hardware decoders be plugged in. Table 1 shows the different media types that Yima currently recognizes. One unusual type is panoramic video with 10.2-channel audio.
SERVER DESIGN CHALLENGE
The servers for delivering isochronous multimedia over IP networks must store the data efficiently and schedule the data retrieval and delivery precisely before transmission. We studied both master-slave and bipartite design approaches in the Yima-1 and Yima-2 contineous media (CM) servers, respectively. These approaches share many features that address design challenges in this domain. They differ mainly in the logical interconnection topology between cluster nodes.
Data placement and scheduling
There are two ways to assign data blocks to the magnetic disk drives that form the storage system: in a round-robin placement or randomly. Traditionally, round-robin placement uses a cycle-based approach for resource scheduling to guarantee a continuous display, while random placement uses a deadline-driven approach. In general, the round-robin cycle-based approach provides high throughput with little wasted band-width for video objects that are retrieved sequentially, such as a feature-length movie. The startup latency for an object might be large under heavy loads, but object replication can reduce it.
The random deadline-driven approach supports fewer optimizations, so it could lower throughput, but several benefits outweigh this potential drawback. First, random data placement supports multiple delivery rates with a single server block size; it also simplifies the scheduler design, supports interactive applications, and automatically achieves the average transfer rate with multizoned disks.Finally, random placement reorganizes data more efficiently when the system scales up or down.
Random placement can require a large amount of metadata to store and manage each block’s location in a centralized repository, for example, in tuples of the form
Hence, Yima stores only the seed for each file object instead of locations for every block.
0 comments:
Post a Comment
Thanks for your Valuable comment