PrestoCentre Standards Register
The PrestoCentre Standards Register gathers information on standards for content and metadata used across all communities involved in audiovisual digital preservation.
Showing posts with label IT Broadcast. Show all posts
Showing posts with label IT Broadcast. Show all posts
DPP Launches a Producer’s Guide to File Delivery
As the UK broadcast industry moves towards full digital delivery, the DPP has launched A Producer’s Guide to File Delivery, a complete handbook that explains – from a production point of view – all that is involved and required in the new process.
The guide is published six months out from the 1st October, the date UK broadcasters will move to full digital delivery, and is a step-by-step guide to the process. The handbook includes guidance on the key stages of file delivery:
- Completing the Programme – final Video and Audio
- Creating MXF Files
- QC Checks – Eyeball tests and Automated QC
- PSE Checks
- Adding DPP Metadata
- Delivering DPP Standard Programme File
- Late Changes before TX
Key Media Industry Organizations Launch Joint Task Force on File Formats and Media Interoperability
The launch of the Joint Task Force on File Formats and Media Interoperability was announced today by its sponsors, the North American Broadcasters Association (NABA), Advanced Media Workflow Association (AMWA), Society of Motion Picture and Television Engineers (SMPTE), International Association of Broadcast Manufacturers (IABM), American Association of Advertising Agencies (4A’s), and Association of National Advertisers (ANA). The European Broadcasting Union (EBU) is participating as an observer.
Bringing together manufacturers, broadcasters, advertisers, ad agencies, and industry organizations (standards bodies and trade associations) serving the professional media market, the Task Force has an ultimate goal to create greater efficiencies and cost savings for exchange of file-based content.
The group’s initial focus will be to gather and analyze requirements for a machine-generated and readable file interchange and delivery specification — including standardized and common structured metadata — for the professional media industry. Use case examples include promo, spot, and program delivery from a provider to a broadcaster.
In one of its initial actions, the task force has published a survey designed to collect data on user requirements. Open to any member of the media industry, the survey asks participants to create a one-sentence “user story” by identifying the nature of their work, the specific function they seek, and the business value that would be provided by that function.
Other task force activities will include the collection of data on existing products for transcode, transform, and file QC, and their ability to be driven by data from UML, XML, API, script, and other machine-to-machine communication mechanisms.
In addition to analyzing and publishing this data within a formal report, the task force will analyze the data in terms of current, planned, and unplanned standards activities and publish recommendations for future activities.
Source: SMPTE
Browse Proxy Transcoder
The use of a browse file – a frame accurate low bit rate proxy of the master essence – is an important enabler in lightweight IT based broadcast and production workflows.
The BLM Ingest service provides the ability to create the browse proxy in real time during linear ingest and in BLM deployments in which material arrives in the file domain a simple browse proxy transcoder is provided for ‘low-res’ generation.
BLM now make this simple tool available in a cut-down watch-folder only version to allow system builders to reap the benefit of low-res operations without having to tie up a fully featured transcoder.
The service will accept source material as an D-10 IMX, DNxHD, AVCi-100, DVCPro, XDCAM HD, MPEG-2, DV, H.264 or ProRes and transcode it to a defined resolution and bit rate.
The IP Revolution Reaches Playout
Television facilities are gradually evolving and are becoming more IP/networking-centric in many areas. IP networking infrastructure has been built up throughout facilities primarily to handle the exchange of files from one storage device or file-based system to another. Files have been successfully navigating the IP domain within television and playout facilities for some time.
IP networking makes perfect sense for file-based processes, but what about real-time program streams? There are many areas where real-time or linear program streams are in use. Today, we commonly find IP networking used for real-time program streams on the edges of the facility, typically in the incoming feeds area or at the point of outbound transmission. At these points, the stream is encoded and compressed for transport. Take that farther, and here is the killer question: Could IP networking be used throughout a facility?
Headends Take an IP plunge
Anyone unsure about the suitability of IP networking infrastructure to carry real-time program streams need only look to the radical transformation that has occurred in cable, DTH and IPTV headends in the past 10 years. In the beginning, these headends would accept a combination of compressed and uncompressed signals, and employed a combination of SDI and ASI infrastructures.
Now, these headends have transitioned to using IP networking infrastructures for several reasons. Namely, the signals they transport are now compressed when they arrive and remain so either all the way to the home or, for cable systems that still support analog tiers, are decoded close to the home where the signal is modulated to RF. But, why did TV delivery headends transition to IP?
With the functional integration of devices leading to the development and proliferation of compressed domain splicer systems, the transition to IP was facilitated. Today, traditional MPEG decoders and encoders are being replaced by integrated systems that feature IP inputs and outputs, and combine ad and graphics insertion and transcoding from one compression format to another, or from one bit rate to another, inside a single box.
With these integrated transcoder systems, a signal can be demodulated at the entrance of the facility but stay IP until it hits the integrated processing chain. Here, it is internally transcoded, while allowing processing and insertions to take place, thus allowing routing to remain in the IP realm. This integration has allowed the scalability to more channels. Also, it allows for ease of redundancy within a flexible, routable environment, compatible with telecom networking gear already in use there. Having switched the video infrastructure to IP, headends have the ability to share the same infrastructure for TV, telephony and data for Internet services.
Could IP Replace SDI?
In cable headends, the case was clear. But, what about a TV station or multichannel origination facility? Some in the industry, and many from outside the industry, think Ethernet/IP networking should be replacing SDI everywhere in a TV plant. Many think that the transition from SDI to Ethernet will happen gradually.
In considering this transition, we follow something of a common sense rule that states, “If the real time video signal is already encoded/compressed, then it is practical to carry it over an IP infrastructure. But, if you are inside a facility, and you have to encode a signal just to switch and distribute it within the facility, then it may be less practical or economical to use an IP infrastructure.”
Based on this rule, there are specific areas within a television production and origination facility where Ethernet/IP networking for real-time programs makes sense, and other areas where SDI/HD SDI makes more sense.
Production
There are several reasons why an IP/Ethernet infrastructure may be less practical today in a live production environment. Many sources in a live production environment are not natively compressed (cameras, graphics, etc.), and there is a desire to keep them uncompressed to maximize quality and, more importantly, to avoid encode/decode delays.
One could consider leaving these sources uncompressed and routing them using Ethernet/IP equipment instead of SDI. But, the high bit rates associated with uncompressed video, and the large number of sources in a modern live production, make this impractical today.
The bit rates for uncompressed video are quite large, ranging from 270Mb/s for SD, 1.5Gb/s for HD and on up to 12Gb/s for 4K. Now, if we were only talking about a few uncompressed sources, then using IP/Ethernet equipment would be workable. But, it is common to have 1000 x 1000 matrices in a large production facility. And, some larger facilities are now at 2000 x 2000 matrices. The Ethernet networking gear currently available is just not economically viable at those rates and fabric sizes, but it will become more feasible as the price per 10GigE port decreases.
IP’s Next Use in a Facility
Based on our rule that if signals are compressed, then it is practical to use IP infrastructure, we think and IP networking infrastructure begins to make a lot of sense in the playout area. This is the area where automation systems, playout servers, branding, subtitle insertion and delivery encoding combine together to deliver real-time program streams to increasingly diverse distribution platforms. Consider a typical multichannel playout system as it exists today in an SDI-centric world and a more IP-centric approach.
Why Migrate Playout to IP?
Three main motivational factors influence migration to an IP infrastructure in playout. The first factor is integration. In the past, a playout chain consisted of many discrete devices each interconnected by SDI and supported by SDI routing to allow reassignment of resources and redundancy protection.
Today, broadcasters, particularly multichannel broadcasters, use integrated playout systems, often called "channels in a box", that combine most of the functionality of a channel chain in a single device, typically software on a standard computer server.
These integrated systems accept one or two inputs for live programming but perform all other master control functions inside the box. The output of the integrated channel box typically is a delivery-ready real-time stream on SDI. A few vendors of these integrated channel boxes now provide an option for an encoded (compressed) output over IP.
The second factor enabling IP in playout is that multiple “deliverable” bit rates are becoming required as facilities need to feed secondary outputs for OTT formats along with primary outputs, such as main distribution systems using, for example, ATSC or DVB-T for terrestrial transmission or DVB-S for satellite transmission.
Where a standalone encoder is used now to compress the channel’s stream for one stream, in the future, encoders will be replaced by transcoders that support IP inputs and outputs, and provide multiple delivery formats. Like in cable headends, these IP in/IP out transcoders enable the transition to IP infrastructure.
From a topology perspective, there is often a separation between playout and uplink or delivery functions. With the availability of IP connectivity between those points, it creates a natural place to start migrating the interconnect between playout and uplink to IP.
Within this context, it is now possible and sensible to link the integrated playout device to the transmission transcoding devices using an IP infrastructure. The output of the channel chain is encoded within the playout chain and delivered to the transmission transcoding device over IP. But, rather than have the playout device provide a final delivery grade encode, it provides a higher bit rate mezzanine encode.
Mezzanine Encoding
A mezzanine encode is a low-compression encode resulting is an intermediate bit rate. The ideal mezzanine rate is high enough to maintain maximum quality for multigeneration transcoding. At the same time, the rate should be low enough for efficient, cost-effective transportation around the facility and be transcoded easily to multiple output formats for playout distribution.
Preferably, it would be a common format used for recording the original video, which is good enough for editing. One example would be Sony XDCAM-HD. It is common and supports good-quality 4:2:2, 8-bit compression, and it is easy and economical to encode. XDCAM HD is also compatible with MXF, allowing carriage of multiple audio tracks and SMPTE 436M ancillary data. In the context of the playout application, the mezzanine encoding technique is sensible because it keeps encoding in the integrated playout device simple and provides a maximum base quality for the transcoder to work with.
Benefits and Challenges
The benefits of an IP networking structure are abundant. First, the flexibility and absolute routability of all signals is simplified. All source signals are wrapped up and compatible with all destinations. We are able to create a truly redundant architecture, which allows protection against points of failure. We are able make use of generic IP switches, which are present already in many facilities and easy to acquire. Since the switches support IP inputs and outputs, they are easy to integrate with other IP systems, such as subtitle insertion devices.
Monitoring can be accomplished for many points with standard IP monitoring tools. Creating an IP infrastructure may eventually allow us to virtualize the playout device as a software application in a virtual machine, allowing several instances to run simultaneously and further enhance scalability.
There also will be challenges moving to an IP-based playout infrastructure, similar to those faced with the TV delivery transition to an IP infrastructure. If we think of the structure physically, it will become much more complex. Before, it was simple when one wire carried one signal to one port. Now, with potentially several signals per wire, routing becomes less obvious. Where exactly is each signal? Can I just take this wire and plug it in elsewhere? No. There is not a simple way to just patch around a point of failure because it is no longer a single signal. If there is a failure, it is difficult to fix, meaning it fails big time.
Luckily, IP networks have the ability to provide excellent redundancy to prevent a potential massive failure. IP network topologies can ease the creation of truly redundant architectures, which prevent many catastrophes. By simply combining two channel chains along with two switches, every routable path becomes redundant. A failure in one chain or one switch will not prevent the signal passage. Actually, we could lose both a switch and a channel chain and still be OK. This redundancy allows the broken node to be serviced without disrupting normal operations.
Managing signal routing also becomes more complex. With SDI routing, it is common to find simple router control panels that allow operators with basic training to quickly make changes to signal routing. In an IP routing environment, routing is typically a system administration task. Tools will have to be developed to make setting of routes simpler and more operational.
Conclusion
In the future, as IP/networking technology evolves, Ethernet port speeds increase and port costs decrease, IP migration will naturally move to other areas. As technology becomes increasingly IP-centric, following this path will leave facilities prepared for whatever follows. Before then, however, now is the time to become more IP-centric and knowledgeable.
By Sara Kudrle and Michel Proulx, Broadcast Engineering
Broadcast Delivery 101
Broadcast Delivery 101 is a book created for the post production community from around the world, this tool will allow you to understand the different requirements for Television Commercial Delivery.
Created by Craig Russill-Roy a 25 year professional in the industry and offers a window into the world of digital delivery, video codecs, audio loudness and most importantly tutorials.
This 117 page book is a great tool for anyone that is exporting commercials for not only local adaptation but international requirements as well.
This book is available for download on your iPad with iBooks or on your computer with iTunes.
SDI Over IP
As bitrates increase and equipment prices drop, IP-based communication technologies – both fixed and wireless alike – are pushing more and more dedicated communication systems into retirement. The sheer amount of connectors currently found on professional video cameras make some of the advantages obvious that an IP/Ethernet-based solution brings.
Also, the number of HD SDI signals that you can squeeze into a 10GigE or even 100GigE line is a convincing argument for mediumterm migration to IP. With SMPTE 2022-6, the wrapping of all SDI formats within IP will be defined, but previous wrappings were never used to actually do anything in the IP-layer – they were just used as a transparent channel.
This article outlines the steps and required mechanisms to go “all-IP” and leverage the possibilities that come with it. The first step to take is to achieve seamless switching between signals in the IP layer, which was implemented at the IRT as a software-based Proof of Concept, followed by a novel approach regarding multicast signal distribution within a network. The applications made possible by these features are only limited by your imagination.
Digital Video and Audio Interfaces
Professional video interfaces are undergoing a change, in part due to the age of the initial digital systems, and also because of the emergence of high-performance interconnects for consumer use. First, let’s summarize the existing solutions for high-bandwidth audio/video transfer.
Existing Interfaces
Standard-definition Serial Digital Interface (SD-SDI) is a serial link that can transmit uncompressed digital video and audio (usually up to eight channels) over 75Ω coaxial cable. Without repeaters, rates of up to 270Mb/s over 1000ft are customarily used. Digital Video Broadcasting, Asynchronous Serial Interface (DVB-ASI) was defined for the transmission of MPEG Transport Streams, and is electrically similar to SDI, with a data rate of 270Mb/s.
HD-SDI is the second-generation version of SDI and allows the transmission of HD (1080i and 720p) signals over the same 75Ω cables as SD-SDI. It can handle rates up to 1.485Gb/s. A dual-link HD-SDI provides up to 2.97Gb/s and supports 1080p resolution, but it is being replaced by the single-link 3G-SDI, the third-generation version of SDI that can reach a maximum bit rate of 2.97Gb/s over a 75Ω coax cable.
Consumer electronics are catching up with pro interfaces. Although driven from the non-professional side, evolving consumer electronics interfaces are affecting pro equipment, especially displays. The legacy analog VGA and hybrid analog/digital DVI interfaces used to interconnect PCs with displays could be obsolete by 2015, as chipset manufacturers have announced their intent to withdraw support by that year, and that means PC motherboard manufacturers will likely pull the functions from their new designs. Replacing them on PCs, DVDs and other consumer video devices are HDMI and DisplayPort.
HDMI 1.4a has a throughput of 8.2Gb/s, allowing it to carry up to 4096p24 video (or 1920p60) at 24 bits per pixel, as well as various 3-D formats, eight channels of audio, Consumer Electronics Control (CEC) and High-bandwidth Digital Content Protection (HDCP). DisplayPort 1.2 supports up to 8.6Gb/s, and thus can carry payloads similar to that of HDMI. Functionally, the interfaces differ in the way they handle video and audio, with HDMI using a raster-based protocol, and DisplayPort transporting content in packets. From a market standpoint, the main difference between HDMI and DisplayPort is that the first was designed primarily as a digital TV interface, while the second was intended as a PC-centric interface. The two interfaces also have license and royalty differences.
The USB 3.0 (also called Super Speed USB) specification is used almost exclusively as a PC (or tablet) interface to support peripherals. It supports transfer rates up to 5Gb/s, over a maximum distance of about 16ft. As a data-transfer protocol, USB is payload-agnostic, so the transfer of audio and video is essentially limited to the latency characteristics of the interface. IEEE 1394 was originally designed to support bit rates of up to 400Mb/s, but newer versions of the standard support speeds as high as 3.2Gb/s.
Thunderbolt is a newer 10Gb/s bidirectional serial interface. Developed by Apple/Intel, it provides full-bandwidth data and video transfer between a PC and peripheral and display devices, up to a distance of 10ft. Serving as the hardware layer below the PCI (bus used inside PCs) and DisplayPort stacks, the product utilizes a time-synchronization protocol that allows up to seven daisy-chained Thunderbolt products to synchronize their time within 8ns of each other. Like USB, Thunderbolt’s key differentiator from other display-interface technologies is its capability to supply power to the peripheral, at up to 10W, superseding USB 3.0’s 4.5W capacity.
HDBaseT is a recent standard that uses CAT-5e Ethernet cable to transmit 10Mb/s video and two-way control signals and power, with enough capacity for additional simultaneous 100BaseT Ethernet uses. The great attraction to this interface is that it can be deployed over existing Ethernet infrastructures, greatly reducing implementation cost. As with other data-based interfaces, the video can be conventional uncompressed HD, 3-D, 4K or high frame rate. The maximum specified distance for HDBaseT is 328ft, which can be extended through 8 hops, and the standard supports carrying up to 100W of power.
Wireless Video Products
There are several wireless standards that are vying for use driving displays. Wireless Home Digital Interface (WHDI) is an interface that uses the same 5GHz band as Wi-Fi, and is designed to transmit uncompressed HD video at data rates of up to 3Gb/s in a 40MHz channel. The range is said to be greater than 100ft, with a latency of less than 1ms.
WiGig (by the Wireless Gigabit Alliance) is a specification based on 802.11 that supports generic data transmission rates up to 7Gb/s. A different approach is being taken by WirelessHD, a specification that defines a wireless protocol that enables consumer devices to create a wireless video area network (WVAN) that can stream uncompressed audio and video up to Quad Full HD (QFHD, or4K) resolution, at 48-bit color and 240Hz refresh rates, with support for 3-D video formats. The specification, which is based on 802.15, supports data transmission rates at 10Gb/s to 28Gb/s.
The Wi-Fi Alliance has also announced a certification program, called Miracast, through which certified devices can make use of an existing Wi-Fi connection to deliver audio and video content from one device to another, without cables or a connection to an existing Wi-Fi network.
In another industry development, MHL is being used to connect tablets and smartphones to displays. MHL defines an HD video and digital audio interface optimized for connecting mobile phones and portable devices to HDTVs, displays and other home entertainment products. MHL features a single cable with a five-pin interface that is able to support up to 1080p60 HD video and 192kHz digital 7.1 channel audio, as well as simultaneously providing control and power (2.5W) to the mobile device.
Because MHL does not specify a unique connector, various mechanical interfaces have emerged, including five-pin and 11-pin MHL-USB connectors. MHL fully supports the HDCP specification (used elsewhere on DVI and HDMI interfaces) for the safeguarding of digital motion pictures, television programs and audio against unauthorized access and copying.
Maintaining High-Speed Networks
High-speed networks are challenging to maintain. When any of these high-speed interfaces are combined with long runs of cable, performance will degrade, primarily from inter-symbol interference caused by cable-based dispersion of different signal frequencies, as well as jitter caused by processing equipment, as shown in the figure below. The result will be an increase in error rate at the receiving end.
To minimize this, video plants should be designed and maintained with equipment having low jitter and cable runs having the lowest length necessary, with repeaters used for lengths nearing maximum specifications. Adhering to these precautions will result in reliable operations.
By Aldo Cugnini, Broadcast Engineering
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
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
AMWA Releases MXF Commercial Delivery Specification
The Advanced Media Workflow Association (AMWA) has released a new MXF Commercial Delivery specification, AS-12. The constrained version of MXF has been developed to enable more efficient handling of commercials through the many transactional and media processing operations between conception and air.
As broadcasters look to serve commercials to long tail delivery platforms as well as their primary channels, controlling costs is all-important. Many versions may exist of the same commercial, adding confusion to the traffic operations. Versions may be sourced from different distribution routes, arriving with different wrappers and codecs, as well as different aspect ratios.
MXF Commercial Delivery aims to solve two problems: unique identification, and defining a master spot for the creation of long-tail versions.
MXF Commercial Delivery unambiguously identifies the spot through the Ad-ID unique identifier carried in a “digital slate”. Current practice to identify commercials is by the visual slate preceding the commercial. Although a human operator can read this by playing the commercial, it does not lend itself to use by automated systems.
With MXF Commercial Delivery the advertisement identification metadata is carried as a Descriptive Metadata track and serves as a digital slate. The digital slate can be used to reconcile the video and audio components of the commercial with the traffic instruction thus preventing expensive mistakes. The Ad-ID unique identifier ensures that what the advertiser ordered gets to air.
MXF Commercial Delivery, AS-12, is an addition to AS-03, MXF for Delivery. AS-03 defines MXF files optimized for program delivery, and intended for direct playout via a video server. Used together, the specifications allow the agency to supply broadcasters with a master commercial, along with information like closed captions and AFD that the broadcaster can use to create the lower resolution versions appropriate to their long-tail delivery platforms.
The AS-12 metadata or digital slate can be created early in the production process to uniquely identify the commercial. AS-12 carries fields to identify the advertiser, the agency, brand and product, as well as the title. Through the use of the guaranteed unique Ad-ID, the rekeying of identifiers that typically happens today is avoided. House codes used by agencies or broadcasters are replaced with the Ad-ID, avoiding many of the issue of misidentified commercials that have been commonplace.
The Commercial Delivery specification is sponsored by AMWA principal member Ad-ID, a joint venture of the American Association of Advertising Agencies (4A's) and Association of National Advertisers (ANA), and establishes a baseline for improved Operations, Administration, and measurement of advertising assets across the myriad of current and emerging delivery platforms, which when fully deployed, will result in substantial financial gains and improvements in productivity that will flow back to all participants within the supply chain.
Source: Advanced Media Workflow Association
DPP Unveils Technical & Metadata Standards for File-based Programme Delivery
The Digital Production Partnership (DPP) – a partnership between ITV, Channel 4 and the BBC – has unveiled its new Technical and Metadata Standards for File-based programme delivery in the UK.
Through the DPP, seven major broadcasters (BBC, ITV, C4, Sky, Channel Five, S4C and UKTV), have all agreed the UK’s first common file format, structure and wrapper to enable TV programme delivery by digital file. These new guidelines will complement the common standards already published by the DPP for tape delivery of HD and SD TV programmes.
Working closely with the Advanced Media Workflow Association (AWMA) in the US, the DPP has been the driving force behind the creation of the organisation’s ‘AS-11,’ a new international file format for HD Files. The new DPP guidelines will require files delivered to UK broadcasters to be compliant with a specified subset of this new, internationally recognised standard.
By implementing one set of pan-industry technical standards for the UK, the DPP aims to minimise confusion and expense for programme-makers, and avoid a situation where a number of different file types and specifications proliferate.
The new DPP standards aim to remove any ambiguity during the production and delivery process. A key aspect is the inclusion of editorial and technical metadata, which will ensure a consistent set of information for the processing, review, and scheduling of programmes, as well as their onward archiving, sale and distribution.
As part of the file-based guidelines, the DPP’s member broadcasters have agreed a minimum set of common metadata to be delivered with a file-based programme. And, in a bid to encourage international adoption of its metadata standards, the DPP has worked closely with the European Broadcasting Union (EBU), mapping its minimum set of common metadata to existing ‘EBU-Core’ and ‘TV-Anytime’ metadata sets.
Alongside these new standards, the DPP is currently building a free-to-use, downloadable, metadata application to enable production companies to enter the required editorial and technical metadata easily. The new application is due to launch in spring 2012.
The agreement of these new file based technical standards does not signal an immediate move to file based delivery. Instead, the DPP seeks to provide clarity around digital delivery that will become the expected standard in the future.
During 2012 BBC, ITV and Channel 4 will begin to take delivery of programmes on file on a selective basis. Production companies wishing to deliver by file should discuss this at the point of commission, and seek formal agreement with their broadcaster at the outset of production. After a period of selective piloting, file based delivery will be the preferred delivery format for these Broadcasters by 2014.
Source: Digital Production Partnership
AS-11: MXF for Contribution
AS-11 is a vendor-neutral subset of the MXF file format to use for delivery of finished programming from program producers and distributors to broadcast stations. AS-11 files are intended to be complete and ready for playout.
AS-11 supports playout while the file transfer is in progress, a workflow is referred to as “late delivery”. It is preferable for AS-11 files to be used by playout servers directly without rewrapping of the MXF data structures.
The content may be delivered at the ultimate bit-rate, picture format and aspect ratio, or it may be transcoded at the broadcast station to the required bit-rates and formats. Similar transcoding may be applied to audio and captions; additionally, specific audio and caption tracks may be selected for different broadcast channels.
The content may be pre-packaged for broadcast without further splicing or it may be segmented for ease of insertion or replacement of interstitials.
AS-11 supports SD video encoded as D-10, 50Mbit/s, and HD as AVC-Intra Class 100. Audio can be PCM, AC-3 or Dolby E.
AS-11 defines a minimal core metadata set required in all AS-11 files, a program segmentation metadata scheme, and permits inclusion of custom shim-specific metadata in the MXF file.
Source: Advanced Media Workflow Association
EBU-TT Subtitling Format Published for Industry Comments
The EBU has published a new Subtitling Format specification (EBU Tech 3350). The new format is called EBU Timed Text (EBU-TT) and provides an easy-to-use method to interchange and archive subtitles in XML.
EBU-TT is based on the W3C Timed Text Markup Language (TTML) specification. The EBU format can be seen as a constrained version of the W3C spec, aimed at providing a solution more tailored to broadcast operation. This is especially relevant as broadcasters are increasingly moving to file-based HDTV facilities, where subtitles are created, edited, exchanged and archived together with the content.
The previous EBU subtitling format was EBU STL (Tech 3264), developed at a time when information was still exchanged on floppy discs. However, as many broadcasters still use STL or have archived STL files, great care was taken in the development of EBU-TT to make sure that it provides backwards compatibility with its predecessor.
The EBU is also providing an XML Schema for EBU-TT.
Source: EBU
IMF for a Multi-Platform World
Among other things, the looming arrival of the Interoperable Master Format (IMF) is illustrating that the digital media industry is now capable of moving "nimbly and quickly" to create technical standards to address and evolve the ways that it packages, moves, and protects precious content in the form of digital assets in a world where the technology used to do all that, and the very industry itself, is fundamentally changing at a startling rate. The term "nimbly and quickly" comes from Annie Chang, Disney's VP of Post-Production Technology who also chairs the SMPTE IMF work group (TC-35PM50).
Six Hollywood Studios through the University of Southern California Entertainment Technology Center (USC ETC) started to develop IMF in 2007, and in early 2011, they created an input document that the SMPTE IMF working group is now using as the basis of the IMF standardization effort. Over time, IMF has developed into an interchangeable, flexible master file format designed to allow content creators to efficiently disseminate a project's single master file to distributors and broadcasters across the globe.
Chang reports that progress has moved quickly enough for the work group to expect to finalize a basic version of the IMF standard in coming months, with draft documents possibly ready by early 2012 that focus on a core framework for IMF, and possibly a few of the potential modular applications that could plug into that framework.
Once that happens, content creators who have prepared for IMF will be in a position to start feeding all their distributors downstream far more effectively than has been the case until now in this world of seemingly unending formats. They will, according to Chang, be able to remove videotape from their production workflow, reduce file storage by eliminating the need for full linear versions of each edit or foreign language version of their content, and yet be able to take advantage of a true file-based workflow, including potentially automated transcoding, and much more.
The rollout will still need to be deliberate as various questions and unanticipated consequences and potential new uses of IMF begin to unfold. But that said, Chang emphasizes that the goal of being able to streamline and improve the head end of the process—creating a single, high quality, ultimate master for all versions is real and viable, and with a little more work and input, will be happening soon enough.
"Today, we have multiple versions, different resolutions, different languages, different frame rates, different kinds of HD versions, standard-definition versions, different aspect ratios—it's an asset management nightmare," she says, explaining why getting IMF right is so important to the industry.
"Everyone creates master files on tape or DPX frames or ProRes or others, and then they have to create mezzanine files in different formats for each distribution channel. IMF is designed to fix the first problem—the issue of too many file formats to use as masters."
Therefore, IMF stands to be a major boon for content creators who repeatedly and endlessly create different language versions of their material.
"For a ProRes QuickTime, you are talking about a full res version of a movie each time you have it in a new language," Chang says. "So 42 languages would be 42 QuickTime files. IMF is a standardized file solution built on existing standards that will allow people to just add the new language or whatever other changes they need to make to the existing master and send it down the chain more efficiently."
Chang emphasizes the word "flexible" in describing IMF, and the word "interoperable" in the name itself because, at its core, IMF allows content distributors to uniformly send everybody anything that is common, while strategically transmitting the differences only to where they need to go. In that sense, IMF is based on the same architectural concept as the Digital Cinema specification—common material wrapped together, combined with a streamlined way to package and distribute supplemental material. Eventually, each delivery will include an Output Profile List (OPL) to allow those transcoding on the other end a seamless way to configure the file as they format and push it into their distribution chain.
Unlike the DCI spec, however, IMF is not built of wholly new parts. Wherever possible, the file package will consist of existing pieces combined together in an MXF-flavored wrapper. This should, Chang hopes, make it easier for businesses across the industry to adapt without huge infrastructure changes in most cases as IMF comes to fruition.
"With IMF, we are using existing standards—a form of MXF (called MXF OP1A/AS-02) to wrap the files, and parts of the Digital Cinema format and other formats that many manufacturers already use," she says. "So, hopefully, there is not much of a learning curve. We hope that most of the big companies involved in the process won't be caught unaware, and will be able to make firmware or software upgrades to their systems in order to support IMF. Hopefully, companies will not have to buy all new equipment in order to use IMF.
"And with the concept of the Output Profile List (OPL), which essentially will be global instructions on output preferences for how to take an IMF file and do something with it relative to your particular distribution platform, companies that are doing transcoding right now will have an opportunity to use that to their advantage to better automate their processes. IMF has all the pieces of an asset management system and can use them all together to create standardized ways to create packages that fit into all sorts of other profiles. It's up to the content owners to take these OPL's and transcode the files. As they do now, they could do it in-house or take it to a facility. But if transcoding facilities get smart and use IMF to its potential, they can take advantage of IMF's capabilities to streamline their processes."
Chang says major technology manufacturers have been extremely supportive of the SMPTE standardization effort. Several, such as Avid, Harmonic, DVS, Amberfin, and others have actively participated and given input on the process, which is important because changes to existing editing, transcoding, and playback hardware and software, and the eventual creation of new tools for those tasks, will eventually need to happen as IMF proliferates. After all, as Chang says, "what good is a standard unless people use it?"
She emphasizes that manufacturer support is crucial for IMF, since it is meant to be a business-to-business tool for managing and distributing content, and not a standard for how consumers will view content. Therefore, outside of the SMPTE standardization effort, there is a plan to have manufacturers across the globe join in so-called "Plugfests" in 2012 to create IMF content out of draft documents, interchange them with each-other, and report on their findings.
As Chang suggests, "it's important to hit IMF from multiple directions since, after all, the first word in the name is 'interoperable.' " As a consequence of all these developments, it's reasonable to assume that IMF will officially be part of the industry's typical workflow chain where content distributors can start sending material to all sorts of platforms in the next year. Some studios and networks are already overhauling their infrastructures and workflow approaches to account for IMF's insertion into the process, and encoding houses and other post-production facilities should also, in most cases, have the information and infrastructure to adapt to the IMF world without any sort of fundamental shift. But the post industry will be somewhat changed by IMF, especially if some facilities or studios decide on processes for automating encoding at the front end of the process that changes their reliance on certain facilities currently doing that kind of work.
However, Chang adds, the broadcast industry specifically will probably have the most significant learning curve in terms of how best to dive into IMF since, unlike studios, which have been discussing their needs and pondering IMF since about 2006, the broadcast industry was only exposed more directly to IMF earlier this year when SMPTE took the process over. IMF was originally designed and intended as a higher bit-rate master (around 150-500MB/s for HD, possibly even lossless, according to Chang), but broadcasters normally use lower bit-rate files (more like 15-50MB/s).
"However, I feel that broadcasters would like to have that flexibility in versioning," Chang says. "But because they need different codecs and lower bit-rates, there is still discussion in SMPTE about what those codecs should be. Broadcasters are only now starting to evaluate what they need out of IMF, but there is still plenty of time for them to get involved."
Of course, as the explosion of mobile devices and web-enabled broadcasting on all sorts of platforms in a relatively short period of time illustrates, viewing platforms will inevitably change over time, and therefore, distribution of data will have to evolve, as well. As to the issue of whether IMF is relatively future-proofed, or merely the start of a continually evolving conversation, Chang is confident the standard can be in place for a long time because of its core framework—the primary focus to date. That framework contains composition playlists, general image data, audio data (unlimited tracks, up to 16 channels each), sub-titling/captioning data, any dynamic metadata needed, and so on.
Modular applications that could plug into that framework need to be further explored, Chang says, but the potential to allow IMF to accommodate new, higher compressed codecs, new or odd resolutions or frame rates, and all sorts of unique data for particular versions is quite high.
"The core framework we created with documents is something we tried to future proof," she says. "The question is the applications that might plug into that core framework (over time). We are trying to make it as flexible as possible so that if, in the future, even if you have some crazy new image codec that goes up to 16k or uses a new audio scheme, it will still plug into the IMF framework. So image, audio, or sub-titling could be constrained, for example, but as long as the sequence can be described by the composition playlist and the essence can be wrapped in the MFX Generic Container, the core framework should hold up for some time to come."
To connect with the SMPTE IMF effort, you can join the SMPTE 35PM Technology Committee, and then sign up as a member of 35PM50. The IMF Format Forum will have the latest news and discussions about the status of the IMF specification.
More information about IMF:
- Overview of the IMF presentation at NAB 2011's Post Pit event.
- Amberfin's Bruce Devlin SMPTE PDA Now Educational Webcasts, discussing MXF application designs coming out of the IMF Work Group.
By Michael Goldman, SMPTE Newswatch
DPP to Release Metadata App
The Digital Production Partnership (DPP) will release a metadata application next year to help production companies comply with proposed file-based delivery requirements. The web-based app will allow production companies to enter a required set of metadata that is associated with a completed TV programme and wrap it into MXF files that are compliant with the cross-broadcaster group’s common standards.
“This will enable the creation of finished file-based TV programmes by independent producers for onward delivery to major UK broadcasters,” the DPP said.
The app, which was described as being compatible with common PC and laptop operating systems, is set to be rolled out during “spring/summer” next year.
From 2012 the BBC, ITV and Channel 4 will begin to take delivery of programmes as files on a selective basis. File-based delivery will be the broadcasters preferred delivery format by 2014. The common standard for the delivery of file-based programmes is set to be announced in by January.
Source: Broadcast
AMWA Draws Up Delivery Spec
AS-02, which has been in development since 2007, is designed for use by post-production facilities, broadcasters and distributors that face the challenge of distributing programmes to a variety of platforms.
“A particular episode of a programme may need to be rendered to tens of different versions for linear broadcast, on-demand platforms, use by airlines and so on,” AMWA executive director Brad Gilmer told Broadcast. “Together with audio tracks and subtitle files, that might result in hundreds or thousands of elements that need to be held together.”
AS-02 will be a specific way of using MXF (Material Exchange Format) with video codec that will support MPEG-2, H.264 and JPEG2000. It will also wrap multiple mono, stereo and surround audio tracks, and carry subtitles.
The application specification is currently undergoing AMWA’s intellectual property rights (IPR) review process. The review closes on 11 November, with ratification of the spec expected to take place at AMWA’s board meeting on 14 November.
A statement from Avid described the spec as “a cornerstone of the future content creation paradigm”. It said: “With migration of physical to file-based workflows largely complete, the coming phase of media enterprise consolidation will be predicated upon technologies like AS-02.”
Gilmer added: “There is a lot of interest in this from companies facing the challenges of professional media distribution. “It used to be easy to distribute content when you sent a tape to playout and everyone watched the programme at the same time, but now people watch on myriad devices and the goal is to get content to as many platforms as possible.”
By George Bevir, Broadcast
BXF Explained
For years, broadcast automation systems and business systems needed manual access and conversion interface applications to convert metadata to/from their respective systems. The multitudes of proprietary interfaces are difficult to keep up with, especially as system upgrades and enhancements were added to either side.
The new SMPTE 2021 BXF 1.0 schema standard is one of the biggest advances in broadcast automation in this decade. The holy grail of automation has always been to provide a system that uses a central database for metadata between traffic and master control. Since centralizing a database between business systems and master control/operations is easier said than done, the next best thing is to standardize on a communication schema for the exchange of mission-critical data.
Technology standards are needed to organize varying systems and technologies. While manufacturers offer the promise of tight integration between varying systems, they still offer varied proprietary systems. BXF changes that. The new open SMPTE schema standard levels the playing field for manufacturers. By enabling their systems to work within the protocol's framework, manufacturers can assure broadcasters of getting nonproprietary full-feature metadata conversions and messaging systems.
History and Stats
In 2008, SMPTE developed and published a schema standard called BXF (Broadcast Exchange Format) 1.0 or SMPTE 2021. In a nutshell, BXF was developed to replace the various archaic text conversion schemas that have been developed over the years to interface, access and transfer schedules, playlists, dubs lists, record lists, delete lists, etc., from business systems to automation systems.
Today, SMPTE representatives note there are dozens of manufacturers that have developed applications and workflow systems using the BXF schema. There have been more than 150 national and international SMPTE members, including industry-leading manufacturers, involved in the development and enhancement of BXF. In this new digital world of broadcasting where multichannel, multimedia operations are the norm, the BXF schema standard helps manufacturers build applications for automating processes and procedures to next-generation enterprise levels.
The current BXF 1.0 includes an Exchange Schema Definition (XSD) collection for schedules, as-run, content, content transfers, etc. The BXF schema helps manufacturers simplify and automate the communication and workflow between a broadcaster's diverse business and transmission systems such as traffic, program management, content delivery and automation. The master control and traffic departments are the most common broadcast uses. When properly implemented, BXF-based applications automate the workflow process, streamline operations, maximize value of content and inventory, and increase flexibility for sales and advertisers.
As an XML-based communication schema, BXF allows for near-real-time messaging and updating between disparate systems. The XML-based messages include instructions about program or interstitial changes, allowing an automated approach to as-run reporting and schedule changes. Other BXF capabilities include near-real-time dub orders, missing spots reports and content management.
In the past, a phone call to/from traffic was the norm. Seeing a traffic department representative in master control to make changes to the paper schedule is usually a daily event. In today's world, business departments need to know exactly when a program or interstitial has aired and if it aired correctly, and they need to know it as soon as possible.
Revenue Optimization
One of the most important factors about BXF-based applications is that they allow the decision-making aspects of master control schedule changes to be made in the traffic department. Traffic personnel can maximize revenue opportunities by providing lucrative replacements to any missing spot scenario. Or, when lucrative missing “copy” finally arrives and is ingested into playout video servers, traffic can make decisions on which interstitials/programs to drop and replace. Traffic has advertiser contract information giving them the ability to switch programs and interstitials to more lucrative advertisers.
The sales department also benefits from BXF-based applications. Because of the automated near-real-time fashion of the BXF messaging schema, the sales department can make last-minute, higher-revenue interstitial or program additions to the on-air schedule. So while BXF schemas lower costs through standardizing, streamlined processes and minimized manual changes/inputting, they also generate more revenue through revenue optimization.
Comprehensive Event Structure
In creating playout schedules, the goal is to create a schedule with the minimum and most efficient amount of effort. BXF-based applications simplify the creation of complex multiline event situations by automating the creation of multiple event lines within a playout schedule. In the most efficient configuration, traffic does little to activate a complex playout scenario like a live news break for example. For traffic personnel, it may be as simple as creating a one-line traffic schedule with a predefined identification number. A BXF-based application and the master control automation system take that one-line traffic schedule and convert it into a complex multiline playout schedule with all the needed secondary events. If BXF-based applications are properly configured with predefined conversion rules, master control personnel are not saddled with creating or fixing complex multiline event structures.
Latest Applications
News production automation is the latest craze in broadcast automation. A handful of manufacturers have developed systems to automate live newscast productions. The more advanced news production automation systems repurpose content for distribution via Internet, mobile devices, VOD and syndication. A key aspect of these systems is the ability to monetize content assets. Interfacing with traffic and billing systems, via BXF-based applications, helps to maximize advertising avails to other platforms. BXF-based applications automate the heavy lifting of scheduling, changing and verifying ads in live on-air and live streaming productions.
Content Metadata Management
Beyond schedules and as-runs, access and distribution of database metadata is another of BXF's benefits. Business systems such as sales, programming and rights management use BXF-based schemas and applications to automatically populate centralized data warehouses with cost and scheduling data. The master control automation database can be populated with extensive and accurate metadata from traffic systems. Media Asset Management (MAM) and Digital Asset Management (DAM) systems use database information from business systems also. News production systems use BXF-based applications to automate schedule changes and verify information for on-air, VOD, mobile and IPTV schedules. BXF-based applications and features can allow for the exchange of metadata among systems that may not have direct access to content.
Content Movement Instructions
As rich media content moves from place to place, the metadata associated with this content moves also. This usually is a manual process or one with error-prone work-arounds such as hot-folders. Today, there are BXF-based applications that can automate the transfer of metadata that originates from advertising agencies and business systems to master control, nearline and archive MAM/DAM systems.
For example, let's say traffic makes a change request via a BXF schema message to master control, and a new interstitial is added to the master control playout schedule. Once the message is accepted by master control and the event is added to the schedule, the master control system will begin searching for that rich media within its automation database. If the rich media is located on a nearline and/or archive system, the master control automation or MAM/DAM system will activate a transfer request for that rich media. Metadata from the business systems will populate the master control and media asset management systems database. BXF-based applications can create move-instruction messages to activate a system's physical transfer of content from source to destination.
The Spotlight Moves to Business Systems
As BXF-based applications become more popular, we can see business systems playing a larger role in the control and monitoring of broadcast production systems such as master control automation, MAM, DAM, etc. It's clear that improving and advancing operations, procedures and workflows that are upstream of master control is now more important than ever for broadcasters. The spotlight will shift to the traffic, programming, sales and rights management systems. For example, it makes sense for traffic to be responsible for master control metadata and schedule changes. With advertiser contracts in hand, the traffic department has the information to make the best possible decisions.
Cost Versus Benefit
We've mentioned many times during this report that BXF-based applications and their open-standard schema save on costs. To factor how much, you must first define cost and values to each aspect of the workflow and operation, multiply personnel and wage costs by the hours it takes to transfer files, manually update databases, manually correct schedules, manually enter and correct data in databases, plus e-mails, phone calls, meetings, etc. Define the costs of how much time and effort is being exerted by functioning in a manual mode.
Value is the next factor. What is the average value of your interstitials and programs? How much revenue would be lost if an interstitial or program did not air or it aired incorrectly, requiring a make-good? Value can also mean potential revenue. By offering automated processes, last-minute changes can incur additional revenue. Near-real-time updating is constantly showing commercial avails. These benefits have value. Value can also be given to your on-air look. How do we compare to the competition? Automated systems by definition give you a higher up-time percentage and better on-air look than stations without automation.
Implementation
Implementing BXF-based applications involves hardware, software and a good amount of workflow changes. The majority of a BXF implementation is reorganizing and revamping your workflow process. In fact, you'll spend more time on redefining duties and tasks than you will with the physical implementation of hardware and software. In physical terms, the BXF-based applications and their schemas run best on server-class hardware with modern network accessibility to all parties involved.
To implement BXF in your facility, you must first understand the needs. Then, understand how BXF will benefit your system. You must also understand the manufacturer and its integration of BXF schema standards in its products. Once you've pinpointed the areas where BXF-based applications can be used, devise a plan. Creating a diagram and documenting is always a good first step.
Even though automating simplifies an operation, it's only smart to have accurate documentation. The main reasons for documentation include the training of new staff, for trouble-shooting issues and for future configuration changes or enhancements. Test offline and verify the results. Train staff on how the new processes and procedure will work, and then activate your BXF-based applications.
BXF 2.0
The SMPTE BXF standard and schema is alive and constantly changing and updating. SMPTE representatives note there are big advances coming in the next version of BXF. SMPTE balloting and voting are still required, but there are a few new advances worth noting. If voting passes, the next BXF version standard will soon provide support for simultaneous program events in master control.
A simultaneous program event scenario occurs when there is a closing credits DVE squeeze while simultaneously starting the next program. BXF will properly report timestamps and durations for programing and interstitials. Previously, secondary automation events such as DVE, logos, crawls, animation keys, etc. were considered nonprogram events. In BXF 2.0, the plan is that secondary events can be identified as program events for proper automation as-run reporting.
Multilanguage support is also planned for BXF Version 2.0. If committee voting passes, the BXF schema will be enhanced to allow for multiline, noncontrol program titles that can be places on the schedule in multiple languages. The noncontrol information lines are used by program managers to properly schedule and verify, via as-run, multilanguage programming. Master control operators will also benefit by knowing if a program will run on other output channels in another language or that the program has multilanguage audio channels.
The Future
There are many enhancements coming in future releases of the BXF schema standard. Most notably is how the BXF schema will be used in application to interface with rich media MXF files. BXF-based applications will someday have the ability to map and extract metadata information from MXF files. For example, if a station or network receives an MXF file from a distributor, a BXF schema-based application can extract the metadata from the MXF file without having to wait for a hard copy sent separate via paper timesheet or e-mail.
Combining metadata with rich media is a common operation in many applications for European broadcaster. For example, metadata extraction is automatically entered into the master control automation system for playout. Databases in master control and traffic for spot or programming metadata is not common like it is in the U.S.
The EBU, Advanced Media Workflow Association (AMWA) and their Framework for Interoperability Media Services (FIMS) initiative are working to improve how metadata and rich media are managed in a Service-Oriented Architecture (SOA) environment. It is hoped that the output of this initiative will soon be brought to SMPTE for due process standardization.
We can also expect more rights management support in the future. As our industry is quickly moving from multichannel to multichannel/multimedia operations, rights management is more important than ever. Both broadcasters and content owners will benefit by accessing near-real-time information regarding their content. BXF schema-based application manufacturers are working to make these options and features a reality.
Thus far, advertising agencies have not used BXF. SMPTE representatives hope that one day ad agencies will also be able to benefit from BXF. National advertising and content metadata begins with advertisers and ad agencies. By adding ad agencies to the broadcasting workflow, metadata accuracy can be improved and operations can be more streamlined. For example, today interstitials have unique agency identification code. If they used BXF-based schema and applications, this agency identification code would stay with the metadata throughout the entire end-to-end workflow. The metadata would begin at content creation, then stay through advertising buys, content distribution, playout, as-run, business reconciliation and finally to verification, affidavit creation and billing.
Why BXF?
Many manufacturers think the adoption of the BXF schema standard shows a commitment to and support of a broadcaster's right to choose the best systems available. Inventory and revenue optimization work extremely well with the BXF standard in the mix. Competition is a good thing for the industry, and it raises the bar of functionality. Manufacturers are eager to compete to ensure broadcasters remain competitive in a fast-changing multichannel, multimedia digital world. Standards such as BXF are the best way to ensure that happens.
BXF schema-based applications are becoming an essential component of highly automated broadcast operations. The notion of both eliminating cumbersome manual file exchange and having a near-real-time exchange of data between production and business systems is a good example of how today's broadcast technology provides more functionality and requires less time to manage.
By Sid Guel, Broadcast Engineering
The Digital Production Partnership Announces Two Major Initiatives to Accelerate the Move to Digital Production in Television
The Digital Production Partnership (DPP) – a partnership between ITV, Channel 4 and the BBC – has today made two major interventions in digital production in Television. The first is the release of a report, The Reluctant Revolution – Breaking Down Barriers to Digital Production in TV. The second is the announcement of common Technical & Metadata standards for file-based delivery of TV programmes to all major UK broadcasters.
Painting a picture of a technical and creative revolution that is struggling to ignite, the report argues the reason is not the indifference or ignorance of producers, but rather the failure of broadcasters, suppliers and manufacturers to understand the practical realities and frustrations of the production community.
Gathering the views and experiences from a broad range of production companies across the UK, the report, commissioned by the DPP from industry analysts MediaSmiths International, concludes that for all the new technology of recent years, there is no easily workable and affordable model for end-to-end digital production available to independent producers.
“The move to end-to-end digital production is inevitable,” says the report, “but the pace of change is limited by the lack of clear signposts, or standard ways of working, and therefore a reluctance in the production community to set off on the journey… The key to ignition for this slow-moving revolution is the acceptance by all concerned of the day to day realities faced by production communities, and an understanding of where and how the benefits can be identified and achieved.”
The report identifies a number of opportunities and interventions that could bring about revolutionary change in digital production. These include pay-as-you-go models for web and cloud based tools and services, a new role for existing trusted providers such as facility houses, and a more pro-active role for the Broadcasters.
Mark Harrison, Controller of Production, BBC North and BBC lead for the DPP, said of the report and its outcomes, “Those of us who have been evangelists for the creative and business benefits of fully digital production have been mystified by the slow pace of change. This report explains that slowness, and offers practical suggestions for how change can be accelerated – not least by recognising that Broadcasters must get more involved.”
The second announcement made today reflects the commitment on the part of Broadcasters to get more involved: the DPP has unveiled the key features of its Technical & Metadata Standards for File-based Delivery, which will be published in full at the end of this year.
In response to producers citing ‘unnecessary complexity and lack of standardisation’ as one of the key barriers to digital production, the DPP, as a starting point to gaining greater simplicity, has clarified the UK Broadcaster’s technical expectations around file based delivery.
Through the DPP, six broadcasters have agreed the UK’s first common file format, structure and wrapper to enable TV programme delivery by file. These new guidelines will complement the common standards already published by the DPP for tape delivery of HD and SD TV programmes.
By agreeing one set of pan-industry technical standards for the UK, the DPP aims to minimise confusion and expense for programme-makers, and avoid a situation where a number of different file types and specifications proliferate.
The DPP has also worked closely with the Advanced Media Workflow Association (AMWA) based in the US, on a new standard for HD files. AS-11 is planned to be published by AMWA by the end of the year, and the DPP guidelines will require files delivered to UK broadcasters to be compliant with a specified subset of this internationally recognised file structure.
Key Features of the File Standard
• Designed for completed programme deliveries
• Based on the MXF file format, AVC Intra compression at 100 Mb/s for HD, and IMX at 50 Mb/s for SD
• Founded on a new AMWA international standard, AS-11
• Includes a minimum set of requirements for Programme Editorial and Technical Metadata
The common metadata standards, which form an important part of the new file-based delivery guidelines, have been developed with reference to the European Broadcasting Union’s EBU Core.
The new standards aim to remove any ambiguity during the production and delivery process. A key aspect is the inclusion of editorial and technical metadata, which will ensure a consistent set of information for the processing, review and scheduling of programmes. As part of this requirement, the DPP is planning to provide an application to enable production companies to enter this metadata easily.
Kevin Burrows CTO Broadcast and Distribution, C4 and DPP Technical Standards Chair, said, “Having one set of standards for file-based delivery across the industry is of huge benefit in ensuring ease of exchange. It will also reduce costs for independent producers as well as minimising confusion amongst programme makers.”
The agreement of these new 'file based technical standards' does not signal an immediate move to file based delivery. Instead, the DPP provides clarity now around which file formats, structures and wrappers will become the expected standards for file-based delivery as it is phased in.
From 2012 BBC, ITV and Channel 4 will begin to take delivery of programmes on file on a selective basis. File based delivery will be the preferred delivery format for these Broadcasters by 2014. This announcement represents long notice lead-time to the industry, and will enable production and post production companies to ready themselves for this transition.
Source: Digital Production Partnership
Subscribe to:
Posts (Atom)
