What is IMF and Why Do You Need It?

A nice video introduction to IMF by Bruce Devlin.

H.264 Video Codecs Comparison

The MSU Graphics & Media Lab has released its eighth H.264 video codecs comparison. The main goal of this report is the presentation of a comparative evaluation of the quality of new H.264 codecs using objective measures of assessment.

The comparison was done using settings provided by the developers of each codec. The main task of the comparison is to analyze different H.264 encoders for the task of transcoding video—e.g., compressing video for personal use. Speed requirements are given for a sufficiently fast PC; fast presets are analogous to real-time encoding for a typical home-use PC.

The overall ranking of the software codecs tested in this comparison is as follows:

1. x264
2. MainConcept
3. DivX H.264
4. Elecard
5. Intel Ivy Bridge QuickSync
6. XviD
7. DiscretePhoton
8. MainConcept CUDA

This rank is based only on the encoders’ quality results. Encoding speed is not considered here.



Click to enlarge

x264 HDTV “High Quality” Settings
1-st pass:
--tune ssim --pass 1 --keyint 500 --preset slow

2-nd pass:
--tune ssim --pass 2 --keyint 500 --preset slow

Source: MSU Graphics & Media Lab

Distributed Media Facilities

This article connects the dots among Serial Digital Interface (SDI), image compression, the invention of the Advanced Authoring Format / Material eXchange Format (AAF / MXF) data model, the MXF wrapper format, the subsequent development of AS-02, AS-03 and other MXF application specifications, developments in high-speed networking technology and network security, the SMPTE 2022 Standard for Professional Video over IP transmission, the recent activities of the Hollywood-based ETC’s Interoperable Mastering Format (IMF), which has recently moved into SMPTE, and the Advanced Media Workflow Association / European Broadcasting Union (AMWA / EBU) Task Force on the Framework for Interoperable Media Services (FIMS), concentrating on service-oriented media workflows.

Understanding the MPEG-4 Movie Atom

An atom is a self-contained data unit that contains information about an MP4 file. The moov atom, also referred to as the movie atom, defines the timescale, duration, display characteristics of the movie, as well as subatoms containing information for each track in the movie. The optimal location of the moov atom depends on the selected delivery method.

MPEG-4 Stream Packaging
For Flash Player to be able to play back an MPEG-4 (MP4) file, the file must be packaged in a specific type of container—one that follows the MPEG-4 Part 12 (ISO/IEC 14496-12) specification. Stream packaging is the process of making a multiplexed media file. Also known as muxing, this procedure combines multiple elements that enable control of the distribution delivery process into a single file. Some of these elements are represented in self-contained atoms.

As mentioned at the outset, an atom is a basic data unit that contains a header and a data field. The header contains referencing metadata that describes how to find, process, and access the contents of the data field, which may include (but is not limited to) the following components:

• Video frames
  
• Audio samples
  
• Interleaving AV data
  
• Captioning data
  
• Chapter index
  
• Title
  
• Poster
  
• User data
  
• Various technical metadata: codec, timescale, version, preferred playback rate, preferred playback volume, movie duration, etc.

In an MPEG-4–compliant container, every movie contains a moov atom. Normally, a movie atom contains a movie header atom (an mvhd atom) that defines the timescale and duration information for the entire movie, as well as its display characteristics. The movie atom also contains one track atom (a trak atom) for each track in the movie. Each track atom contains one or more media atoms (an mdia atom) along with other atoms that define other track and movie characteristics.

In this tree-like hierarchy, the moov atom acts as an index of the video data. It is here that the MPEG-4 muxer stores information about the file to enable the viewer to play and scrub the file. The file will not start to play until the player can access this index.

Unless specified otherwise, the moov atom is normally stored at the end of the file in on-demand content, after all of the information describing the file has been generated. Depending on the type of on demand delivery method selected—progressive download, streaming, or local playback—the location will need to move either to the end or to the beginning of the file.

If the planned delivery method is progressive download or streaming (RTMP or HTTP), the moov atom will have to be moved to the beginning of the file. This ensures that the required movie information is downloaded first, enabling playback to start right away.

If the moov atom is located at the end of the file, it forces the download of the entire file first before it will start playback. If the file is intended for local playback, then the location of the moov atom will not impact the start time, since the entire file is available for playback right away.

The placement of the moov atom is specified in various software packages through settings such as "progressive download," "fast start," "use streaming mode," or similar options. Software packages such as MP4creator or AtomicParsley enable you to analyze the location of the moov atom in your encoded files (see Figures 1 and 2).



Figure 1 - Analysis of a video file in AtomicParsley, showing the atom located at the beginning of the file structure.



Figure 2 - The atom is located at the end of the file structure.

Some tools enable relocation of the moov atom to the beginning of the file's structure through post processing of the compressed MPEG-4 (MP4) file. One such tool is MP4Creator, mentioned earlier, and another is MP4 FastStart. The best way to handle the moov atom location, however, is to set it during the compression and muxing portion of the encoding process. This minimizes the probability of the moov atom inadvertently being placed at the end.


Issues with edts Atom Handling
An edts atom contained in the trak atom of a moov atom located within an MP4 container hierarchy is responsible for tracking times and durations of the media. Flash Player architecture is designed to ignore the existence of an edts atom; however, an edts atom containing invalid or broken data may interfere with smooth and stable switching of HTTP packaged streams. Therefore, it is important to repair or remove an invalid edts atom prior to packaging the file for HTTP Dynamic Streaming.

The broken edts atom can be eliminated from a file using tools such as FLVCheck for file conformance, MP4Creator for structure analysis, and AtomicParsley for removal of metadata (see Figures 3 and 4).



