Thursday, May 31, 2012


---------- Forwarded message ----------
From: "3D CineCast" <>
Date: May 31, 2012 4:05 AM
Subject: 3D CineCast
To: <>

3D CineCast


Posted: 30 May 2012 07:13 AM PDT

Broadcast contribution applications like newsgathering, event broadcasting or content exchange currently benefit from the large availability of high-speed networks. These high-bandwidth links open the way to a higher video quality and distinctive operational requirements such as lower end-to-end delays or the ability to store the content for further edition.

Because a lighter video compression is needed, the complexity of common long-GOP codecs can be avoided, and simpler methods like intra-only compression can be considered. These techniques compress pictures independently, which is highly desirable when low latency and error robustness are of major importance. Several intra-only codecs, like JPEG 2000 or MPEG-2 Intra, are today available, but they might not meet all broadcasters' needs.

AVC-I, which is simply an intra-only version of H.264/AVC compression, offers a significant bit-rate reduction over MPEG-2 Intra, while keeping the same advantages in terms of interoperability. AVC-I was standardized in 2005, but broadcast contribution products supporting it were not launched until 2011. Therefore, it may be seen as a brand new technology, and studies have to be performed to evaluate if they match currently available technologies in operational use cases.

Why Intra Compression?
Video compression uses spatial and temporal redundancies to reduce the bit rate needed to transmit or store video content. When exploiting temporal redundancies, predicted pixels are found in already decoded adjacent pictures, while spatial prediction is built with pixels found in the same picture. Long-GOP compression makes use of both methods, and intra-only compression is restricted to spatial prediction.

Long-GOP approaches are more efficient than intra-only compression, but they have also distinctive disadvantages:
  • Handling picture dependencies may be complex when seeking in a file. This makes editing a long-GOP file a complex task.

  • Any decoding error might spread from a picture to the following ones and span a full GOP. This means that a single transmission error can affect decoding for several hundred milliseconds of video and, therefore, be very noticeable.

  • Encoding and decoding delay might be increased using long-GOP techniques compared to intra-only because of compression tools complexity.

Another problem inherent to long-GOP compression relates to video quality that varies significantly from picture to picture. For example, the figure below depicts the PSNR along the sequence ParkJoy when encoding it in long-GOP and in intra-only. While the quality of the long-GOP pictures is always higher than the one of their intra-only counterparts, it varies considerably. On the other hand, the quality of consecutive intra-only coded pictures is much more stable.

Long-GOP versus intra-only compression.

Therefore, intra-only compression might be a better choice than long-GOP when:
  • Enough bandwidth is available on the network;
  • Low end-to-end latency is a decisive requirement;
  • Streams have to be edited; and
  • The application is sensitive to transmission errors.

Several intra-only codecs are currently available to broadcasters to serve the needs of contribution applications:
  • MPEG-2 Intra — This version of MPEG-2 compression is restricted to the use I-frames, removing P-frames and B-frames.

  • JPEG 2000 — This codec is a significantly more efficient successor to JPEG that was standardized in 2000.

  • VC-2 — Also known as Dirac-Pro, this codec has been designed by BBC Research and was standardized by SMPTE in 2009. Like JPEG 2000, it uses wavelet compression.

Older codecs like MPEG-2 Intra benefit from a large base of interoperable equipments but lack coding efficiency. On the other hand, more recent formats like JPEG 2000 are more efficient but are not interoperable. Consequently, there is a need for a codec that could be at the same time efficient and also ensure interoperability between equipment from various vendors.

What is AVC-I?
AVC-I designates a fully compliant variant of the H.264/AVC video codec restricted to the intra toolset. In other words, it is just plain H.264/AVC using only I-frames. But, some form of uniformity is needed in order to ensure interoperability between equipment provided by various vendors. Therefore, ISO/ITU introduced a precise definition in the form of profiles (compression toolsets) in the H.264/AVC standard.

