Broadcast is shifting rapidly from its traditional linear production model to file-based systems. This gives rise to tremendous flexibility, instant delivery and huge opportunities for cost reduction primarily through improved efficiency.
Those efficiencies can only be realized, however, if those files are both accessible and usable. Access relies on accurate information, much of which regards how the file is cataloged and archived. Usability relies on the format of all aspects of the content, the obvious picture resolution and audio format ,but also the data carried both within the VBI, VANC and HANC.
Indeed, the flexibility and efficiency improvements can be fully realized only if the original content (picture + audio + data) can be read, managed, manipulated and converted to meet the final output criteria. Modern broadcast facilities rely on information: Equipment is triggered by cue tones, switched by active format descriptors (AFDs), aligned to time code and managed by automation. (See Table 1.)
Data, embedded within the content, is not only there for the benefit of the broadcaster, but also it is there for the viewer in the form of captions, teletext, program guides, red-button interactivity, parental control and much more. Regardless of whom the intended user may be, there are only three reasons for inserting data: to enhance, to control or simply to meet regional legal requirements. Whoever makes use of the data, for whatever reason that data was created and whatever the intended use, the importance of inserting, reading, managing and monitoring data efficiently and effectively throughout the broadcast chain is essential. (See Figure 1 on page 60.)
Data insertion is commonplace throughout the broadcast industry and has been for the past 30 years. Initially, data was inserted into the VBI portion of the program stream as analog waveforms. With the advent of SDI, these waveforms were digitized. Indeed, much data today is still in analog format and simply converted to a digital waveform to be inserted into the SDI stream.
With the advent of HD, VBI has been superseded by VANC. In terms of the physical insertion of data, there is no real difference. The primary difference is HD carries only packetized data (i.e. not digitized waveforms). These are now formatted as digital ancillary data packets (with 000 3FF 3FF prefix), which carry parallel data rather than analog signals that have been digitized or serial digital data (e.g. video index).
This allows considerably more data per line than previously possible. For instance, one VBI line of teletext contains 40 displayed characters (+5 characters of run-in and framing codes). One line in 1080i video contains 1920 Y and C words in the active video portion (i.e. that used for VANC). One OP47 (see the teletext bullet point on page 65) multipacket can contain up to five analog teletext lines and is about 255 words long. It is theoretically possible to fit seven of these multipackets onto a single HD line (equivalent to 35 old teletext lines), or more than a full page on a single line. Again, it is theoretically possible to fit the same amount of data into both Y and C, which would give approximately 70 analog SD teletext lines on a single HD line.
Ultimately there are questions regarding bandwidth in the ASI transmission stream to put all this data in, but it proves the vast potential for data to be used in HD transmissions. A suitably equipped set-top box is able to read this data and processes it as required. The increase in volume of data will inevitably lead to increased interaction between the viewer and the broadcaster, making true interactive TV a certainty in the coming years.
Within the broadcast facility, there is no difference with regard to the transport or use of data in one format or another. Regardless of whether the data started life as an analog waveform and was subsequently digitized or is inserted as SD or HD-SDI, it is carried with the picture and audio as a single digital stream.
As discussed, the primary difference for the broadcaster is not the format of the data but the amount of data and the uses it is put to. For instance, widescreen signaling (WSS) on line 23 was primarily a European initiative. It was first introduced to account for the consumer take-up of 16:9 TVs, which was quicker and more widespread than in the rest of the world. WSS was introduced specifically to address the consumer requirements to switch formats between programs transmitted in 4:3 and those transmitted as 16:9. AFDs are in principle the same thing as WSS. However, AFDs are used extensively throughout the broadcast facility to switch, for instance, aspect ratio converters.
Similarly, cue tones or triggers can be in the form of a line 23 waveform (analog or digitized) or as a data string, e.g. a packet 31 teletext stream. There are always advantages and disadvantages to whichever is chosen. As an example, a line 23 waveform is a robust signal. While in use, it is present on every frame. Because line 23 is considered part of the picture, it is effectively bandwidth-free. The primary disadvantage with line 23 is it can, when passing through the MPEG encoder, become corrupted by stray motion vectors unless care is taken in the encoding process.
Packet 31, however, is a teletext packet and is, therefore, passed without incidence by all encoders. Packet 31 is normally only transmitted with a single frame, so a dropped frame will result in a dropped cue tone and, therefore, a missed action somewhere downstream. If it were a trigger for an ad server, it could be a very expensive dropped frame indeed. Packet 31 could be pulsed with each frame, but this is not bandwidth-free. So Packet 31 is a simple solution and easy to work through encoders and decoders. A WSS waveform cue tone, on the other hand, is bandwidth-free and robust but not as simple to get through the entire signal chain.
Different hardware, in the same way as different data, also has pros and cons. A PC with a commercial SDI interface is a low-cost option and well-suited to offline subtitling. However, for live broadcast, low-cost commercial interface cards often cause both operational and quality issues. Professional-quality cards, on the other hand, can be prohibitively expensive. It is, therefore, more robust, reliable and less expensive to use an embedded system for data insertion, albeit, if required, interfacing with a standalone PC to provide the data carrying the captions.
Each format of data and the equipment to insert it has advantages and disadvantages. The important point for a modern broadcast facility is that it has the flexibility to choose what data type is inserted from a single hardware solution and that the solution is not a proprietary solution forced upon it. Similarly, as the world moves toward standardization of certain aspects of the broadcast chain, (for instance 16:9, driven by the TV set manufacturers) some equipment in much use today will become redundant. Therefore, it is important that the chosen solution has built-in flexibility in both the hardware and software, and that it is also future proofed, i.e. can be repurposed should requirements or standards change in the future.
In principle, there are only two types of data that concern the broadcaster, that which is produced by or for them, such as subtitles, metadata and program guides, and that which is generated by a piece of hardware situated in the transmission stream — for instance, AFDs and cue triggers. The only question the broadcaster should need to answer is: Is the format of the raw data to be inserted analog, digital, RS422/485/232, TCP/IP or embedded within an existing SDI stream? None of this should matter to modern data encoders/inserters. Neither should it matter if the format of that data is not the format required for transmission.
For instance, data formatted to an SD standard when transmission is required in HD should be managed by the inserter hardware. Transcoding data between formats should be standard in any modern equipment. There is too much data and too much change for modern data management to be carried out by single-function boxes — one for insertion, one for decoding, one for monitoring, one for bridging/shuffling, etc. Today's modern data management systems must insert, read, bridge, shuffle, copy, move and transcode data in a single, cost-effective unit.
There are few guarantees in broadcast. The only guarantee that anyone can give with certainty is that broadcast has changed and will continue to change. Through that change, there is a need to replicate all or part of legacy systems, but in new formats.
One example is the growth of playout centers. Playout centers have long existed, but their scale and number far exceeds that of only a few years ago. There is good reason for this — efficiency, cost saving and reduction of fixed overheads. Indeed, it is no different to the outsourcing and core business focus seen in almost every other industry over recent years. But this brings with it a series of challenges. Each broadcaster is used to doing things a certain way. Often the playout center has a service level agreement for one broadcaster that requires completely different data management requirements to any of the many channels it manages. Flexible systems are a must. The hardware and software within the system must accommodate and work with a multitude of different incoming data — all while having the flexibility to meet their contractual obligations independently for each individual broadcaster.
The data that reaches as far as the consumer is decoded by the set-top box or TV, and acted upon accordingly. For example, if data is received prompting an interactive icon to appear on screen, the set-top box recalls the icon and adds it to the picture. If DVB subtitles are present, the receiving device adds them to the picture when required. When AFDs associated with the program currently being viewed are present, the set-top box adds black bars to the sides of the picture so it doesn't get squashed when viewed on a 16:9 TV. Data is also inserted to enable interactive content and enhance the consumer experience, such as viewer participation in live voting and the ability to set viewing reminders for a program.
Moving forward, with the increased presence of advanced set-top boxes, data for triggering revenue-gathering features — such as disabling fast forward functions during ad breaks or showing a small advertisement graphic during fast forward — can be implemented.
There is also the added complication, or should that be opportunity, of DVB or ASI insertion. Data can be inserted directly into the ASI stream with the relevant timing information added to the header to ensure accuracy of, for instance, switching of equipment or display of subtitles. This is especially useful where one particular point in the chain receives and retransmits programs in an MPEG form, negating the need to decode and re-encode in order to insert data. This saves capital, overhead and infrastructure costs while also maintaining picture quality.
The following is by no means an exhaustive list of data types, nor does it seek to give an in-depth explanation or analysis of the merits or limitations of each. There are specifications for data types that contradict and there are others that are evolving, but this just goes to prove the need for a flexible, future-proofed approach to managing data within the broadcast facility and beyond to the relay station and the viewer.
- Ancillary data packet and space formattingThere are two types of ancillary data packet in component (SDI) HD video: type 1 and type 2. This allows a wider range of data types (more than 29,000) to be used. The two types of data packet are the same size, and the only difference is the way the data is used inside the packet.Type 1 data has a data block number (DBN), whereas type 2 has a secondary data ID (SDID). Type 1 data with a DBN is used when there is a requirement to distinguish several packets with the same data ID (DID). The most common type of data packet used with what was traditionally VBI data is type 2, with type 1 mainly used for audio data.
- VANCPeople often see the word VANC and think it is something mysterious, new and difficult to understand. In fact, it is in effect the same as VBI. The term VBI refers to the time taken for the cathode ray beam to return to the top of the frame after scanning a frame (or field), while the term VANC means vertical ancillary data space, demonstrating that the space/bandwidth associated with the TV transmission is now firmly established as being used for transmitting ancillary data. (See Figure 2.)
- AFD and bar dataAFD and bar data is used to indicate how video shot in a particular aspect ratio should be displayed when shown on a display of a different aspect ratio. For example, a movie shot in 16:9 can be shown in two different ways when displayed on a 4:3 television. It can have bars added at the top and bottom to maintain the full image (the height of the bars being determined by the bar data element of the signal if the aspect ratio is greater than 16:9), or it can have the sides of the image cut off so that it fills the vertical space on the display. Correct AFD signaling ensures that the footage reaches consumers as the director intended.
- Switching pointsSpecific switching points exist for two reasons. The first reason is to ensure that a digital transmission can be switched to another source without picture disturbance that is visible to consumers. The second is to ensure that ancillary data is not corrupted when a switch takes place. (VBI data should not be transmitted on the switching line.) These switching points are within a specified zone on particular VBI lines. The switching line can differ depending on the video standard in use, and interlaced standards have a switching line specified in each field.
- Control signalsControl signals, also known as opt-outs, are used to trigger other pieces of equipment in the transmission chain. For example, a control signal can be inserted at the central playout point of a national television channel that has multiple regions. This signal can be used at the start of ad breaks to trigger advertisement servers located in the remote regions. These signals can also be used to switch other equipment in to play, such as remote servers — for instance, local advertising or news.
- Time codeTime code is used for synchronization of equipment in the broadcast chain, such as subtitle/caption inserters, making sure the captions appear with the correct piece of video. It is also used for synchronizing automation, to ensure, among other things, that commercials start and end at the correct time, and for audio, to make sure it's in sync with the video.
- Program descriptorsProgram description data is used in HD video to carry information that defines the characteristics of the audio and video material being broadcast, such as whether the service has captions, details of the audio signal, information for parental control and program genre.
- eXtended Data Services (XDS)/V-chipXDS are used in NTSC video to carry data such as time information for setting clocks on VCRs and TVs. It also carries basic information such as program name and station identification.Likewise, it is used to carry V-chip content rating data, which allows programs to be blocked based on the program content. The consumer's television is programmed to allow viewing of content up to a rating that is chosen as acceptable for that particular receiver, and viewing is blocked for any program outside this threshold.
- DVBMore data is being inserted directly into the ASI transport stream. Each multiplexed stream carries a number of programs (typically from two to 16) identified by the Program Allocation Table (PAT). Each program is mapped via the Program Map Table (PMT), which breaks the program into video, audio and data, each identified by Packet Identifiers (PIDs). Data can be common across many program streams or specific to a particular program stream. In deciding what data is common and what is shared, many factors are taken into account — for instance, whether the multiplexing is fixed data rate or statistical. Typically, the type of data inserted directly in the DVB stream includes idents, GPI triggers and subtitles.In DVB subtitling, subtitles and basic graphics can be added to video after the compression stage. When the insertion occurs at this stage, the subtitles can either be converted to bitmap form (bitmap DVB subtitling), or the raw subtitle data is sent to the MPEG encoder (code-based DVB subtitling), before being sent to the mux and transmitted with the station output. The advantage of code-based subtitling is its backward-compatibility with teletext-based receivers, while bitmap subtitling has the ability to generate character-based subtitles, along with richer content using graphics, different fonts, sizes and colors.
- Teletext (OP47)Teletext is a means of transmitting basic pages of text information that can be decoded by the receiving television set. It is also a means of increasing revenue through advertising. One teletext page can be transmitted using the VBI data space in 25 lines of 625-line video. Pages are transmitted in a sequential manner, and data is normally inserted on several VBI lines to speed up page cycling and reduce the amount of time consumers have to wait for a page to load.Teletext is also used as a means of transmitting subtitles/closed captions in SD 625-line video. However, teletext is represented by an analog waveform, so with HD services, the OP47 subtitling standard is the most commonly used to produce what appears to the consumer as the same end product.
- Country and Network Identification (CNI)CNI data was originally an analog waveform that gives country of origin information and is transmitted as a packet 30 teletext data packet. It is now available as OP47 packetized data and rarely used by broadcasters today. The interesting point for this document is its evolution from analog waveform to packetized data and its modern use, where it forms part of the audience viewing data. Its use is not widespread, but significant nonetheless. CNI shows that both data and its uses evolve and that unique uses for data, in whatever form, continue today.
- MetadataMetadata is probably the most misused and confused term in the broadcast industry. Metadata is simply data that describes data. Think of it rather like a library system. The library is divided in sections, and each section is categorized and then subcategorized. If you use the system, you can find what you are looking for almost instantly. However, if you tried to find the specific volume by going through each shelf and each book, you may be at the library for longer than you would like.
Metadata is simply the categorization and subcategorization of information required by broadcast engineers, researchers, program makers and anyone else who needs to find a specific clip, or edit or produce content. It simply lets them know where they will find specific data they need to fulfill their objective.
Data, and its management, is an integral part of broadcasting. Its uses, formats, generation and transmission are all changing and will continue to change. Hardware and software must be able to accommodate not just today's requirements but legacy and future requirements, while being flexible enough to manage interim solutions.
Ian Hudson is CEO at Microvideo.
The latest product and technology information
Future US's leading brands bring the most important, up-to-date information right to your inbox