Figure 3 - An original analyzed MPEG-4 file by MP4Muxer/MP4Creator. This illustrates the existence and location of an edts atom within the file. This file was found to have invalid edts data.



Figure 4 - An MPEG-4 file created by AtomicParsley. This illustrates removal of invalid edts atom and moov atom relocation to the beginning of the structure.

The AtomicParsley command responsible for removing atoms is represented in the following string:

AtomicParsley.exe filename.mp4 --manualAtomRemove "moov.trak.edts" --manualAtomRemove "moov[2].trak.edts" --overWrite

Here, filename.mp4 is the name of the file being processed and --manualAtomRemove is a command that initiates the removal of the specific atom, edts, which is hierarchically located within the trak atom, which is within the moov atom. If the file contains more than one trak atom, such as audio and video media elements, then the track number is added to the "moov.trak.edts" as shown above. By default, AtomicParsley removes the atom from the first moov atom track. Adding the next track number in sequence, or a track number of your choice, forces AtomicParsley to proceed to that atom number next (for example, moov[2].trak.edts). To edit all track numbers, repeat the command for each track. Adding the command string --overWrite overwrites your original processed file.


Tools

• AtomicParsley (command-line program for reading and parsing MPEG-4 files)
  
• FLVCheck (MPEG-4 checker)
  
• MP4Box (multimedia packager)
  
• MP4Creator (MPEG-4 file creater and modifier)
  
• MP4 FastStart (starts MPEG-4 progressive downloads immediately)
  
• QTIndexSwapper (starts H.264 progressive downloads immediately)

By Maxim Levkov, Adobe

What Follows HDTV?

This document has been prepared by the EBU ‘BeyondHD’ Project that is part of the strategic programme on Future Television Systems. It is intended for EBU Members’ senior management and provides a general technical overview about future TV formats.

ITU Drafts New Recommendations to Boost 3DTV

To get it out of the doldrums it remains in, 3D needs as much help as possible and the latest leg-up has been given by the International Telecommunication Union (ITU) the United Nations agency for information and communication technology.

The ITU has drafted a series of recommendations, submitted to its Administrations for accelerated approval, on 3DTV that are intended to promote the further use of this format worldwide and which the ITU hopes will provide much needed tools to evaluate, make, and exchange 3DTV programmes. The ITU’s Radiocommunication Sector (ITU-R) has developed the standards in collaboration with experts from the television industry, broadcasting organisations and regulatory institutions in its Study Group 6.

In detail, the new ITU-R Recommendations focus on 720p and 1080i/p HDTV 3DTV programme production and broadcasting with recommendations also agreed on the digital interfaces used in studios for 3DTV programme production, and on the general requirements for 3DTV. The ITU-R Study Group 6 also agreed a Recommendation for the methods to evaluate the quality of 3DTV images, which relates to three aspects, or quality factors: picture quality, depth, and comfort levels.

Source: RapidTV News

AVC-I

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.

Conclusion
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

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 schema.org 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!

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

What is AS02 and Why Do You Need It?

A nice introduction to AS02 by Bruce Devlin.

HTTP ABR Streaming

Cisco Systems Visual Networking Index (VNI) predicts that more than 50 percent of all global Internet traffic will be attributed to video by the end of 2012. It also confirms, in addition to television screens, video delivery to cell phone and computer screens will be increasingly common Globally, Internet video traffic is projected to be 58 percent of all consumer Internet traffic in 2015, up from 40 percent in 2010. At that time, three trillion minutes of video content are projected to cross the Internet each month, up from 664 billion in 2010, when 16 percent of consumer internet video traffic in 2015 will be TV video. There is no doubt that if you are in the business of transmitting video, you will likely be using IP in the near future.

Delivering acceptable video quality over IP to TV viewers and other devices has led to a still-evolving delivery infrastructure. The required network scale has higher packet loss and error rates than smaller managed networks. Adaptive Bit Rate (ABR) delivery protocols like Apple's HLS and Microsoft's Silverlight, among others, help address these issues. These protocols use HTTP over TCP to mitigate data loss by dynamically adapting bit rates to adjust to networks that can provide only unpredictable instantaneous bandwidths.

Using a CDN to distribute the content to a range of servers located close to the viewers is another key feature to successful deployments to avoid the congestion and bottlenecks of centralized servers. Yet, despite more complex protocols to handle a range of transport issues, high-quality performance is not guaranteed. Cost-effective operations and a good viewer experience depend on good monitoring observability and targeted performance metrics for rapid problem identification, location and resolution.

ABR Protocols
ABR video delivery mechanisms over IP that enable this rapidly growing Internet video market are effective, but complex. Not only do they require the usual video compression encoders to achieve practical bit rates, but they also require a host of other devices and infrastructures, including segmenting servers, origin servers, a CDN and a last-mile delivery network.

ABR protocols help deliver a quality video experience to viewers by overcoming common IP data network performance issues such as packet arrival jitter, high loss rates, unpredictable bandwidth and security firewall issues. HTTP delivery solves most firewall issues as it is almost universally unblocked since it is also used for web browsing. HTTP, which uses TCP, assures loss-free payload delivery as well. While predictable instantaneous bandwidth levels are a challenge in unmanaged networks, by using variable encoding rates and these protocols, the viewer's client device can dynamically select the best stream bit rate for the instantaneously available bandwidth.

Apple's HTTP Live Streaming (HLS) is an example of a protocol that successfully navigates the challenges of unmanaged networks to transfer multimedia streams using HTTP. To play a stream, an HLS client first obtains the playlist file, which contains an ordered URI list of media files to be played. It then successively obtains each of the media files in the playlist. Each media file is, typically, a 10-second segment of the desired multimedia stream. A playlist file is simply a plain text file containing the locations of one or more media files that together make up the desired program.

