Open Source tools are described throughout the DCI specifications, and the nuance of using them is detailed in the myriad SMPTE (and ISO) documents of Digital Cinema. The Digital Cinema Package (DCP) is a complex joining of various video and audio standards coupled with several security protocols that make the transport, local storage and playout of entertainment able to be used by any combination of the available ‘compliant’ media players and projectors.

Since official compliance is a new part of the dcinema world, this hasn’t been an easy task. It is made more complicated by the several transitions that the equipment is going through; Series One and Series Two projectors, external to internal media blocks (IMBs), InterOp to SMPTE compliant systems are a few of the major examples.

For the last 10 years packages have been made by the classic companies, Technicolor and Deluxe, and more recently by some of the integrators such as Cinedigm, ArtsAlliance and XDC. Dolby has long had a separate group making packages.

There are several manufacturers who make package creation systems. The two most popular are from Doremi (CineAsset) and Qube (QubeMaster Pro and Xpress). Fraunhofer makes a package named EasyDCP. All of these systems cost in excess of $5,000. All are using somewhat user-cuddly front ends to steer the user through the many details and choices available. It is well known in the field that any product that pops out the other side needs to be tested on each variation of cinema player and projector to make certain that it will play when needed.

OpenDCP is no different², but until now its interface was by command line (CLI), which added a layer of complexity to the learning curve. This month a new release was posted on the open source code site http://code.google.com/p/opendcp/.

The package roadmap tells of some of the features that hold it back from being the perfect tool for all users. One item not listed is that the GUI version will only create single reel packages (though the CLI will create multi-reel packages). And like all DCP creation packages, the user needs to test the package on the target system.

This brings up the point of “Why”, which becomes easily understood if one searches the net for requests by film-makers and directors who want their product played at film festivals and local cinemas that use digital projection systems. These artists commonly have eaten their relatively small budgets getting the entertainment shot and edited, where there is enough format and standards confusion. Often the festival site doesn’t know the answers either since this is yet another technical area in flux, manned by volunteers who only get fragments of data to pass on to their constituents. The topics of using DVDs or Blu Ray discs comes up. There is a commonality of panic as each question brings up further confusion. The nuance of multi-track audio and going from TV-centric HD standards to truly HD cinema standards (wider color space, 4:4:4 color depth instead of 4:2:0 and different White Points for example) brings up more decision points that can’t be universally answered.

Thus, one more complication in the road to cinema salvation by Alternative Content. While there are many good arguments that these details are best handled by pros who have experience with permanently set-up and maintained professional tools, the reality is that many of these artists just don’t have the money (or rather, they have time that they are forced by circumstances to value at less per hour.) One recent local film festival worked with a patron who charged a flat 200€ fee for the transfers, while the Venice Film Festival transfers materials gratis (in exchange for publicity, which Qube and D2 have taken advantage of for the last two years.)

There is also a need at cinemas to create and package local commercials or theater policy trailers for insertion into the pre-show of the movies and sport and concerts that they show through their digital projection systems. This might be easily handled in larger cities where there are companies who can make economies of scale work in their favor. But spending thousands getting a DCP made will eat all the profits from a quickly shot local pizza parlor ad. New tools such as the RED Scarlet, the Canon 5D MkII, GoPro or Drift cameras and easy to use editing software make this a nice adjunct to a clever facility…only held up by the expense and ease of creating the DCP.

With this background, we spoke to Terrence, the lead programmer for the OpenDCP project. He is a cinema owner of a 7 theater cinema facility which was one of the first independent complexes in the US to go completely digital. He has had extensive experience in the computer field as well, and it was just this need for making local commercials that got him on the project. After listing some of the features of this new DCP creation system with the Graphical User Interface, we’ll ask our Three Questions.

Features

• JPEG2000 encoding from 8/12/16-bit TIFF images
• Supports all major frame rates (24,25,30,48,50,60)
• Cinema 2K and 4K
• MPEG2 MXF
• XYZ color space conversion
• MXF file creation
• SMPTE and MXF Interop
• Full 3D support
• DCP XML file creation
• SMPTE subtitles
• Linux/OSX/Windows
• Multithreaded for encoding performance
• XML Digital signatures
• GUI

One last point – Open Source does not necessarily imply free. There is a lot of nuance in just this point, but for example, the EasyDCP system of Fraunhofer also uses tools that follow Open Source standards within its structure, yet it is a highly priced (and highly valued) package. More detail can be found at: GNU, Free Software, and Open Source Software – Linux 101

Hello Terrence. For all the great and required features of the OpenDCP software, what in reality should a user expect as they dive into its use? Without knocking any other package, what advantages and disadvantages will one see when using OpenDCP?

OpenDCP: Let’s continue on the conversation about Open Source tools to illustrate some points. In the current version of the OpenDCP package we use an open source encoder named “openjpeg” that does the work of encoding from the TIFF images to JPEG2000 package. The commercial products can afford to license much faster encoders. Their highend tools might create packages at 15 frames per second (fps) while the OpenDCP packages are converted at 3fps. On long-form projects this can make a significant difference in time. Not quality, of course, and for the short commercial or under 20 minute project this would be an acceptable compromise.