H.264/AVC Intra Profiles
Provision to using only I-frame coding was introduced in the second edition of the H.264/AVC standard with the inclusion of four specific profiles: High10 Intra profile, High 4:2:2 Intra profile, High 4:4:4 Intra profile and CAVLC 4:4:4 Intra profile. They can be described as simple sets of constraints over profiles dedicated to professional applications. Thez Table below gives an overview of the main limitations introduced by these profiles:

Because the intra profiles are defined as reduced toolsets of commonly used H.264/AVC profiles, they don't introduce new features, technologies or even stream syntax. Therefore, AVC-I video streams can be used within systems that already support standard H.264/AVC video streams. This enables the usage of file containers like MPEG files or MXF, MPEG-2 TS or RTP, audio codecs like MPEG Audio or Dolby Digital, and many metadatastandards.

AVC-I and JPEG-2000 Artifacts
Below 100Mb/s, a problematic defect was observed similarly on both codecs: Pictures can exhibit an annoying flicker. This issue is caused by a temporal instability in the coding decisions, amplified by noise. It seems to appear below 85Mb/s with JPEG 2000 and below 75Mb/s with AVC-I. And, it worsens as the bit rate decreases. At 50Mb/s and below, the flicker is extremely problematic, and it was felt that the video quality was too low for high-quality broadcast contribution applications, even when the source is downscaled to 1440 × 1080 or 960 × 720.

Around 100Mb/s, both codecs perform well, even on challenging content. Pictures are flicker-free, and coding artifacts are difficult to notice. However, noise or film-grain looks low-pass filtered, and its structure sometimes seems slightly modified. Even so, it wasn't felt this was an important issue.

All those defects are less visible as the bit rate is increased. But, while AVC-I picture quality raises uniformly, some JPEG 2000 products may still exhibit blurriness artifacts, even at 180Mb/s. Using available JPEG 2000 contribution pairs, a bit rate at which compression is visually lossless on all high-definition broadcast content was not found. On the other hand, some encoders appeared visually lossless at 150Mb/s, even when encoding grainy content like movies.

Bit Rates in Contribution
The subjective analysis of an actual AVC-I implementation on various broadcast contribution content allows us to categorize its usage according to the available transmission bandwidth. The table below presents findings on 1080i25 and 720p50 high-definition formats:

Because AVC-I does not make use of temporal redundancies, 30Hz content (1080i30 or 720p60) is more difficult to encode than 25Hz material. Additionally, to achieve the same perceived video quality level, bit rates have to be raised by 20 percent.

The availability of high speed networks for contribution applications enables broadcasters to use intra-only video compression codecs instead of the more traditional long-GOP formats. This allows them to benefit from distinctive advantages like: low encoding and decoding delays; more constant video quality; easy edit ability when the content is stored; and lower sensitivity to transmission errors. However, currently available intra-only video codecs require one to choose between interoperability and coding efficiency.

AVC-I, being just the restriction of standard H.264/AVC to intra-only coding, avoids making difficult compromises. It is more efficient than other available intra-only codecs, but, more importantly, it benefits from the strong standardization efforts that permitted H.264/AVC to replace MPEG-2 in many broadcastapplications.

Finally, a subjective study across a range of products from multiple vendors identified specific coding artifacts that may occur and confirmed the visual superiority of AVC-I versus MPEG-2 and JPEG 2000, when measured at high bit rates.

Pierre Larbier, CTO for ATEME, Broadcast Engineering

EBUCore: the Dublin Core for Media

Posted: 30 May 2012 05:30 AM PDT

EBUCore was first published in 2000. It was originally a set of definitions for audio archives, applied to the Dublin Core, which is itself a generic set of descriptive terminology that can be applied to any content. XML was then in its infancy but its use would grow dramatically, demanding more structured information to describe audiovisual content. Since then, other semantic languages have greatly influenced the way this information is modelled. EBUCore followed this evolution to become what it is today: the Dublin Core for media, a framework that can be used to describe just about any media content imaginable.