The media file is a segment, or “chunk,” of the overall presentation. For HLS, it is always formatted as an ISO 13818 MPEG-2 TS or an MPEG-2 audio elementary stream. The content server divides the media stream into media files of approximately equal durations at packet and key frame boundaries to support effective decoding of individual media files. The server creates a URI for each media file that allows clients to obtain the file and creates the playlist file that lists the URIs in play order.

On the transmitting end, the adaptive encoder creates segments with fixed duration at different bit rates and an index file that acts as a playlist to indicate the sequence of the segments. On the receiving end, the adaptive protocol buffers video segments in the correct sequence, selecting the best quality possible for the bit rate available at each interval before playing them seamlessly.

Multiple playlist files are used to provide different encodings of the same presentation. A variant playlist file that lists each variant stream allows clients to dynamically switch between encodings. Each variant stream presents the same content, and each variant playlist file has the same target duration. If the playlist file obtained by the client is a variant playlist, the client can choose the media files from the variants as needed based on its own criteria, such as how much network bandwidth is currently available. The client will attempt to load media files in advance of when they will be required for uninterrupted playback to compensate for temporary variations in latency. The client must periodically reload the playlist file to get the newest available media file list, unless it receives a tag marking the end of the available media.

CDN Operation
Using HTTP client-driven streaming protocols like HLS effectively supports adaptive bit rates, handles high network error rates and firewall issues, and supports both on-demand and live streaming. However, with millions of clients establishing individual protocol sessions to receive video, scalability must be considered. Further challenging the system design are sudden spikes in requests from “flash crowds” or “SlashDot effects” that may be caused by current events where a sudden, unexpected demand overwhelms servers, and content becomes temporarily unavailable.

The CDN is a collection of network elements that replicates content to multiple servers to transparently deliver content to users. The elements are designed to maximize the use of bandwidth and network resources to provide scalable accessibility and maintain acceptable QoS. Particular content can be replicated as users request it or can be copied before requests are made by pushing the content to distributed servers closer to where it is anticipated users will be requesting it.

In either case, the viewer receives the content from a local server, relieving congestion on the origin server and minimizing the transmission bandwidth required across wide areas. Caching and/or replica servers located close to the viewer are also known as edge servers or surrogates. To realize the desired efficiencies, client requests must be transparently redirected to the optimal nearby edge server.

Content distribution and management strategies are critical in a CDN for efficient delivery and high-quality performance. The type and frequency of viewer requests and their location must dynamically drive the directory services that transparently steer the viewer to the optimum edge server, as well as the replication service, to assure that the requested content is available at that edge server for a timely response to the viewer. A simplistic approach is to replicate all content from the origin server to all surrogate servers, but this solution is not efficient or reasonable given the increase in the size of available content. Even though the cost of storage is decreasing, available edge server storage space is not assured. Updating this scale of copies is also unmanageable.

Practically, a combination of predicted and measured content popularity and on-demand algorithms are used for replication. Organizing and locating edge server clusters to maintain optimum content availability relies on policies and protocols to load balance the servers. Random, round robin or various weighted server selection policies, along with selections based on number of current connections, number of packets served, and/or server CPU utilization, health and capacity are all utilized and varied based on load persistence considerations.

Quality Assurance
Cost-effective operations rely on good monitoring observability and performance metrics for rapid problem identification and resolution. QoS performance monitoring metrics provide needed information about stream delivery quality, key information about the types of impairments and their causes, as well as warnings of impending impairments for ABR streaming networks. Combined with end-to-end monitoring, QoS monitoring used in production network monitors network delivery quality of the flows and for other applications such as system commissioning and tuning.

In adaptive streaming environments, QoS should be monitored post caching server and at the client. This chart shows how the VeriStream metric characterizes instantaneous network delivery quality on a 1-5 scale:

1 - Severe underrun: Interval between segments and the file transfer time are slower than the drain rate.
2 - Underrun: Segment interval is slower than the drain rate, but file transfer time is faster than the drain rate.
3 - Warning: Interval between segments and the file transfer time are marginal.
4 - Growing buffer: Interval between segments and the file transfer are faster than the drain rate.
5 - Balanced system: Interval between segments is balanced, and the file transfer is faster than the drain rate.

Such metrics are intended to analyze streams susceptible to IP network device and client/server impairments. For adaptive streaming environments, it is also important to monitor QoS at the client end point, which can be used to assess the dynamic performance of network and system delivery. QoS metrics for ABR must continuously analyze the dynamic delivery of stream segments.


Comprehensive monitoring in real time at strategic network locations for rapid problem detection and fault isolation can be combined with control plane and content quality monitoring for optimum system management.

Summary
Leaving the well-managed network domain of provider IP networks requires new adaptive bit-rate protocols that are rapidly proving their effectiveness. A comprehensive, end-to-end monitoring strategy gives content and service providers the streamobservability and fault-isolating capabilities needed for timely and efficient adaptive bit-rate network delivery deployments.

By James Welch, Broadcast Engineering

World's First Ultra High Definition Shoulder-Mount Camera

This is the world's first compact shoulder-mount Ultra High Definition camera. Developed by NHK, it uses a single-chip color imaging sensor to produce 33MP video.

By reducing the size and weight of the camera, the portability had been improved, making it more maneuverable than previous prototypes, so it can be used in a wide variety of shooting situations. This compact head can also be used with commercially available still camera lenses.

