SMPTE Working Groups and Ad Hoc Groups meet June 2 in Los Angeles. Following the last round of meetings in February, several document ballots closed:
- 428-5 TIFF Mapping for DCDM
- 428-19 Additional Frame Rates for the SDI interface
- 428-x Archive Frame Rates
- 430-6 Auditorium Security Message (ASM) (Revision)
A brief explanation of these documents follows:
In the workflow of creating a movie, the creation of the JPEG2000-compressed and encrypted digital cinema package (DCP) is the last step prior to distribution. During the post-production process, work is performed with uncompressed images. The output of the post production process must be shared with other post houses and distribution houses, thus a B2B file interchange format is needed. The TIFF file format is ideal for this purpose as it was designed to preserve image quality. However, the TIFF format has many optional features, not all of which are necessarily supported by receiving equipment. For this reason, 428-5 is necessary to dictate which features of TIFF are to be used for motion picture interchange. This ensures wide support for a common interchange format among business entities prior to actual distribution to the theatre.
It may seem a bit late to bring 428-5 forward as a standard, as surely the workflow process is working. In fact, this document has been in discussion for at least 7 years. It’s true that a certain amount of collaboration already exists among tool makers to ensure compatibility. But if the number of tool makers is to grow, the standard is needed.
The work on frame rates is also forward-looking. Digital cinema is built around the 24 frame rate of film. The only exception to this is the built-in support for 48 frames per second at 2K resolution – which is the crack in the door that allows support for 3-D. (3-D was never considered by DCI when settling on frame rates.) However, not all production uses the 24 frame rate, and so additional frame rate and archive frame rate standards are needed to guide manufacturers. So as to provide the means to not burden all digital cinema equipment, these additional frame rates are described in separate documents.
The revision of 430-6 is significant. The ASM protocol is required by DCI. The revision of 430-6 was largely needed to support the Series 2 projector, which employs a DCI-compliant security structure, and is different than that of the TI Series 1 projector. (The Series 1 projector does not have a DCI compliant front end, even with the addition of the “Gore” board.) However, it was an error in judgment to have standardized 430-6 prior to providing a solution for all security architectures described by DCI. This revision fixes that error. The fix incorporated by the standard is that which TI already specifies for Series 2, and is implemented by compliant server manufacturers.
The revision of SMPTE security documents within SMPTE has recently come under question, 430-6 not being the only such document to be fixed up. In fact, within the coming year, nearly every SMPTE security document will have been amended or revised. The complaint is that these standards were pushed through too quickly, and should be a model of what not to do in the future.
But this complaint is difficult to support. Standards bodies exist to support business. Digital cinema was invented from the ground up, and SMPTE provided the umbrella under which businesses could collaborate on standards. The speed at which business needed to get to market meant that a stake needed to be placed in the sand, even if mistakes were bound to occur. It is true that the security standards were pushed through, including the KDM and FLM, without testing. Indeed, in most if not all cases, the security standards were pushed through without implementation of any kind. But by pushing these standards through, DCI had standards to refer to in its specification, and manufacturers had templates to design to. Bugs may have been found along the way, but the very existence of these documents caused all manufacturers to work together, rather than allowing them to solve these problems independently, which would have been their natural direction, and a disaster for the industry.
Last but not least, the “ugly slash” problem continues to rear its head. The chair of 21DC will ask that a formal decision be made on the matter by means of ballot. The excruciatingly simple question is whether or not all namespace names in XML documents are to end with a forward slash. For example, a namespace name with such a trailing forward slash is:
http://www.smpte-ra.org/schemas/433/2008/dcmlTypes/ ,
which is the namespace name for SMPTE 433 Datatypes. (Note that there is no web page associated with this namespace name, although it looks like the URL for a web page.) The forward slash at the end is actually a typo, but was approved as the normative namespace, slipping through the review process that took place prior to standardization. That simple oversight led to a series of errors in later documents, all of which must now be addressed. The conclusion of this effort, regardless of the nature of the conclusion, will affect the software code of many companies. This could include the CSP/RPL protocol used by 3rd party closed caption devices, whose documents have been withheld from standards publication until the “ugly slash” problem is resolved.