EBUCore is the fruit of well-defined requirements and an understanding of user and developer habits. User friendliness, flexibility, adaptability and scalability are more important than richness and comprehensiveness allied to impossible compliance rules. The richer the metadata, the higher the likelihood that implementers will reinvent their own. History is full of such examples. The golden rule for EBUCore was and remains "keep it simple and tailor it for media".

EBUCore covers 90% of users' needs and its use is no longer restricted to audio or archives. Based on the simple and flexible EBU Class Conceptual Data Model (CCDM), EBUCore's ontology (categories and structure), which is expressed in RDF/OWL (Resource Description Framework/Web Ontology Language), can be used right through to the delivery of content to the end user. It responds to the need for more effective querying. It also paves the way for effective metadata enrichment using Linked Open Data (LOD).

EBUCore was designed to be a metadata specification for "users with different needs" and duly serves this goal. Delegates at the EBU's Production Technology Seminar last January heard a wealth of evidence pointing to the key role that EBUCore is now playing. Several speakers explained how they have deliberately chosen and benefited from EBUCore.

The EBU-AMWA FIMS project, creating a vendor-neutral specification to interconnect production equipment, has adopted EBUCore. The FIMS 1.0 specification uses EBUCore as its core descriptive and technical metadata. FIMS is a vital project for the future of file-based production and feedback received from participants has influenced the most recent version of EBUCore. Early adopters of FIMS, such as Bloomberg, are using this metadata.

The UK's Digital Production Partnership (DPP), which recently published its new specification for file-based programme delivery, is mapping its metadata to EBUCore and TV-Anytime. (TV-Anytime was co-founded by the EBU, who chaired the metadata activities and now actively maintains the specification on behalf of ETSI).

The work on EBUCore and EBU's CCDM greatly influenced the development of W3C Ontology for Media Resources, and vice versa. MA-ONT, as it is known, is a subset of the EBUCore ontology and the RDF/OWL representation rules are common to both. This work is also being used to propose extensions to the in order to describe TV and radio programmes and associated services and schedules.

EBUCore is also used as the solution for metadata aggregation in EUScreen, the European audiovisual archives portal and now a key contributor to Europeana, the European digital library. Two forms of EBUCore are used in this context, the EBUCore XML metadata schema and also the EBUCore RDF ontology.

Other on-going or planned activities using EBUCore include:
• EBUCore will be listed as a formal metadata type by the SMPTE. The EBU is arranging for software to be available to embed EBUCore metadata in languages such as XML or JSON.

• The NoTube project has combined egtaMeta (an EBU specification extending the EBUCore for the exchange of commercials) and TVAnytime to develop innovative solutions in targeting advertising.

• EBUCore is also used in combination with MPEG-7 in the VISION Cloud project exploring technologies for storage in the cloud. The EBU is directly involved in the definition and promotion of the new MPEG-7 AVDP profile.

• Singapore's national broadcaster, MediaCorp, has implemented and adapted EBUCore/SMMCore into its internal company metadata framework.

• The EBU is engaged with several broadcasters for the adaptation of EBUCore in different contexts such as a common metadata format for file exchange.

The above is just a small selection of developments. For example, EBUCore is also republished by the Audio Engineering Society (AES) as AES60, and is available in XML, SMPTE KLV, JSON and RDF/OWL.

Watch this space as the EBU will soon publish a user-friendly EBUCore mapping tool on its website.

By Jean-Pierre Evain, EBU Technical Magazine

Let's DASH!

Posted: 30 May 2012 05:08 AM PDT

In the last century, access to video delivered over networks was almost exclusively dominated by scheduled consumption on dedicated devices – broadcasters distributed premium content at a specific time to TV sets. Broadband internet, both fixed and mobile, as well as highly capable devices such as smartphones and tablets have changed video consumption patterns dramatically in recent years. Video is now consumed on-demand on a multiplicity of devices according to the schedule of the user.