As the single-chip sensor uses a Bayer color filter array, where only one color component is acquired per pixel, researchers at NHK have also developed a high quality up-converter, which estimates the other two color components to convert the output into full resolution video.

Next, NHK will develop a camera control unit to perform signal processing specifically for this head. This will improve the picture quality and functionality of the camera.

By Don Kennedy, DigInfo TV

HbbTV on Brink of Global Expansion

HbbTV is now odds on to emerge from the cluster of interactive and hybrid TV standards to become the dominant platform uniting broadcast and connected TV.

Currently sweeping through continental Europe, and under trial in a number of other major countries including China, Japan and the U.S., it looks like the winning hybrid TV platform is emerging, partly through not being too ambitious and sticking clearly within defined boundaries. It leaves plenty of scope for apps vendors, broadcasters and pay TV operators to innovate around the platform and stamp their own distinctive flavor on their products or standards.

The closest to an actual HbbTV deployment outside Europe is in South Korea, where national broadcaster KBS is launching services based on the country’s OHTV (Open Hybrid Television), which is a separate development but almost identical technically and now likely to be aligned completely with HbbTV given its momentum in other countries. In Korea, the service is hybrid digital terrestrial and broadband, as is the case with many early HbbTV deployments in Europe.

HbbTV evolved in 2009 as a joint project between France and Germany, and it is those two countries along with Spain and the Netherlands that have made the early running with HbbTV deployments. In Germany, at least eight broadcasters, including public service broadcaster RTL and pan European media distributor ZDF, are now offering HbbTV apps over terrestrial or satellite networks.

Such apps can combine multiple delivery channels into one coherent service, or provide additional viewing options within a single channel. An example of the first of these use cases is German home shopping channel QVC, which is exploiting HbbTV to unite its various existing distribution channels including TV, Internet and mobile networks, within one coherent service allowing customers to search for products. An example of the second is German private broadcaster Vox, part of the RTL Group, which is using HbbTV for a cooking channel, allowing viewers to access different recipes for demonstration within a show by pressing the “red button.”

In France, public broadcaster France Télévisions has been leading the way and is using HbbTV to expand coverage of the French Open tennis tournament over the next two weeks. It will allow viewers to choose from a number of matches at a given time, again using red button functionality.

Spain, meanwhile, has agreed to adopt HbbTV as its system for connected TV, with pilots completed by broadcaster Mediaset España and Telco Telefonica. These involved Mediaset’s Telecinco importing content from Telefónica’s services, including Movistar Imagenio, Movistar Videoclub and Terra TV.

Similarly, Dutch broadcasters, including SBS, NPO and RTL, have agreed to use HbbTV as their standard for hybrid connectivity, while launches have just occurred or are imminent in Switzerland, Austria, the Czech Republic and Poland.

HbbTV has also won over the Nordic region, which originally was planning to build hybrid broadcast around the alternative Multimedia Home Platform (MHP) developed by the DVB, with the main original difference being that HbbTV is based on HTML while MHP is written in Java language. Germany originally went with MHP, but it failed miserably, partly because there was then little demand for interactive TV in the country.

Now, the Nordic region comprising Denmark, Finland, Iceland, Norway and Sweden, oddly also including Ireland, has replaced DVB-MHP with HbbTV as the common API for hybrid digital receivers within its NorDig digital TV specification. The stated reason is that HbbTV now has much wide market acceptance, with a range of TV applications and new hybrid services, and crucially HbbTV compatible receivers from a number of manufacturers such as Humax of South Korea. Also significant is that HbbTV software stacks are now incorporated in leading hybrid chip sets from Broadcom and Sigma Designs. Most major players in the connected TV arena are now members of the HbbTV Forum.

The success of HbbTV can be put down to three factors: its flexibility; foundation on existing standards that are being implemented anyway as part of OTT and IPTV deployments; and support from industry groups, notably the European Broadcast Union (EBU), whose influence extends outside the continent.

The EBU is hoping that the Olympics will give HbbTV a big lift, and has laid the ground by offering “white-label” HbbTV applications free of charge to its members. These apps are currently being customized and rebranded for deployment just ahead of the games, when they will deliver interactive services to peak audiences during the Olympics.

Equally crucial is the approval of the Open IPTV Forum (OIPF), which has emerged as the major body forging standards for OTT and general online video service delivery over unmanaged infrastructures, as well as IPTV within closed ‘walled garden’ networks.

The key component for OTT that has been adopted by HbbTV is the OIPF’s Open Internet Profile, based on its Declarative Application Environment (DAE), which is a browser for TVs with support for various presentation mechanisms including HTML4, HTML5, SVG, and CE-HTML.

“Its key component is the set of JavaScript objects which permit the manipulation of media for both content on demand as well as live streaming, interactions with local and remote storage, and control of adaptive streaming,” said Nilo Mitra, OIPF president. “This specification is reused by the HbbTV Consortium for providing catch-up services via broadcaster portals, and is now implemented in retail TVs sold by major manufacturers in several EU regions,” Mitra added, arguing that this was the only fully open specification for content delivery over unmanaged networks available today.

The OIPF specification includes a mechanism for adaptive delivery of MPEG-2 transport streams over HTTP, and this has been incorporated into one of the profiles of the newly just published ISO DASH specifications, according to Mitra. DASH is likely to become the standard mechanism for adaptive streaming, taking over from existing proprietary systems such as Microsoft Smooth Streaming, and possibly Apple’s HLS (HTTP Live Streaming).

Support for DASH streaming was an addition to HbbTV. But, at the outset, it had the right foundation by being built on two relevant and mature technology sets, one being web standards already included in web browsers for embedded devices, and the second being the Digital Storage Media Command and Control (DSM CC) specification already part of the MHEG-5 interactive platform adopted in several countries, including the UK and Australia.

Use of existing web standards provided the basis for broadband access, while DSM CC specified a common approach for interactive services uniting two way online delivery with one way broadcast. DSM CC, therefore, delivered the hybrid component, and although it is a complex set of technologies the basic principle is simple. The aim is to facilitate control over transport of audio and video streams within interactive services in both a bi-directional environment such as a cable TV or VOD system, and also a uni-directional service such as satellite or digital terrestrial.

The challenge was how to simulate interactivity in a one-way environment when there was no return path. The simple answer was to adopt a carousel approach — hence the name. As the receiver in a traditional broadcast environment has no return path and so cannot request specific files from a server, DSM CC periodically transmits every file, and the receiver then grabs the ones it wants as they pass by on the carousel. Of course, this is not particularly efficient since if a receiver misses a file it has to wait for it come round again. But, techniques have been developed and embodied in HbbTV to improve the interactive performance for one way broadcast services.

It will become clear during the rest of 2012 how well HbbTV does perform in a variety of hybrid environments including those involving one-way broadcast, with the Olympics providing useful feedback. But, HbbTV has still not convinced all its doubters, even in Europe. Italy is the notable outsider, having gone its own way by deploying MHP for hybrid services.

The UK is the other major odd one out, since its much delayed connected TV platform, YouView, took a different approach. However, the UK is itself a bit of a hybrid, since the Digital Technology Group (DTG) responsible for digital TV and particularly terrestrial standards in the UK developed an extension to MHEG-5 called the MHEG-5 Interaction Channel (MHEG-IC), allowing broadcast interactive services to be delivered via an IP connection. This made it more like HbbTV, and, subsequently, the DTG has fully endorsed HbbTV for Freeview DTT.

By Philip Hunter, Broadcast Engineering

NHK 33 Megapixel 120fps Ultra High Definition Imaging System

NHK, in conjunction with Shizuoka University, has developed an Ultra High Definition imaging system that outputs 33MP video at 120fps.

As Ultra High Definition broadcasts at full resolution are designed for large, wall sized displays, there is a possibility that fast moving subjects may not be clear when shot at 60fps, so the option of 120fps has been standardized for these situations.

To handle the sensor output of approximately 4 billion pixels per second with a data rate as high as 51.2Gbps, a faster analog-to-digital converter has been developed to process the data from the pixels, and then a high-speed output circuit distributes the resulting digital signals into 96 parallel channels.

This 1.5-inch CMOS sensor is smaller and uses less power when compared to conventional Ultra High Definition sensors, and it is also the world's first to support the full specifications of the Ultra High Definition standard.

From now on NHK plan to increase the light sensitivity of this Ultra High Definition sensor.

by Don Kennedy, DigInfo

NHK Hybridcast Making broadcast TV Interactive

Hybridcast is an infrastructure system being developed by NHK, with a view to commercial use in 2013. This system combines broadcasting with the Internet, to enable a variety of TV-centered services.

At this year's NHK Science & Technology Research Laboratories Open Day, NHK exhibited prototype receivers, developed together with manufacturers, as well as the service concept.

Source: DigInfo

DPP Unveils Digital Workflow Guide

The Digital Production Partnership (DPP) has unveiled a major industry report, The Bloodless Revolution: A Guide to Smoother Digital Workflows in Television. The report is the first published guidance on digital workflows to be issued on behalf of ITV, Channel 4 and the BBC. It seeks to help producers and suppliers achieve a smoother transition to fully digital production.

The new guide follows the publication of the DPP’s report on breaking down the barriers to digital production The Reluctant Revolution, September 2011. One of the claims made in the first report was that the pace of change in the industry was held back by a lack of commonly agreed ways of working. It observed that greater guidance is needed if the industry is to complete its move from tape-based to file-based production.

The DPP’s new report now provides such guidance. It sets out to identify the smoothest, most efficient digital workflows for use with currently available technology, while providing sufficient background information to help maintain a view of the wider production landscape. It also identifies opportunities for collaboration, cost saving, and better creative outcomes.

The guide sets out a clear high level workflow as a framework for providing information, guidance and direction to digital production workflows. The overall process has been broken into four steps: planning – which covers the process up to the point of shooting, including the different conventions and practices that need to be adopted right at the outset; rushes management – which looks at the capture and handling of content on location or in studio up to the point of rushes archive and management; post production – which goes from the ingest of material for editing through to completion of the master: and delivery – the production of masters for delivery to broadcasters, clients or the audience.

The report was commissioned by the DPP from industry analysts MediaSmiths International. Its starting point was the views and experiences offered by dozens of attendees from all over the UK at the DPP’s regular industry forums.

From the outset ‘The Bloodless Revolution’ acknowledges that programme makers have no desire to see their world reduced to a series of workflows. Many may feel that by over-describing the process, the magic of television production will be driven out.

But the report goes on to offer a user-friendly map by which to navigate the potentially complex processes of file-based production – and in so doing offers a guide that, while first appearing analytical, is actually liberating.

Source: Digital Production Partnership

ITU Sets Standards for Ultra HD

The London Olympics will provide the first live trials of Ultra High Definition TV (UHDTV) based on standards finally agreed last week by the International Telecommunications Union (ITU) after a decade of research and development in which the EBU was heavily involved.

The ITU has defined the UHDTV standards, 4K and 8K, as multiples of the existing 1080p1920 format defined in the ITU-R Rec. 709 standard. HD 1080p, at present often referred to as full HD, displays at a resolution of 1920 pixels wide by 1080 high in progressive scan, corresponding to a widescreen aspect ratio of 16:9. Various frame rates are supported including 24, 50 and 60.

