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.
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.
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.
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
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:
- x264
- MainConcept
- DivX H.264
- Elecard
- Intel Ivy Bridge QuickSync
- XviD
- DiscretePhoton
- MainConcept CUDA
This rank is based only on the encoders’ quality results. Encoding speed is not considered here.
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).
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).
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.
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.
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
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.
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.
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
Subscribe to:
Posts (Atom)