Recent studies conclude that mobile data traffic will grow by a factor of 26 between 2011 and 2016 and that by 2016 video traffic will account for at least two-thirds of the total. The popularity of video also leads to dramatic data needs on the fixed internet. In North America, real-time entertainment traffic (excluding p2p video) today contributes more than 50% of the downstream traffic at peak periods, with notably 30% from Netflix and 11% from YouTube.

HTTP Delivers
The astonishing thing is that these data needs are not driven by traditional broadcast, IP multicast or managed walled-garden services, but by over-the-top video providers. One of the cornerstones of this success is the use of HTTP as the delivery protocol. HTTP enables reach, universal access, connectivity to any device, fixed-mobile convergence, reliability, robustness, and the reuse of existing delivery infrastructure for scalable distribution.

One of the few downsides of HTTP-based delivery is the lack of bitrate guarantees. This can be addressed by enabling the video client to dynamically switch between different quality/bitrate versions of the same content and therefore to adapt to changing network conditions. The provider offers the same media content in different versions and the client can itself select and switch to the appropriate version to ensure continuous playback. The figure below shows a typical distribution architecture for dynamic adaptive streaming over HTTP. HTTP-based Content Delivery Networks (CDNs) have been proven to provide an easy, cost-efficient and scalable means for large-scale video streaming services.

Click to enlarge

Setting a Standard
MPEG has taken the lead on defining a unified format for enabling Dynamic Adaptive Streaming over HTTP (DASH). MPEG-DASH was ratified in 2011 and published as a standard (ISO/IEC 23009-1) in April 2012. It is an evolution of existing proprietary technologies that also addresses new requirements and use cases. DASH enables convergence by addressing mobile, wireless and fixed access networks, different devices such as smartphones, tablets, PCs, laptops, gaming consoles and televisions, as well as different content sources such as on-demand providers, broadcasters, or usergenerated content offerings.

The standard defines two basic formats: the Media Presentation Description (MPD) uses XML to provide a manifest of the available content, its various alternatives, their URL addresses, and other characteristics; and Segments, which contain the actual media streams in the form of chunks, in single or multiple files. In the context of part 1 of MPEG-DASH the focus is on media formats based on the ISO Base Media File Format and the MPEG-2 Transport Stream.

With these basic formats MPEG-DASH provides for a very wide range of use cases and features, including support for server and client-side component synchronization and for efficient trick modes, as well as simple splicing and (targeted) ad insertion and session metrics. DASH can support multiple Digital Rights Management systems, content metadata, and support for advanced codecs including 3D video and multi-channel audio.

Towards Deployment
With the completion of the standard the focus has shifted towards deployment and commercialization of DASH. In this context MPEG will later this year publish Conformance Software and Implementation Guidelines and continues to work on client implementations and optimizations. This is especially relevant for a stable and consistent user experience under varying network conditions.

On the distribution side, coming optimizations include DASH for CDNs – to improve efficiency, scalability and user experience – along with integration into mobile networks and transition between unicast and multicast distribution.

The creation of the DASH Promotors' Group will help to address interoperability and promotional activities. The EBU is among the 50 major industry players that make up this group. Support is also provided for other standards planning to include MPEG-DASH to enable over-the-top video, including HbbTV, DLNA, the Open IPTV Forum and 3GPP. Furthermore, the W3C consortium is considering extensions to the HTML5 video tag that would aid the integration of DASH into web browsers.

The significant efforts currently under way to deploy DASH in a wide range of contexts raise the expectation that MPEG-DASH will become the format for dynamic adaptive streaming over HTTP.

By Thomas Stockhammer, EBU Technical Magazine
You are subscribed to email updates from 3D CineCast
To stop receiving these emails, you may unsubscribe now.
Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

No comments: