A Guide to Closed Captioning for Web, Mobile, and Connected TV

Captioning is coming to Internet video. Legislation goes into effect in the US during 2012 and 2013 that mandates closed captioning on certain categories of online content – see Zencoder's post for details on the legislation. But even apart from this legislation, closed captioning is a good thing for accessibility and usability, and is yet another milestone as Internet video marches towards maturity.

Unfortunately, closed captioning is not a single technology or “feature” of video that can be “turned on”. There are a number of formats, standards, and approaches, ranging from good to bad to ugly. Closed captioning is kind of a mess, just like the rest of digital video, and is especially challenging for multiscreen publishers.

How Closed Captions Work
The first thing to understand is how closed captions are delivered, stored, and read. There are two main approaches today:

• Embedded within a video: CEA-608, CEA-708, DVB-T, DVB-S, WST. These caption formats are written directly in a video file, either as a data track or embedded into the video stream itself. Broadcast television uses this approach, as does iOS.


• Stored as a separate file: DFXP, SAMI, SMPTE-TT, TTML, EBU-TT (XML), WebVTT, SRT (text), SCC, EBU-STL (binary). These formats pass caption information to a player alongside of a video, rather than being embedded in the video itself. This approach is usually used by browser-based video playback (Flash, HTML5).

What about subtitles? Are they the same thing as closed captions? It turns out that there are three main differences:

• Goals: Closed captions are an accessibility feature, making video available to the hard of hearing, and may include cues about who is speaking or about what sounds are happening: e.g. “There is a knock at the door”. Subtitles are an internationalization feature, making video available to people who don’t understand the spoken language. In other words, you would use captions to watch a video on mute, and you would use subtitles to watch a video in a language that you don’t understand. (Note that this terminological distinction holds in North America, but much of the world does not distinguish between closed captions and subtitles.)


• Storage: Historically, captions have been embedded within video, and subtitles have been stored externally. This makes sense conceptually, because captions should always be provided along with a video; 100% accessibility for hard-of-hearing is mandated by legislation. Whereas subtitles are only sometimes needed; a German-language video broadcast in Germany doesn’t need to include German subtitles, but that same video broadcast in France would.


• Playback: Since captions are passed along with the video and interpreted/displayed by a TV or other consumer device, viewers can turn them on and off themselves at any time using the TV itself, but rarely have options for selecting a language. In these situations when subtitles are added for translation purposes, they are generally hard subtitles and thus cannot be disabled. However, when viewing DVD/Blu-Ray/VOD video, the playback device controls whether subtitles are displayed, and in which language.

Formats and Standards
There are dozens of formats and standards for closed captioning and subtitles. Here is a rundown of the most important ones for Internet video:

• CEA-608 (also called Line 21) captions are the NTSC standard, used by analog television in the United States and Canada. Line 21 captions are encoded directly into a hidden area of the video stream by broadcast playout devices. If you’ve ever seen white bars and dots at the top of a program, that’s Line 21 captioning (more information.)


• An SCC file contains captions in Scenarist Closed Caption format. The file contains SMTPE timecodes with the corresponding encoded caption data as a representation of CEA-608 data.


• CEA-708 is the standard for closed captioning for ATSC digital television (DTV) streams in the United States and Canada. There is currently no standard file format for storing CEA-708 captions apart from a video stream.


• TTML stands for Timed Text Markup Language. TTML describes the synchronization of text and other media such as audio or video. See the W3C TTML Recommendation for more.
  
  Example:

  <tt xml:lang="" xmlns="http://www.w3.org/ns/ttml">
    <head>
      <styling xmlns:tts="http://www.w3.org/ns/ttml#styling">
        <style xml:id="s1" tts:color="white" />
      </styling>
    </head>
    <body>
      <div>
        <p xml:id="subtitle1" begin="0.76s" end="3.45s">
          Trololololo
        </p>
        <p xml:id="subtitle2" begin="5.0s" end="10.0s">
          lalala
        </p>
        <p xml:id="subtitle3" begin="10.0s" end="16.0s">
          Oh-hahaha-ho
        </p>
      </div>
    </body>
  </tt>



• DFXP is a profile of TTML defined by W3C. DFXP files contain TTML that defines when and how to display caption data. DFXP stands for Distribution Format Exchange Profile. DFXP and TTML are often used synonymously.


• SMPTE-TT (Society of Motion Picture and Television Engineers – Timed Text) is an extension of the DFXP profile that adds support for three extensions found in other captioning formats and informational items but not found in DFXP: #data, #image, and #information. See the SMPTE-TT standard for more.
  
  SMPTE-TT is also the FCC Safe Harbor format – if a video content producer provides captions in this format to a distributor, they have satisfied their obligation to provide captions in an accessible format. However, video content producers and distributors are free to agree upon a different format.


• SAMI (Synchronized Accessible Media Interchange) is based on HTML and was developed by Microsoft for products such as Microsoft Encarta Encyclopedia and Windows Media Player. SAMI is supported by a number of desktop video players.


• EBU-STL is a binary format used by the EBU standard, stored in separate .STL files. See the EBU-STL specification for more.


• EBU-TT is a newer format supported by the EBU, based on TTML. EBU-TT is a strict subset of TTML, which means that EBU-TT documents are valid TTML documents, but some TTML documents are not valid EBU-TT documents because they include features not supported by EBU-TT. See the EBU-TT specification for more.