4K is defined simply by doubling 1080p1920 in each direction to yield pictures with four times the spatial resolution, at 3840 pixels wide by 2160 high, which is 8 mega pixels. 8K then doubles up again to resolution 7680 wide by 4320 high, spatially 16 times 1080p, or 32 mega pixels. But, the ITU has also added support for a higher frame rate option of 120, which experiments have shown may be necessary for accurate portrayal of motion at these very high resolutions on large wall sized displays.

Without the corresponding increase in frame rate, there is a danger that UHDTV will display brilliant images of slow moving action, but then exhibit slight jerkiness for high speed shots in some sporting events for example.

The bandwidth implications of these standards will alarm some operators and broadcasters, for an 8K programme running at the full 120 frames per second would require 320 times the bit rate of current HD transmissions given that these are often not yet even 1080p, but usually either 720p or interlaced 1080i. But, as the EBU pointed out, these new standards are unlikely to start working their way into mainstream transmissions for the best part of a decade.

That will coincide with the introduction of new frameless displays in which picture size can vary, and that blend into the background when not in use. Some vendors of pay-TV software are already developing platforms in anticipation of Ultra HD delivery to such large screens. For example, UK-based conditional access and middleware vendor NDS has a platform called Surfaces that was first demonstrated delivering 4K UHDTV to large displays at IBC 2011 in Amsterdam.

Most broadcasters will first upgrade to full HD at 1080p, which will for now meet all quality expectations, certainly for screens up to 60 inches diameter. For example, in the UK, the Freeview HD platform used by the BBC and ITV has been specified to provide full HD capability.

But although UHDTV may be some years away for TV, the 4K version has already been adopted for digital cinematography and computer graphics, using slightly different resolutions than the new ITU standard. 4K is also supported by YouTube, the only video hosting service to do so, in a different version again, allowing uploading of 4K videos at a resolution of 4096 x 3072 pixels, or 12.6 megapixels.

By Philip Hunter, Broadcast Engineering

Microsoft Announces Support for MPEG-DASH in Microsoft Media Platform

Microsoft Media Platform will support MPEG-DASH, a recently ratified ISO/IEC standard for dynamic adaptive streaming over HTTP. Microsoft plans to support DASH and other open standards as part of an industry-wide initiative to establish reliable video delivery to Internet connected devices and enable true interoperability between adaptive streaming technologies from different vendors.

Much like Smooth Streaming, DASH uses Extensible Markup Language (XML) to describe media presentations in a manifest file which references media streams stored in ISO Base Media File Format. Combined with the standard HTTP protocol and existing Web content delivery networks, the DASH standard enables a better video experience for end users by automatically adapting to varying client and network conditions during playback.

Taking advantage of similarities between Smooth Streaming and DASH, Windows Azure Media Services will add support for DASH Live Profile later this year so that both Smooth Streaming and DASH devices can access the same live and on-demand video presentations using either manifest format. This will enable a smooth transition to DASH for millions of devices and services currently using Smooth Streaming.

In addition to server-side support, Microsoft will also add support for DASH to all its Smooth Streaming client development kits. The first step will be to enable DASH support in the Smooth Streaming Client for Silverlight, followed by support in Smooth Streaming Client SDKs for Windows 8, iOS, Xbox, Windows Phone and Smooth Streaming Client Porting Kit for embedded devices.

Microsoft is also contributing to W3C efforts to standardize adaptive streaming APIs in HTML5 so that DASH Web applications may also be written in HTML5 and ECMAScript (JavaScript) in the future without requiring browser plug-ins such as Silverlight and Flash to enable advanced streaming media scenarios.

Microsoft has contributed to the development of the DECE UltraViolet video format which enables download and adaptive streaming of premium movie and TV content; and to various international broadcast standards and consortia so that a common protected video format based on DECE Common File Format, MPEG Common Encryption, and MPEG-DASH specifications will be supported by all adaptive streaming services and devices to enable reliable interoperability for consumers, just like broadcast TV and DVD.

What Microsoft services will have DASH support?

Windows Azure Media Services will provide encoding, encryption, and streaming support for Application Profiles based on DASH “ISO Base Media Live Profile” this year. Both DASH manifests and Smooth Streaming manifests will be generated to allow the same media to be streamed by DASH clients and Smooth Streaming clients. The primary media format will conform to the PIFF 1.3 specification in addition to Live Profile, will include several features and constraints compatible with the DECE Common File Format, and may optionally include MPEG Common Encryption with PlayReady DRM support. Windows Azure Media Services will also be capable of live transformation to multiple streaming formats, including MPEG-2 Transport Streams for use with DASH M2TS Simple Profile manifests or M3U8 playlists.

What Microsoft client technologies will have DASH support?

Microsoft plans to add MPEG-DASH support to all client development kits that currently support Smooth Streaming. These are: Smooth Streaming Client for Silverlight; Smooth Streaming Client for Windows Phone; Smooth Streaming Client SDK for Windows 8 Metro-style applications; Xbox LIVE Application Development Kit; Smooth Streaming SDK for iOS Devices with PlayReady; and Smooth Streaming Client Porting Kit.

Is Microsoft discontinuing Smooth Streaming?

No. Microsoft will continue to invest in Smooth Streaming as an established technology and brand while ensuring its Smooth Streaming services, clients, tools and workflows are DASH compatible. The Smooth Streaming file format (PIFF 1.3) is already compatible with the DASH specification (ISO Base Media Live Profile) so customers and partners who are investing into creation of Smooth Streaming content today will have a clear path to making that content deliverable to DASH clients in the future.

