Seminar Topics

www.seminarsonly.com

IEEE Seminar Topics

Remote Media Immersion


Published on Mar 02, 2016

Abstract

The Remote Media Immersion (RMI) system is the result of a unique blend of multiple cutting-edge media technologies to create the ultimate digital media delivery platform. The main goal is to provide an immersive user experience of the highest quality. RMI encompasses all end-to-end aspects from media acquisition, storage, transmission up to their final rendering.

Specifically, the Yima streaming media server delivers multiple high bandwidth streams, transmission error and flow control protocols ensure data integrity, and high-definition video combined with immersive audio provide highest quality rendering. The RMI system is operational and has been successfully demonstrated in small and large venues. Relying on the continued advances in electronics integration and residential broadband improvement, RMI demonstrates the future of on-demand home entertainment.

STAGES OF RMI

Acquisition of high-quality media streams

This authoring component is an important part of the overall chain to ensure the high quality of the rendering result as experienced by users at a later time. As the saying "garbage in, garbage out" implies, no amount of quality control in later stages of the delivery chain can make up for poorly acquired media.

Real-time digital storage and playback of multiple independent streams

Yima Scalable Streaming Media Architecture provides real-time storage, retrieval and transmission capabilities. The Yima server is based on a scalable cluster design. Each cluster node is an off-the-shelf personal computer with attached storage devices and, for example, a Fast or Gigabit Ethernet connection. The Yima server software manages the storage and network resources to provide real-time service to the multiple clients that are requesting media streams. Media types include, but are not limited to, MPEG-2 at NTSC and HDTV resolutions, multichannel audio (e.g., 10.2 channel immersive audio), and MPEG-4.

Protocols for synchronized, efficient realtime transmission of multiple media streams

A selective data retransmission scheme improves playback quality while maintaining realtime properties. A flow control component reduces network traffic variability and enables streams of various characteristics to be synchronized at the rendering location. Industry standard networking protocols such as Real-Time Protocol (RTP) and Real-Time Streaming Protocol (RTSP) provide compatibility with commercial systems.

Rendering of immersive audio and high resolution video

Immersive audio is a technique developed at IMSC for capturing the audio environment at a remote site and accurately reproducing the complete audio sensation and ambience at the client location with full fidelity, dynamic range and directionality for a group of listeners (16 channels of uncompressed linear PCM at a data rate of up to 17.6Mb/s). The RMI video is rendered in HDTV resolutions (1080i or 720p format) and transmitted at a rate of up to 45 Mb/s.

OVERVIEW OF COMPONENTS

The overall objective of the RMI research endeavor is to achieve the best possible quality at each rendering location for a group of participants. Group sizes may range from a single person or family at home to a large venue seating hundreds. For the visual streams we decided that we required at least high-definition (HD) resolution as defined by ATSC1. The highest quality ATSC modes are either 1920 × 1080 pixels at an interlaced frame rate of 29.97 per second, or 1280 × 720 pixels at a progressive frame rate of 59.94 per second. For the audio rendering we rely on the immersive audio technology developed at IMSC which utilizes a 10.2 channel playback system. The rendering capabilities of immersive audio goes much beyond current stereo and 5.1 channel systems. The combination of 10.2 channels of immersive audio and high-definition video is the next step in audio-visual fidelity.

Each presentation session retrieves and plays back at least one high-definition visual and one immersive aural stream in synchronization. Note that this choice was imposed by the available media content and is not an inherent limitation in the Yima design. The streams are stored separately on the server for two reasons. First, the RMI system is designed to be extensible such that additional video or other streams may become part of a presentation in the future. Second, allowing streams to be separately stored enables RMI to retrieve different components of a presentation from different server locations. The final, fine-grained synchronization is achieved at the client side. The on-demand delivery of the streams that form anRMI presentation is enabled through our streaming media architecture called Yima. With features such as scalability, multi-stream synchronization, transmission error and flow control, it is uniquely suited for RMI-style media delivery.

DELIVERY OF HIGH-RESOLUTION MEDIA

An important component of delivering isochronous multimedia over IP networks to end users and applications is the careful design of a multimedia storage server. The task of such a server is twofold: (1) it needs to efficiently store the data and (2) it must schedule the retrieval and delivery of the data precisely before it is transmitted over the network. RMI relies on our Yima streaming media architecture. Yima has been designed from the ground up to be a scalablemedia delivery platform that can support multiple very high bandwidth streams.

Remote Media Immersion

Figure shows the server cluster architecture which is designed to harness the resources of many nodes and many disk drives per node concurrently.

Our current implementation the server consists of a 4- way cluster of rack-mountable PCs running Red Hat Linux, however, larger configurations are possible to increase the number of concurrent RMI sessions supported. Each cluster node is attached to a local network switch with a Fast or Gigabit Ethernet link. The nodes communicate with each other and send the media data via these network connections. The local switch is connected to both a WAN backbone (to serve distant clients) and a LAN environment with local clients.

Choosing an IP based network keeps the per-port equipment cost low and is immediately compatible with the public Internet. The media data is stored in segments (called blocks) across multiple, say four, high performance hard disk drives. There are two basic techniques to assign the data blocks of a media object – in a load balanced manner – to the magnetic disk drives that form the storage system: in a round-robin sequence, or in a random manner. Yima uses a pseudo-random data placement in combination with a deadline-driven scheduling approach.

Error Control with Selective Retransmissions from Multiple Server Nodes

One of the characteristics of continuous media streams is that they require data to be delivered from the server to a client location at a predetermined rate. This rate may vary over time for streams that have been compressed with a variable bit rate (VBR) media encoder. VBR streams enhance the rendering quality, however they will generate bursty traffic on a packet switched network such as the Internet. This in turn can easily lead to packet loss due to congestion. Such data loss adversely affects compressed audio and video streams because much of the temporal or spatial redundancy in the data has already been removed by the compression algorithm.

Furthermore, important data such as audio/video synchronization information may get lost that will introduce artifacts in a stream for longer than a single frame. As a result it is imperative that as little as possible of a stream’s data is lost during the transmission between the server and a rendering location. The Yima cluster architecture takes advantage not only of the distributed storage resources among the multiple nodes, but also of the multiple network connections that link all the nodes together. Media data is transmitted via the real-time protocol (RTP) encapsulated in connection-less UDP datagrams. To avoid traffic bottlenecks, each node transmits the data blocks that it holds directly to the clients via RTP. Hence, each client will receive RTP data packets fromeach server nodewithin the cluster












Are you interested in this topic.Then mail to us immediately to get the full report.

email :- contactv2@gmail.com

Related Seminar Topics