• SRT is a format created by SubRip, a Windows-based open source tool for extracting captions or subtitles from a video. SRT is widely supported by desktop video players.


• WebVTT is a text format that is similar to SRT. The Web Hypertext Application Technology Working Group (WHATWG) has proposed WebVTT as the standard for HTML5 video closed captioning.
  
  Example:
  
  

  WEBVTT

  00:00.76 --> 00:03.45
<v Eduard Khil>Trololololo

  00:5.000 --> 00:10.000
lalala


  00:10.000 --> 00:16.000
Oh-hahaha-ho

  
  
• Hard subtitles (hardsubs) are, by definition, not closed captioning. Hard subtitles are overlaid text that is encoded into the video itself, so that they cannot be turned on or off, unlike closed captions or soft subtitles. Whenever possible, soft subtitles or closed captions are generally be preferred, but hard subtitles can be useful when targeting a device or player that does not support closed captioning.

Captioning for Every Device
What formats get used by what devices and players?:

• Flash video players can be written to parse external caption files. For example, JW Player supports captions in SRT and DFXP format.


• HTML5 captions are not yet widely supported by browsers, but that will change over time. There are two competing standards: TTML, proposed by W3C, and WebVTT, proposed by WHATWG. At the moment, Chrome has limited support for WebVTT; Safari, Firefox, and Opera are all working on WebVTT support; and Internet Explorer 10 supports both WebVTT and TTML.
  
  Example:
  

  <video width="1280" height="720" controls>
    <source src="video.mp4" type="video/mp4" />
    <source src="video.webm" type="video/webm" />
    <track src="captions.vtt" kind="captions" srclang="en" label="English" />
  </video>

  
  Until browsers support a format natively, an HTML5 player framework like Video.js can support captions through Javascript, by parsing an external file. (Video.js currently supports WebVTT captions.)


• iOS takes a different approach, and uses CEA-608 captions using a modified version of CEA-708/ATSC legacy encoding. This means that, unlike Flash and HTML5, captions must be added at the time of transcoding. Zencoder can add captions to HTTP Live Streaming videos for iOS.


• Android video player support is still fragmented and problematic. Caption support will obviously depend on the OS version and the player used. Flash playback on Android should support TTML, though very little information is available.


• Some other mobile devices have no support for closed captions at all, and hard subtitles may be the only option.


• Roku supports captions through external SRT files.


• Some other connected TV platforms do not support closed captioning yet. But they will soon enough. Every TV, console, cable box, and Blu-Ray player on the market today wants to stream Internet content, and over the next year and a half, closed captioning will become a requirement. So Sony, Samsung, Vizio, Google TV, et al will eventually make caption support a part of their application development frameworks. Unfortunately, it isn’t yet clear what formats will be used. Most likely, different platforms will continue to support a variety of incompatible formats for many years to come.

Closed Captioning for Internet Video: 2012 Edition
The landscape for closed captioning will change and mature over time, but as of 2012, here are the most common requirements for supporting closed captioning on common devices:

• A web player (Flash, HTML5, or both) with player-side controls for enabling and disabling closed captioning.


• An external file with caption data, probably using a format like WebVTT, TTML, or SRT. More than one file may be required – e.g. SRT for Roku and WebVTT for HTML5.


• A transcoder that supports embedded closed captions for HTTP Live Streaming for iPad/iPhone delivery, like Zencoder. Zencoder can accept caption information in a variety of formats, including TTML, so publishers could use a single TTML file for both web playback and as input to Zencoder for iOS video.

Beyond there, things get difficult. Other input formats may be required for other devices, and hard subtitles are probably necessary for 100% compatibility across legacy devices.

Source: Zencoder

Internet TV Systems and Coding

Today's TV viewers want more content from an increasing number of sources, and that means that Internet delivery is a growing phenomenon. With hybrid technologies emerging, it is reasonable to expect that television broadcast will increasingly use the Internet to expand throughput beyond that afforded by a single RF channel. But there are limitations to the Internet that must be understood in order to capitalize on this commodity, and some of those constraints are being overcome by new technologies.

Streaming Can Now Provide a High Quality of Service
In general, Internet TV is a means to provide streamed video content to a PC, STB or Internet-connected TV, by means of an Internet connection. Internet Protocol Television, or IPTV, refers to a special case where a full-time TV subscriber connection is established by means of a dedicated line (and channel) to the telephone system central office. It is envisioned, however, that many Internet TV viewers will get their content though their Internet connection, and as such, receive OTT video service that shares bandwidth with other Internet traffic.