What is Common Encryption?

Common Encryption is an MPEG standard using AES-128 media encryption that enables a single protected ISO Base Media file or adaptive streaming presentation to be used with any DRM system supported by a device and the publisher. The standard is designated ISO/IEC 23001-7 “Information technology – MPEG systems technologies – Part 7: Common encryption in ISO base media file format files”. Prior to this standard, a different set of files was required for each different DRM type, and interchange of files between authorized devices was generally not possible because of different DRMs.

What is Common File Format?

Common File Format (CFF) is a DECE video specification titled “Common File Format & Media Formats Specification” used for content download. It specifies video files based on fragmented ISO Base Media files (MPEG-4 Part 12), optionally using Common Encryption, containing AVC video, AAC audio, SMPTE Timed Text and Graphics subtitles, metadata, and several optional audio formats. All parameters required for interoperability are sufficiently specified to allow independently implemented encoders, publishers, delivery services, and devices to reliably interchange and play the same files. Different “media profiles” are specified for high definition, standard definition, and “portable” definition devices.

The CFF requirement to use short movie fragments makes these files and compatible decoders forward compatible with DASH adaptive streaming using movie fragments as DASH Media Segments. DECE is currently in the process of specifying “Common Streaming Format” and considering DASH Application Profiles.

What about HTML5 playback?

The current working draft of HTML5 does not include specific support for either adaptive streaming or DRM protection. It is possible to indicate a playlist or manifest file as the source of the <video> tag, but a publisher would have no control over the behavior and presentation that each device or browser would execute in response to that manifest. There are no standard APIs to integrate the presentation decisions made by the platform with a presentation application running in the browser.

However, there is work underway in W3C to add both adaptive streaming and content protection APIs so that a script application will be able to run in any HTML5 browser to perform DRM license acquisition and DASH adaptive streaming under the control of the script application. This will allow the script application to control adaptive heuristics, authorization, load balancing, performance reporting, targeted ad insertion, and interactive presentation and navigation of one or more adaptive presentations. These script APIs will make HTML5/JavaScript DASH applications a viable alternative to Silverlight and Flash across the full range of devices … in the future.

Source: Microsoft Media Platform Team Blog

AMWA Releases MXF Commercial Delivery Specification

The Advanced Media Workflow Association (AMWA) has released a new MXF Commercial Delivery specification, AS-12. The constrained version of MXF has been developed to enable more efficient handling of commercials through the many transactional and media processing operations between conception and air.

As broadcasters look to serve commercials to long tail delivery platforms as well as their primary channels, controlling costs is all-important. Many versions may exist of the same commercial, adding confusion to the traffic operations. Versions may be sourced from different distribution routes, arriving with different wrappers and codecs, as well as different aspect ratios.

MXF Commercial Delivery aims to solve two problems: unique identification, and defining a master spot for the creation of long-tail versions.

MXF Commercial Delivery unambiguously identifies the spot through the Ad-ID unique identifier carried in a “digital slate”. Current practice to identify commercials is by the visual slate preceding the commercial. Although a human operator can read this by playing the commercial, it does not lend itself to use by automated systems.

With MXF Commercial Delivery the advertisement identification metadata is carried as a Descriptive Metadata track and serves as a digital slate. The digital slate can be used to reconcile the video and audio components of the commercial with the traffic instruction thus preventing expensive mistakes. The Ad-ID unique identifier ensures that what the advertiser ordered gets to air.

MXF Commercial Delivery, AS-12, is an addition to AS-03, MXF for Delivery. AS-03 defines MXF files optimized for program delivery, and intended for direct playout via a video server. Used together, the specifications allow the agency to supply broadcasters with a master commercial, along with information like closed captions and AFD that the broadcaster can use to create the lower resolution versions appropriate to their long-tail delivery platforms.

The AS-12 metadata or digital slate can be created early in the production process to uniquely identify the commercial. AS-12 carries fields to identify the advertiser, the agency, brand and product, as well as the title. Through the use of the guaranteed unique Ad-ID, the rekeying of identifiers that typically happens today is avoided. House codes used by agencies or broadcasters are replaced with the Ad-ID, avoiding many of the issue of misidentified commercials that have been commonplace.