Another advantage that open source projects seem to take better advantage of is the methods of communication with their users. Where commercial entities have to beware of odd statements that live forever on the internet, as well as hackers and spammers and the like, our control issues are not as great and so the OpenDCP user forum can be more open and vibrant. It fits our spirit of cooperation to point to the work of an independent expert in the digital signatures field like Wolfgang Woehl of Filmmuseum Munich whose github digital_cinema_tools social coding site is filled with practical and historical information. He, as a support board monitor, and others of his skill are able to help guide the product and test it in ways that build on the fundamentals of Open Source. People can look through the code and make certain that the standards are kept, and that we don’t do things that commercial entities are often tempted to do.

It isn’t out of the question that we could license a faster JPEG 2000 encoder. We’ve discussed ways to do this on the site – there is a yearly cost of $10,000 to meet. Maybe we could do this with a Pro version, spreading the cost over a number of users. Or maybe we can help spur the OpenJPEG programmers along…anyone out there who is a math genius that wants to help?

DCTools: That’s out of our league, but hopefully there’s someone out there who can apply their genius to the task. How did you decide to take on this OpenDCP task?

OpenDCP: The origins of OpenDCP started in Oct 2010. I had wanted to create a policy trailer for my movie theater. Unfortunately, the cost to have one converted was around $2000 and the cost of the commercial DCP software was in the $5000 range. After some research I came across some people that were attempting to create DCPs using various open source tools. They had success, but the process was a bit involved. It required a half dozen tools, some knowledge of the DCI specifications, compiling of tools. I had some programming experience, so I decided I could take what I had learned and create a tool everyone could use. The first version had a command line interface and it’s feature set grew over a few months. It simplified the process a lot, but I really wanted to add a GUI and last month I released the first GUI version of the tool.

There is certainly a lot of interest in film festivals. A couple have floated the idea of an OpenDCP Film Festival. Unfortunately, I have neither the time or knowledge to plan that sort of thing.

DCTools: There is a great deal of interest toward the inclusion of the hard of hearing and the hearing and visually impaired audience into the great culture known as “Going To The Movies”. Indie producers who I’ve spoken to point out that there are thousands of professional movies shot but only hundreds get finished. Of those, only a small percentage get distribution. So added features like closed captions, narrative tracks and even sub-titles for other markets gets put on the “If List”.

On the other hand, the US Department of Justice will be handing down their directives or rulings soon on how many open and closed caption movies should be played in the commercial cinemas, and the EU is walking toward that path with the recent inclusion of the UN Human Rights documents being used as the basis for inclusion of people’s with handicaps in the marketplace.

How does OpenDCP handle these things, and what else is on your road map?

OpenDCP: Right now, we handle one narrative track per DCP. [DCTools: Many HI/VI equipment manufacturers can switch up to 4 narrative tracks per DCP.] Thus far the typical user hasn’t been doing anything too complex in those regards. OpenDCP will create SMPTE subtitle tracks. But we’ll get there with more options. For example, the GUI currently limits you to one reel per DCP. The command line allows multiple reels and the GUI will as well, just didn’t get done for the first release.

Subtitles are probably the biggest thing people want support for. OpenDCP can handle SMPTE subtitle tracks, but it doesn’t do anything with MXF Interop/Cinecanvas. For my own personal needs, I don’t use subtitles, they are pretty rare in the U.S. However, it seems almost everyone outside the U.S. really needs that support. The problem is that the majority want the Cinecanvas because they mention that SMPTE compliant packages are still not in the field. Most cinemas think that they aren’t going to upgrade their software until InterOp stops working, which is another challenge for SMPTE in general. My issue is that I don’t really want to spend my limited development time implementing features that will be deprecated.

As different packages are usable in the field it seemed like the DCPs that OpenDCP generated wouldn’t play on different sets of equipment all the time. Some media players seemed finicky while others would accept anything. It took several weeks of trying, but it finally worked. It was good because it helped find some slight differences between the MXF Interop and SMPTE packages and flushed out some bugs in my code.

I actually wasn’t even all that aware of how closed caption support in DCPs was handled until a month or so ago. Most of the information I used building OpenDCP came from the DCI 1.2 specification and sort of reverse engineering countless DCPs I had collected from my theater. Then when somebody was having trouble getting a DCP working on the player they were using, they donated a set of SMPTE documents to the project. Reading through the various documents really helped and thats when I learned about the CC stuff.

We hope to have material at the next ISDCF Plugfest. That will hopefully give us more feedback from the professional users.

I’ve gotten feedback from people of all different skill sets that have been able to use OpenDCP to create DCPs. Some have been using it for preshow/commericals, a few are using it for archiving, and independent film makers are quite happy with the results. The current version takes a tiff image sequence and does the jpeg2000 and XYZ color conversion for the picture track. The audio track is created from 24-bit 48/96khz PCM wav files. It supports pretty much supports the entire DCI specification – 3D, 2K/4K, 24, 25, 30, 50, 60fps, digital signatures, etc.

Future features including being able to convert more image types, read directly from video files, image resizing, and simplify the process even more.

Developing OpenDCP has been a great process, first just trying to meet the needs I had as a cinema owner, then really putting my EE degree and programming skills to use. One of the neatest things has been meeting and discussing digital cinema with all kinds of people. I’ve been lucky enough to see some really excellent independent short films and learn so much along the way.

¹ GNU GPL v3

² The OpenDCP author wants to be clear that the project is still considered beta, and that the user should expect some issues depending on different factors. For example, while reading the forum this article’s author noticed that one user had difficulties with an older computer with a slow processor – changing the number of threads in the set-up let the build complete successfully. Thus, the recommendation is to start the DCP process with a small with 5-10 second clip. Get a successful workflow and then do a full conversion.