This sharing of bandwidth creates a QoS challenge for Internet TV service: While a terrestrial channel has a fixed bandwidth (i.e., 19.2Mb/s in the U.S.), an Internet TV service must share the bandwidth, both locally (e.g., within a viewer's household) as well as regionally (e.g., with other subscribers). This means the bandwidth available to a receiver can vary continuously over a wide range, and different subscribers may have different levels of guaranteed service, as well. Lowering the video bit rate to the least common denominator would result in poor video quality to everyone; to deal with this, several technologies are available.

Progressive Download vs. Streaming
The simplest way to deliver video over the Internet is to use progressive download, sometimes called “HTTP streaming.” This is simply a bulk download of a video file to the viewer's terminal (i.e., Internet-connected TV, STB, PC, etc.). A temporary copy of the file is stored on the user's device, typically on a hard drive, and playback can start after a sufficient amount of the file has been downloaded. This means that content will always incur a considerable delay before it is available to be viewed, which makes a live service rather difficult to implement. However, because the files are downloaded using TCP, there can be a nearly 100 percent assurance that every single bit was transferred correctly.

True streaming, on the other hand, opens up a handshaking connection between the server and client using a set of Internet protocols to deliver streams, such as Real Time Streaming Protocol (RTSP), Real Time Messaging Protocol (RTMP) and Microsoft Media Services (MMS). A streaming connection delivers a video stream with minimal buffering, allowing a nearly real-time presentation of the source content. In this respect, streaming has an advantage over progressive download, as continuous delivery is the goal, but the associated downside is that corrupted or missing packets are not detected. The consequence is that audio and video can have ongoing glitches when network congestion is experienced.

Adaptive Bit Rate Streaming
To solve the QoS issue, Adaptive Bit Rate (ABR) streaming has been developed. ABR allows each device to determine the quality of its connection and then use that metric to select the best-coded stream from a number of different quality streams. At the server end, a series of encoders encode a set of multiple streams at different bit rates, and these streams are then sliced up into segments or “chunks.” An ABR client in the viewer terminal detects the incoming stream bandwidth on the fly and uses this, along with a model based on the device's CPU capability, to select a segment among the various streams.

A special manifest file precedes the first segment, providing the client with a list of URLs from which each segment can be accessed. As each segment is received, the client progresses to the next segment in that stream, or it can jump to a parallel segment in one of the other streams if the channel bandwidth changes because of congestion, etc. In principle, a handful of streams will provide enough granularity so that the viewer does not detect a change in picture quality.

Note that ABR provides high transmission bandwidth efficiency when a unicast transmission (i.e., one-to-one) is used, but it can also work well with multicast and broadcast scenarios depending on how well the Internet infrastructure distributes bandwidth to users. ABR has the potential to deliver an audio/visual experience that we have come to expect from linear transmission: low delay, fast start time and a consistent experience across viewers.

Several manufacturers have developed different solutions for ABR streaming. Adobe HTTP Dynamic Streaming (HDS) uses a format called F4F to deliver Flash videos over RTMP and HTTP. Apple HTTP adaptive Live Streaming (HLS) was developed for the iPhone and iPad, and is implemented using HTTP, H.264 and MPEG-2 Transport Streams, with a manifest file called M3U8. Microsoft Internet Information Services (IIS) Smooth Streaming is used within Silverlight on the Windows 7 phone and incorporates fragmented MP4 (fMP4) encapsulation, again with H.264 for video compression.

With these different enterprise systems, an interoperability problem exists because of proprietary protocols and manifest structures. Multiple ABR systems mean that different devices must either pick and choose which systems to support, leading to service-constrained devices, or must include all at increased cost. This situation has motivated companies and experts around the world to propose a single, standard ABR system.

DASH-ing to the Rescue: a Universal ABR System
MPEG-DASH (Dynamic Adaptive Streaming over HTTP) is a newly standardized method for defining Stream Segments and Manifest Files for the purpose of ABR streaming. The specification (ISO-IEC 23009-1) defines a Media Presentation Description (MPD) that formalizes the stream manifest, which includes Segment timing, URLs and media characteristics such as video resolution and bit rates. While compatible Segments can contain any media data — with arbitrary compression — two types of containers are exemplified in the standard: MPEG-4 file format and MPEG-2 Transport Stream.

MPEG-DASH defines a standard set of Media Presentation Description and Segment Formats
that enable adaptive bit rate IP video streaming.

In going to a standard system, MPEG-DASH is quickly deployable with the existing Internet infrastructure, using widely deployed standard HTTP servers/caches for scalable delivery. Generic encoders can be reused, with additional descriptive metadata for better client functionality, and legacy manifest files can be converted easily to MPD format, as well as sent in parallel for backward compatibility with low overhead. In addition, existing content and production equipment supporting legacy ABR streaming systems can be used for MPEG-DASH by means of a set of standard Profiles. Apple HLS content can be used with the DASH M2TS Main profile, and Microsoft IIS Smooth Streaming Content is suitable for DASH ISO-BMFF (Base Media File Format) Live profile.

Vendors are now proposing integrated workflow and delivery systems supporting ABR with multiple source formats, protocols and on multiple devices. While encoding latency can be an issue for live streams, MPEG-DASH includes a profile optimized for live encoding that can achieve a latency of a few seconds by encoding and immediate delivery of short Segments.

In addition to delivery of any multimedia content, MPEG-DASH supports a broad range of use cases, including live, VOD, time shifting (nPVR), ad insertion and dynamic update of program. MPEG-DASH also solves the problem of content repurposing to multiple devices with widely ranging capabilities. In principle, an MPEG-DASH-controlled stream can be targeted simultaneously to both large and small screens, as well as fixed and mobile.

Internet Quickly Becoming Viable for Long-Form Content
The once-exclusive realm of RF transmission as providing the highest quality content consumption experience is being challenged by streaming services. But new technologies and business models are providing broadcasters with the tools to compete with new service entities, and that's where content distribution is headed.

By Aldo Cugnini, Broadcast Engineering

First Live MPEG-DASH Large Scale Demonstration

During the 2012 London Olympics, VRT has been offering its audience the chance to experience the Olympic Games broadcast on their personal devices via MPEG-DASH. The public trial allowed for a maximum of 1000 concurrent viewers to watch their favourite sport events on a laptop, smartphone or tablet.

The commercial deployment of the MPEG-DASH (Dynamic Adaptive Streaming over HTTP) standard is one step closer with the first live public trial, presented by Belgian public broadcaster VRT. This trial has been supported by a number of DASH Promoters Group members: encoding has been provided by Elemental, Harmonic and Media Excel; streaming origins was courtesy of Wowza and CodeShop, who also provided encryption; web clients for PC and Android have been supplied by Adobe; and BuyDRM provided applications for iOS and Android, which incorporate its DRM solution.

This proof of concept was initiated by the European Broadcasting Union, which strongly supports the development of MPEG-DASH as it is a key enabler allowing broadcasters to use a single file and streaming format to deliver content to multiple devices on multiple platforms.

Supported Devices
VRT offered users the following choices for viewing the London Games:

• PCs and MAC running Adobe Flash.


• Web browser for Android provided by Adobe.


• iPhone / iPads from iOS version 4.3, with a special app from the iTunes store. The app is currently pending Apple approval.


• Android smartphones from version 4.0, via Sporza Olympic Games available from the Google Play store.

Used MPEG-DASH Profile
The demonstration featured a live video stream encoded using the MPEG-DASH ISO Base Media File Format Live Profile, delivered through Belgacom’s Content Delivery Network to a range of device categories including tablets, smartphones and PCs running iOS, Android and Windows operating systems. This represents the first large-scale multivendor deployment of MPEG-DASH.

The demonstration was based on an early version of the DASH-264 interoperability guidelines, specifically developed by the DASH Promoters Group for interoperable deployment of the MPEG-DASH standard. DASH-264 provides a general interoperability framework aligned with the HbbTV 1.5 specification and other consortia recommendations. HbbTV 1.5 will be widely used by European broadcasters for interactive services on connected televisions.

DASH details:

• File Format: ISO BM FF
• Profile: Live
• Template: Time based
• Codecs: H.264 Baseline (ABR) / Audio AAC-LC (SBR)

Encoding settings:

The video consists of 6 different streams that can be chosen by the player to adapt the video playout automatically to the available bandwidth. The highest quality is 1500 kbs for the video quality, and there is also an audio-only stream available when there is inadequate Internet speed for video.

The settings of the various adaptive switchable streams in this proof of concept have not been defined for optimal audiovisual quality. Simplicity was the key driver in selecting the Baseline profile for H.264 encoding and 64 kbs audio bitrate limitation. This will ensure that switching between the different streams will run smoothly.



Logic Flow
The logical flow of online distribution based on MPEG-DASH is very similar to what is currently deployed in adaptive streaming systems. One needs only an encoded/packaged stream and an HTTP server to get the job done and play out video to a player that supports MPEG-DASH natively.

The simple part of the workflow is demonstrated by the chain starting with the Elemental Live encoder, which captures the audiovisual content from the SDI feed at the VRT premises. The Apache server located at the CDN of Belgacom picks up the data packages via HTTP GET from the encoder and makes it available by a URL and an MPD file describing how the packages should be interpreted by the player. The Adobe player reads out the MPD, buffers the packages and plays out the video on a device of the end user.

It gets more complicated when one involves dedicated applications that play out video to devices that do not yet support MPEG DASH natively. Additionally, to secure premium content, content protection using DRM technology needs to be implemented in the server and the client. In this trial, a group of equipment suppliers are working together to make this happen.

The Harmonic ProMedia Live encoder encodes the IP feeds. The Wowza server, also located at the VRT premises, acts as an origin server, making the packages available for the Wowza cache server in the CDN. This content is then played out by the BuyDRM Android and iOS players.

In order to also showcase the Common Encryption support for MPEG-DASH with Microsoft’s PlayReady DRM, another distribution chain is set up in which the Media Excel HERO encoder works with CodeShops’s Unified Streaming server acting as an origin to produce live encrypted content. For proof of concept purposes, the BuyDRM Android and iOS applications in this distribution chain switch seamlessly between protected and unprotected content.


Click to enlarge
Source: DASH Promoters Group

New EBU Subtitling Specification Published

The EBU has published EBU-TT part 1, with TT standing for Timed Text. It's a follow-up to the widely used EBU STL specification, which was originally published in 1991. The new format is XML-based, which makes it “human readable” and more suited to modern integrated file-based production methods.

EBU-TT is a simplified version of the W3C Timed Text specification, which means it fits well into the broad family that includes W3C TTML and SMPTE TT, which is more focused on the US environment and on distribution. EBU-TT was developed by the EBU's XML Subtitles group, chaired by Andreas Tai of IRT.

Part 1 (Tech 3350) has been published, defining a structure for the interchange and archiving of subtitles; part 2, now being drafted, will provide mapping guidance for users who want to migrate from EBU STL to EBU-TT. Work has also started towards a specification for live subtitling, with a workshop scheduled for 9 August.

Source: EBU

What is Timed Text?

A nice video introduction to Timed Text by Bruce Devlin.

HD Forum Releases TNT 2.0 Specifications and Conformance Tests

HD Forum is aimed at helping and promoting the development of innovative technologies for the French Digital TV environment. Among various topics, HD Forum has worked during the last 2 years on the TNT2.0 project.

The goal was to coordinate the launch of HbbTV interactive services in France. This effort is done in partnership with the HbbTV consortium and led to an upgrade version of HbbTV standard, version 1.5 and a first recommendation for DRM's.

In this respect:

• The HD Forum board is making official the TNT 2.0 specifications to be applied on the French market;


• All together, manufacturers, broadcasters and distributors representatives committed around the technical choices made so far, expecting that products and services will ramp up from Q4’2012 to April 2013 and beyond. Of course, products and service launch plans details remain the respective choices of broadcasters, manufacturers and distributors;


• In order to support this goal, the “TNT 2 0 - Terminal Specification - V1.1 Final” including last improvement has been made available on the HD FORUM web site for a wider distribution to all interested parties, including non HD FORUM members;


• The HD FORUM is also pleased to announce the full release of the TNT 2.0 test suite, developed in cooperation with companies Farncombe and Digital TV labs in the UK. This test suite has already been licensed to multiple manufacturers, and the HD FORUM restates the requirement for consumer electronic manufacturers to self-validate compliance of their products, by passing the TNT 2.0 test suite. The test suite is licensed under a fair and non-discriminatory terms and conditions approved by the HD FORUM;


• In parallel, work continues on the interoperability of services;


• In due course, HD FORUM will contribute to prepare the launch of products and services complying with the TNT 2.0 specifications.

Source: HD FORUM

What is AS12 and Why Do You Need It?

A nice video introduction to AS12 by Bruce Devlin.

DVB Steering Board Approves Phase 2a of 3DTV Specification

DVB is pleased to announce that at the 71st Meeting of the Steering Board, Phase 2a of the DVB-3DTV specification was approved. The specification will be submitted immediately to the European Telecommunications Standards Institute (ETSI) for formal standardisation. An amended DVB-3DTV BlueBook is to be published to reflect the addition to the specification.

The Phase 2a system, also known as “Service Compatible Mode” is designed to meet the needs of those who need to provide normal HDTV receivers with a 2D version of the 3D programme from the same broadcast channel, and at the same time improve the quality of the 3DTV images. Phase 2a provides a 2D version plus an MPEG MVC top-up signal. Although they are tailored to their different environments, both 3D Blu-ray and Phase 2a use MVC, which will enable receivers to include both capabilities.

The 3DTV Phase 1 specification was published in 2011 for “Frame Compatible” delivery, where the essential requirement was that existing HDTV set-top boxes would allow viewers to watch 3D (if they had a 3D display). This is the most used 3DTV broadcast form in the world today.

Source: DVB

MXF for Program Contribution - AS-11

Ian Wimsett, Senior Technologist at Red Bee Media, describes the Advanced Media Workflow Association (AMWA) specification MXF for Contribution, AS-11. AS-11 is a vendor-neutral subset of the MXF file format to use for delivery of finished programming from program producers and distributors to broadcast stations. AS-11 Files are intended to be complete and ready for playout. AS-11 supports SD video encoded as D-10, 50Mbit/s, and HD as AVC-Intra Class 100. Audio can be PCM, AC-3 or Dolby E.

What is AS11 and Why Do You Need It?

A nice video introduction to AS11 by Bruce Devlin.

What is AS10 and Why Do You Need It?

A nice video introduction to AS10 by Bruce Devlin.

IT Acronyms Explained

As broadcast facilities and post-production houses implement new workflow and media management systems, they deal with an array of new IT-based technologies and are inundated with acronyms associated with those technologies, as well as the best practices concerning their use. Adoption of IT-based technologies continues apace with continued convergence across the media industry.

Despite this rapid shift of operations into the IT realm, however, the industry as a whole has not been as fast in providing engineering staff with an education on the meaning of terms such as XML, WSDL, SOAP, SOA and REST, the technologies underpinning them, and the role they play in present and future media-focused operations. This article will review the most relevant acronyms, their fundamental principles and their typical applications.


XML and XML Schema
Complex control systems depend on a reliable interchange of information in order to make the myriad business decisions that guide material through workflow. This is made simpler if individual systems can swap information in the form of structured data — that is, documents that contain both content and an indication of the content's role in the document.

The concept of structured data is not new; humans have been dealing with information formatted this way for centuries. Examples include published (human-readable) books and magazines, as well as web pages displayed by a browser. In both cases, these systems indicate to the consumer the relevance and importance of any particular item on the page through the use of typographical hints — such as underlining text that hyperlinks to other documents. HTML achieves this by including “tags” in the document, and the browser uses those tags to determine how to emphasize the relative value of the associated data.

As a markup language, HTML represents a fairly limited set of standardized tags intended for the presentation of web content, so its utility beyond that scope likewise is limited.

XML, however, offers flexibility that makes it more suitable for commercial use. This is true because, unlike HTML, XML allows users to define their own tags. Rather than defining the tags themselves (or the semantics of the tags), XML provides a facility for defining tags and using them within a document. As with HTML, data is then bracketed within opening and closing tags, which the receiving device can read and act on as appropriate.

Here is an example of the use of a tag “author” to identify a book's author in a library document:
<author>William Shakespeare</author>

Because XML tags are user-definable, an XML Schema is used to define which tags are valid in a particular document. Such definitions describe, for example, elements that can appear in a document (along with their attributes), whether an element is empty or can include text, and the data types for elements and attributes.

Thus, a document can be compared to an XML Schema — acting much like a blueprint, style guide or template — to ensure the document is valid and contains all relevant information. Again, this idea is not a new concept solely used by XML. Most databases have some sort of schema. Also, textbooks have used schemas for years, generally referring to them as “style guides.”

Here is an example of an XML schema for a memo:

SOAP and SOA
Simple Object Access Protocol (SOAP) is a lightweight protocol for the exchange of information. It describes three main elements: an envelope, the encoding rules, and a convention for the representation of remote procedure calls and responses. SOAP is no longer used; however, the technology remains very much in use.

Though it isn't used, the SOAP acronym is sometimes confused with Service-Oriented Architecture (SOA). Though SOAP standards may be part of an SOA application, the acronyms are not related.

SOA is a design philosophy that separates the core functions of a business into independent modules. These modules are referred to as services — essentially software functions — that are called by one or more other services in the overall workflow. (Media transcoding is an example of a service that could be invoked as part of an overall workflow management system.)

Operating on the principle of loosely coupled systems, SOA abstracts the functions of a service from the low-level substructures of that service, leaving the calling service to use much higher-level language to drive the process. In doing so, SOA can make it easier to choreograph multiple business activities and processes among multiple complex software systems, all working under the control of a central process to achieve the required goal.

Consider the operation of a typical media enterprise: Material comes into a facility on tape, via satellite or as a file transfer, and content from each of these sources must be processed before it can be used. Tapes must be ingested, satellite feeds must be fed through some sort of IRD, and files must be received and error-corrected. Some form of transcoding may then be applied in order to provide the material in the house format. A QC stage may then be applied to ensure technical compliance. In the software world, each of these would be software modules in a SOA-based system.

Without SOA, setting up such systems is a time-consuming process that likely will demand customization so that one vendor's automation/asset management system can talk to another vendor's software module or hardware processor. Any operational or technical changes may require replacement of a module or augmentation with another vendor's module.

For example, in a traditional workflow, the automation system must have deep knowledge of the proprietary API calls required to tell a transcoder to transcode a particular piece of material to another format. Every time a new format is added to the transcoder by its manufacturer, that interface must be modified (or in the worst case, completely rewritten). The custom integration software capable of addressing systems from different vendors thus presents a high-potential investment in time and money.

In a more agile SOA-based architecture, the automation system would simply send an XML message that says, “Transcode file X to format Y, and store the result as Z.” This message remains consistent, even if a new transcoder or format is added. Regardless of the vendor, equally equipped systems will perform the same basic transcode when given the same command. Knowing this, engineers can take a more flexible approach to workflow design. This model depends on the fact that each service describes itself and its capabilities to the rest of the system. Web Services Descriptive Language (WSDL) facilitates this exchange of information.

WSDL is an XML-based language used for describing features and capabilities of a particular service. Provided to the central controlling system, this information ensures all other services and applications are aware of a particular service's capabilities.

Four critical pieces are supplied:

• Interface information describing all publicly available functions;
• Data type information for all message requests and message responses;
• Binding information about the transport protocol to be used in calling the service;
• Address information for locating the specified service.

When several similar services exist in one environment, information delivered via WSDL allows an application to decide which of those is most appropriate for the current task and to engage that service as required.


REST
Representational State Transfer (REST), an architecture for distributed systems such as the World Wide Web, is targeted at HTML rather than XML. It addresses the scalability of component interaction, generality of interfaces and deployment of components to reduce latency and enforce security of transactions. Unlike SOA, which often is considered peer-to-peer architecture, REST is oriented toward client/server interaction where clients initiate requests to servers, and servers process requests and return appropriate responses.

In a RESTful transaction, requests and responses are built around the transfer of representations of resources, which themselves are specific information sources. A representation of a resource is typically a document that captures a resource's current or intended state. Each resource is referenced with a global identifier. To manipulate these resources, components of the network — typically user agents and origin servers — communicate via a standardized interface like HTTP and exchange representations.

In the case of web page information, the raw data on which the page is built is the resource, but the representation of that data could be different for different users. What is representation of a resource? Consider a human using a browser to view a web page in order to retrieve information, and a computer doing the same as part of some larger activity. Both navigate to the same page, but the computer has no interest in the page's layout and styling; it just wants the data. The human does care about layout and styling (which, after all, exists to make the page easier for humans to digest). The two clients (human and computer) want different representations of the resource, both derived from the same raw data source.

While SOA is object-oriented, with the object the service with which other services interact, REST is point-to-point and relies on “GET” commands to a specific URL. It enables code delivery in “applets” as needed, and this capability can reduce basic complexity of any client application. Specialized code (like JavaScript) can be delivered along with data and used to customize how data is presented or obtained.

By Paul Turner, Broadcast Engineering

JPEG 2000, from Master to Archive

Today's broadcasters are looking for the highest image quality, flexible delivery formats, interoperability and standardized profiles for interactive video transport and workflows. They also have a vested interest in a common high-end format to archive, preserve and monetize the avalanche of video footage generated globally.

This is the story behind the rapid adoption of JPEG 2000 compression in the contribution chain. Standardized broadcast profiles were adopted in 2010 to match current industry needs (JPEG 2000 Part 1 Amendment 3 — Profiles for Broadcast Application — ISO/IEC 15444-1:2004/Amd3), ensuring this wavelet-based codec's benchmark position in contribution.

In parallel, these broadcast profiles have also filled the industrywide need for compression standards to archive and create mezzanine formats, allowing transcoding to a variety of media distribution channels. The ongoing standardization process of the Interoperable Master Format (IMF) by SMPTE based on JPEG 2000 profiles brings the adoption full-circle.

The U.S. Library of Congress, the French Institut National de l'Audiovisuel (INA) and several Hollywood studios have selected the codec for the long-term preservation of a century of audio-visual contents.

JPEG 2000 is different from other video codecs. MPEG and other DCT-based codecs have been designed to optimize the compression efficiency to deliver video to viewers via a pipe with limited bandwidth. JPEG 2000, with its wavelet transform algorithm, brings features not only for image compression efficiency, but to give also the user better control and flexibility throughout the image processing chain. The codec provides unique features that are not available in any other compression method.


JPEG 2000 under the Spotlight
JPEG 2000 is based on the discrete wavelet transform (DWT) and uses scalar quantization, context modeling, arithmetic coding and post-compression rate allocation. JPEG 2000 provides random access (i.e. involving a minimal decoding) to the block level in each sub-band, thus making it possible to decode a region, a low-resolution or a low-quality image version of the image without having to decode it as a whole.

JPEG 2000 is a true improvement in functionality, providing lossy and lossless compression, progressive and parseable code streams, error resilience, region of interest (ROI), random access and other features in one integrated algorithm.

Many resolutions and different picture quality files can be derived from a single JPEG 2000 master.

In video applications, JPEG 2000 is used as an intraframe codec, so it closely matches the production workflow in which each frame of a video is treated as a single unit. In Hollywood, its ability to compress frame by frame has made this technology popular for digital intermediate coding. If the purpose of compression is the distribution of essence and no further editing is expected, long-GOP MPEG is typically preferred.


Broadcast Processes
JPEG 2000 brings valuable features to the broadcast process, including ingest, transcoding, captioning, quality control or audio track management. Its inherent properties fully qualify a codec for creating high-quality intermediate masters.

Post-production workflows consist of several encoding/decoding cycles. JPEG 2000 preserves the highest quality throughout this process, and no blocking artifacts are created. Moreover, the technology supports all common bit depths whether 8, 10, 12 bits or higher.

JPEG 2000 enables images to be compressed in lossy and visually or mathematically lossless modes for various applications. Additionally, its scalability allows a “create once, use many times” approach to service a wide range of user platforms.


Support for lossless or lossy compression gives the broadcaster more options.

The technology also enables improved editing: Even at the highest bit rates, its intrinsic flexibility makes it user-friendly on laptop and workstation editing systems, with a limited number of full bit rate real-time video tracks. Improving computing hardware is certain to increase the number of real-time layers.

Since JPEG 2000 is an intraframe codec, this prevents error propagation over multiple frames and allows the video signal to be cut at any point for editing or other purposes.

Easy transcoding appeals to high-end applications where workflows vastly benefit from transcoding to an intermediate version. JPEG 2000 ensures a clean and quick operation when bit rate is at a premium. Professional viewers have labeled correctly transcoded 1080p JPEG 2000 files compressed at 100Mb/s as “visually identical” to the original 2K footage. Furthermore, the wavelet-based JPEG 2000 compression does not interfere with the final — usually DCT-based — broadcast formats.

Last but not least, several standards specify in detail how the JPEG 2000 video stream should be encapsulated in a number of widely adopted containers such as MXF or MPEG-2 TS.


Professional Wireless Video Transmission
Wireless transmission is often challenged to improve its robustness in broadcast. Uncompressed HD wireless transmission is often seen as complex, for even if a 1080p60 transmission (3Gb/s) were possible wirelessly, it would be quite difficult to add the necessary FEC and encryption to the data stream. Of all the compression algorithms available in the market, JPEG2000 is seen as one of the top contenders for the following reasons.

JPEG 2000 is inherently more error resilient than MPEG codecs. The codestream can be configured so the most important data (the lowest frequency data contains the most visually significant information) is located in the front, while successively higher frequency, less important data can be placed in the back. Using appropriate FEC techniques, the lower frequency data can be protected while less protection can be applied to the higher frequency data, as errors in the higher frequency bands have much less effect on the displayed image quality.

Also, similar to the contribution, the low latency of JPEG 2000 is something that would be practically impossible for wireless systems using an MPEG system based on long GOP coding.


Long-term Preservation
The broadcasters and video archivists are looking for long-term digital preservation on disk. In most cases, the source material is not digital, but film that needs to be scanned or high-quality analog videotape. As such, a destination digital format must then be selected.

Key requirements often include reducing the storage costs of uncompressed video while still maintaining indefinite protection from loss or damage. Moreover, the format should preferably enable digitized content to be exploited, which means providing flexibility — workflows again — and security. For these reasons, several studies and user reports claim JPEG 2000 to be the codec for audio-visual archiving.

Several reasons make JPEG 2000 a codec of choice for audio-visual archiving:

• The JPEG 2000 standard can be used with two different wavelet filters: the 9/7 wavelet filter that is irreversible and the 5/3 wavelet filter that is fully reversible. The 5/3 wavelet filter offers a pure mathematically lossless compression that enables a reduction in storage requirement of 50 percent on average while still allowing the exact original image information to be recovered. The 9/7 wavelet filter can encode in lossy or visually lossless modes.


• The scalability allowing proxy extraction, multiple quality layers, is of huge interest to ease client browsing and retrieval or transcoding and streaming.


• JPEG 2000 is an open standard that supports every resolution, color depth, number of components and frame rate.


• JPEG 2000 is license- and royalty-free.

The Future
Several initiatives are pushing the industry beyond today's HD: NHK Super Hi-Vision, also known as 8K and UHDTV, the Higher Frame Rates in Cinema initiative by James Cameron and Peter Jackson (up to 120fps), 16-bit color depth, and the numerous manufacturers that are now offering 4K technology.

The need for efficient codecs has gained significant attraction amongst the industry. The future of JPEG 2000 is bright as it is an open standard that requires less power, consumes less space in hardware implementations and generally delivers greater scalability, flexibility and visual quality than other codecs. An increasing number of manufacturers, broadcasters and producers are using JPEG 2000 implementations to adapt today's industry to these new challenges.

By Jean-Baptiste Lorent and François Macé, Broadcast Engineering

Metadata and MXF

Most video professionals are now quite familiar with metadata. But, just to be sure everyone is on the same page, when we use the term metadata in this tutorial, we are referring to information (data) that typically refers to a program, commercial or other video/audio content. Examples of metadata include: the name of a program, the length of a segment or an ISCII code associated with a commercial.

Collectively, video, audio, subtitles, AFD and other things people consume as part of a program are known as essence. Just remember that essence refers to the stuff we are watching when we view a program. Importantly, essence includes data (subtitles, teletext, AFD and so on). If we want to talk about data that is part of the program, we talk about data essence. Data essence is not metadata; data essence is part of the program that is intended for “viewing” by the end consumer.

Technical vs. Descriptive
Metadata tends to be treated as a single topic. But, in our mind, there are several different ways to classify metadata. One way to look at metadata is whether it is technical or descriptive. Technical metadata is metadata that is required to identify and play back essence properly. Examples include: a Unique Media Identifier (UMID), information about compression used and raster size.

Descriptive metadata is typically the sort of information operators in professional media organizations care about — program title, show number, kill date, ISCII code and so on. Descriptive metadata might also include things like shot notes, scripts and music scores.

Some metadata falls into a grey area. How would you classify GPS location, zoom and focus setting, crank rate, or robotic camera position? Is this technical metadata or descriptive metadata? Generally speaking, technical metadata is directly related to the essence or essence coding and does not include these data types.

Another way to classify metadata is to think about how frequently the metadata is expected to change. We would expect some metadata to remain constant for the duration of the content being viewed. For example, we would not expect the title to change halfway through a program. In the United States, we might expect that the technical metadata regarding frame rate would remain at 59.97Hz for the duration of the program. As you can see from these examples, the frequency of metadata change is an orthogonal classification (meaning it is completely unrelated) to the metadata type (technical or descriptive). Not surprisingly, metadata that remains constant is called static metadata.

Other metadata, such as timecode, would be expected to increase monotonically (increase by a count of one, only) on every frame. Timecode and other metadata may, therefore, be placed on a timeline that increases predictably, and should never decrease (run backwards) or unexpectedly jump ahead. This type of metadata might be called timeline-related metadata.

Finally, metadata associated with shot logging, describing actors in scenes or associating a music score to a section of a program may appear fixed for a period of time, may be duplicated in several locations during a program or may even overlap with other similar types of metadata. This metadata can be referred to as event metadata.

There is one other important family of metadata, and that is perpetual metadata. As you can guess, this is metadata that should never change. Systems rely on the fact that these metadata items are immutable. If something is immutable, it means that it cannot be changed after it is created. Examples of this include a unique ID and the location where a program was filmed. Remember, systems will count on the immutability of certain metadata. If you violate the rules, all bets are off.

Why does all this matter? Because, in the end, media professionals build and operate systems, and these systems need to be properly designed to handle all of these different types of metadata.

Metadata and Essence
How do you tie timecode or program title to a specific copy of a movie? In the tape world, the question was irrelevant. The timecode was either stored in the VBI or in the ANC data, and the program title was printed on a label on the box or the tape itself.

But, things have changed in the file-based world. Associating metadata, especially technical metadata, to a particular program can be critical. Professional file formats must contain not only video and audio, but also the technical metadata necessary to play back the content. When it comes to descriptive metadata, the door was left open as to exactly what types of descriptive metadata were to be included in the file. This is both good and bad. One of the most critical linking mechanisms between metadata and essence is the UMID. The UMID is a unique identifier that is used to identify a particular piece of content.

UMIDs and the Contract
It is important to understand that there is an implicit contract between systems that create content labeled with a UMID and systems that later manipulate the content or rely on the UMID to retrieve the content. Here is the contract: A system will never break the connection between a particular piece of content and the UMID that was originally associated with that content.

If you create a new piece of content, give it a new UMID. Simple, right? But, here is a twist: What if you create a bit-for-bit exact copy of the file? The rule is that you duplicate everything, including the UMID. But, now you have two copies of the content with the same UMID. Is this right? The answer is yes. And, if you ask a media asset management system to retrieve a piece of content using a UMID, you cannot say for certain which copy you will get. The particular instance of a copy of content is not uniquely identified by a UMID. For other reasons, a MAM system may uniquely identify each copy of the same content, but the UMID should not be used to do this.

In a file-based world, metadata becomes key. Understanding how unique identifiers work and treating them correctly is vitally important. Fortunately, manufacturers hide most of this from end users, so you may not even be aware that UMIDs exist.

By Brad Gilmer, Broadcast Engineering

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