The Commercial Delivery specification is sponsored by AMWA principal member Ad-ID, a joint venture of the American Association of Advertising Agencies (4A's) and Association of National Advertisers (ANA), and establishes a baseline for improved Operations, Administration, and measurement of advertising assets across the myriad of current and emerging delivery platforms, which when fully deployed, will result in substantial financial gains and improvements in productivity that will flow back to all participants within the supply chain.

Source: Advanced Media Workflow Association

MPEG Transport Stream

The MPEG-2 standard is defined by ISO/IEC 13818 as "the generic coding of moving pictures and associated audio information." It combines lossy video compression and lossy audio compression to comply with bandwidth requirements. The basic structure of all MPEG compression systems is asymmetric because the encoder is always more sophisticated than the decoder.

MPEG encoders are always algorithmic. The better ones are also adaptive, using a feedback path. MPEG decoders are not adaptive and perform a fixed function. This works well for applications like broadcasting, where the number of expensive complex encoders is few and the number of simple inexpensive decoders is enormous.

The MPEG standard provides little information about how encoder processes and operation. Rather, MPEG-2 specifies how a decoder interprets metadata in a bit stream. The metadata tells the decoder the rate the video was encoded, defines the audio coding, and identifies channels and other vital stream information.

A decoder that successfully deciphers MPEG streams is called compliant. The beauty of MPEG is that it allows different encoder designs to evolve simultaneously. Generic low-cost and proprietary high-performance encoders and encoding schemes all work because they are all designed to communicate with the compliant decoder base.

Stream Structures
An MPEG-2 stream can be either an Elementary Stream (ES), a Packetized Elementary Stream (PES) or a Transport Stream (TS). The ES and PES begin with and are stored as files. Individual ESs are essentially endless because the length of an ES is as long as the program itself.

Starting with analog video and audio content, individual ESs are created by applying MPEG-2 compression algorithms to the source content in the MPEG-2 encoder. This process is typically called ingest. The encoder creates an individual compressed ES for each audio and video stream. An optimally functioning encoder will appear transparent when decoded in a set-top box and displayed on a professional video monitor.

A good ES depends on several factors, beginning with the quality of the original source material, and the care used in monitoring and controlling audio and video variables when material is ingested. The better the baseband signal, the better the quality of the digital file. Also influencing ES quality is the encoded stream bit rate and how well the encoder applies its MPEG-2 compression algorithms within the allowable bit rate.

MPEG-2 has two main compression components: intraframe spatial compression and interframe motion compression. Encoders use a variety of techniques, some proprietary, to maintain the maximum allowed bit rate while at the same time allocating bits to both compression components. This balancing act can sometimes be unsuccessful. It is a tradeoff between allocating bits for detail in a single frame and bits to represent frame to frame motion changes.

Researchers are still investigating what constitutes a good picture. Presently, there is no direct correlation between the data in the ES and subjective picture quality. For now, the best way of checking encoding quality is with the human eye, after decoding.

The Packetized ES
Each ES is broken into variable-length packets. The result is a PES containing a header and payload bytes. The header includes information about the encoding process required by the MPEG decoder to decompress the ES.

Each individual ES results in an individual PES. At this point, audio and video information still resides in separate PESs. The PES is primarily a logical construct and is not actually intended to be used for interchange, transport and interoperability. The PES also serves as a common conversion point between TSs and PSs.

Both the TS and PS are formed by packetizing PES files. During the formation of the TS, additional packets, containing tables needed to demultiplex the TS, are inserted. These tables are collectively called PSI and will be addressed in detail later.

Some packets contain timing information for their associated program, called the program clock reference (PCR). The PCR is inserted into one of the optional header fields of the TS packet. Recovery of the PCR allows the decoder to synchronize its clock to the rate of the original encoder clock.

Null packets, containing a dummy payload, may also be inserted to fill the intervals between information-bearing packets.

TS packets are fixed in length at 188 bytes with a minimum 4-byte header and a maximum 184-byte payload. Key fields in the minimum 4-byte header are the sync byte and the Packet ID (PID). The sync byte's function is indicated by its name. It is a long digital word used for defining the beginning of a TS packet.

The PID
The PID is a unique address identifier. Every video and audio stream as well as each PSI table needs a unique PID. The PID value is provisioned in the MPEG multiplexing equipment. Certain PID values are reserved or specified by organizations such as the Digital Video Broadcasting Group (DVB) and the Advanced Television Systems Committee (ATSC) for electronic program guides.

In order to reconstruct a program from all its video, audio and table components, it is necessary to ensure that the PID assignment is done correctly and that there is consistency between PSI table contents and the associated video and audio streams. This is one of the more critical points in a MPEG-2 stream.

There are four other important fields in the TS header. One is the continuity counter. It is a 4-bit field that repeatedly increments zero through 15 for each PID. It’s used to determine if packets are lost or repeated PCR. Second is the discontinuity indicator. It indicates a time base (PCR) and continuity counter discontinuity, which allows the decoder to handle such discontinuities. Third is the random access indicator. It indicates that the next PES packet in the PID stream contains a video-sequence header or the first byte of an audio frame. Fourth is the splice countdown. It indicates the number packets of the same PID number to the splice point when a new PES packet begins.

PSI
During the formation of the TS, additional packets, containing tables needed to demultiplex the TS, are inserted. These tables are collectively called PSI. PSI is part of the TS. PSI is a set of tables required for demultiplexing and sorting out which PIDs belong to which programs.

To identify which audio and video PIDs contain the content of a particular program, a Program Map Table (PMT) must be decoded. Each program requires its own PMT with a unique PID value.

In order to determine which PID contains the desired program's PMT, the Program Allocation Table (PAT) must be decoded. The PAT is the master PSI table with PID value always equal to zero (PID = 0). If the PAT cannot be found and decoded in the TS, then no programs can be found, decompressed, or viewed.

For a set-top box or ATSC tuner to successfully perform the program recovery and decompression process, the PSI tables must be sent periodically and with a fast enough repetition rate that it doesn’t delay channel-surfing viewers. Thus, checking the PSI tables for correct syntax and repetition rate is a vital part of MPEG testing.

Testing PSI involves verifying the accuracy and consistency of PSI contents. As programs change or multiplexer provisioning is modified, some problems may occur. One problem would be unreferenced PID. Packets with a PID value are present in the TS but are not referenced in any table.

If there are no packets with the PID value referred to in a PSI table present in the TS, the problem could be a missing PID.

Another useful PSI test is a check of program content. Just because there are no unreferenced or missing PIDs indicated does not mean that the viewer is receiving the correct program. There may also be a mismatch of the audio content from one program being delivered with the video content from another program. Because MPEG allows multiple audio channels for multiple languages, an air-check can ensure that viewers are receiving the correct language.

It is possible to use a set-top box and television to do the air check, but a better way would be to use an MPEG test set that incorporates all the PSI table checks plus a built-in decompressor with picture and audio display. This would allow you to correlate PSI contents and actual program content as well as allow a quick visual and aural check of ES.

By Ned Soseman, Broadcast Engineering