The ISDCF Plugfest held this month demonstrated both progress and some pleasant surprises. Tests included the playout of both Interop and SMPTE DCP content, as opposed to only SMPTE DCP content in past Plugfests. (The intent was to learn if DCI and SMPTE DCP requirements broke anything in regards to legacy content.) The CSP/RPL protocol was handed some new twists in this round. HI/VI-N routing was examined. Several tests were imposed on forensic marking, including testing of the KDM flag that instructs the mark to be employed. Open subtitle rendering continued to be examined. And the Theatre Key Retrieval (TKR) protocol and CPL metadata snuck its way into the demonstration. (More on TKR later in this report.)
The primary purpose of the ISDCF Plugfest is to learn if products are ready to play content in the SMPTE DCP format. The Plugfest is needed as there is very real desire among some studios to transition to the format to benefit from the security features. But the stakes are high. There are over 60,000 screens today, and a distribution that doesn’t play on all systems is a dangerous distribution. The Plugfest exists to mitigate this risk.
One of the biggest sticking points of past Plugfest testing has been the rendering of open subtitles on screen. While some products still exhibit font size problems and problems placing text on screen in the correct position, the overall performance of products has significantly improved. Audio routing is also important. Interop DCP audio is inflexible in the channel assignments for audio, and has caused theatres to be wired in a certain manner. SMPTE DCP, however, is quite flexible in how it carries audio. This flexibility has some advantages, but if the media block can’t reroute audio to match the manner in which the theatre is wired, there will be big problems. Not all products pass the audio re-routing test. Of these, one product from a major manufacturer has made no progress whatsoever in the past year.
Forensic marking is important to anti-piracy efforts. It may only be of use after the content is stolen, but it provides the only path available for tracking those who commit the crime. Several aspects of forensic marking were examined. First is the ability to securely turn it on or off using the KDM. All devices demonstrated this ability. Another aspect is the ability to selectively mark the audio tracks. By this, it is intended that certain audio tracks may need to remain unmarked, such as DBox tracks. The tests indicate that there is much work that remains to be done to get this feature implemented correctly.
All products have previously shown the ability to synchronize with a closed caption server using CSP/RPL. However, this Plugfest was the first where multiple makes of Alternative Content Servers (ACS) were present. (In a closed caption system, the ACS is the closed caption server.) Prior to this Plugfest, only USL made an ACS. But Doremi has now formally released its ACS to the market, and they brought that to the Plugfest for testing. In addition, Pirate Eye wanted to test their prototype ACS Pirate Eye won’t use the ACS for closed captions, but it will prove useful for flagging to the camcorder detector when the movie is playing.
This being the first time that the Doremi ACS was tested, it was refreshing to see that it passed with flying colors. Doremi’s unit maintained good synchronization and was not disturbed by extraneous captions in the test material. Pirate Eye also scored, having proven to their engineer that they could synchronize to the server successfully. For the USL, Doremi, and Pirate Eye ACS units to simultaneously work from a single server requires that the server support multiple connections. This requirement is implied by the standard, but not explicitly defined. So while the good news is that all of the ACS devices were working fine, the bad news is that not all of the servers on the market support multiple connections for CSP/RPL. This includes some top name equipment, and will require more work if products such as Pirate Eye are to successfully use the protocol.
This was the first Plugfest where Interop DCP content was loaded into the servers under test to learn if legacy performance was sacrificed along the way. The sad news was that at least one system lost the ability to drive a Series 1 projector. Hopefully that won’t be hard to fix.
The big question at the end of the two days of testing is whether or not another Plugfest is needed. There was thought at drawing the line on some features of SMPTE DCP, as if they weren’t needed. But that would cause a lot of problems down the road. It’s the opinion of this author, and many others, that if there is to be a transition to SMPTE DCP, that all of the features must be available to content owners. Else, why bother?
It’s no surprise, then, that the next Plugfest will be held in early June.