CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority under 35 U.S.C. 119(e) to U.S. Provisional Patent

Application Serial No. 61/878, 126, filed September 16, 2013, the teachings of which are incorporated herein.

TECHNICAL FIELD

This invention relates to a technique for synchronizing auxiliary content with a digital cinema composition

BACKGROUND ART

A digital cinema composition (e.g., a digital cinema movie) comprises pictures and sound. Many digital cinema compositions include closed captions, which employ the Auxiliary Content Synchronization Protocol established by the Society of Motion Picture and Television Engineers (SMPTE) of White Plains, New York. This standard, referred to as "D- Cinema Operations— Auxiliary Content Synchronization Protocol ST 430-10:2010" serves in conjunction with the companion format, "D-Cinema Operations— Auxiliary Resource Presentation List ST 430-11 :2010" to prescribe how to note available auxiliary content related to a digital cinema composition. Unfortunately, the Auxiliary Content Synchronization Protocol prescribed by the SMPTE lacks precision. This standard enables closed captions to appear more or less synchronized with the picture, plus or minus a few frames. However, this standard lacks sufficient accuracy for use with audio or motion seat controls, as examples, or more generally, continuous streams of data that require accurate synchronization, e.g. accurate within 21 uS, as is preferably the case for enhanced audio or even additional projectors.

Dolby Laboratories, Inc. of San Francisco, CA offers the Dolby Atmos® theatrical sound system that relies on a synchronization track embedded in the audio output. The protocol in this product (which has been proposed to SMPTE for standardization), uses a well- known frequency-shift keyed mechanism to represent a bit stream, with the bit stream encoding an auxiliary content identifier and a current frame. However, the bit stream does not provide any information about the content other than the content currently playing out. Thus, an auxiliary content player monitoring the signal cannot recognize the content until at least the first frame of content has already played out. Assuming a finite interval for accessing and queuing the identified content to fill the various digital signal-processing pipelines, the synchronization signal, despite offering "sample accurate synchronization," could cause a delay in the delivery of the audio until after several frames of latency.

D-Box Technologies, Inc. of Longueuil, Quebec, Canada offers the D-Box motion seat, which provides motion cues controlled by an audio signal embedded in one of the audio channels of the digital cinema content output by the digital cinema media block. This signal contains bit-accurate codes that can become corrupted if exposed to watermarking or other signal processing before being provided to the motion seat command decoder. Further, since not all exhibitors make use of the D-Box technology, inadvertent use of a D-Box-enabled digital cinema composition for playout in a non-D-Box enabled auditorium can result in delivery of the D-Box control signals over the auditorium speakers, leading to an annoyed audience and potential damage to the theater sound system.

Thus, a need exits for a digital cinema system that provides a standardized, sample- accurate, frame-aligned synchronization signal for use in conjunction with existing standards for identifying and providing the auxiliary content (e.g., SMPTE's Auxiliary Resource Presentation List) and that further allows synchronous operation of the transport of the digital cinema media block and at least one auxiliary content player. The solution should also permit more than one auxiliary content player, e.g., a motion seat and an enhanced audio system for use together, but provided by different auxiliary content players.

BRIEF SUMMARY OF THE PRESENT PRINCIPLES

A method for synchronizing a slave digital cinema playback device to a master digital cinema playback device commences by receiving at the slave digital cinema playback device a synchronization signal encoded with the current content identification, a next up-coming content identification, and signaling that precedes actions taken by the transport of the master digital cinema playback device. The slave digital cinema playback device synchronizes itself to the master digital cinema playback device based on the synchronization signal by acquiring and buffering content before required for playout. In response to the synchronization signal, the slave digital cinema playback device can provide a sample-accurate reply to frame-based commands directing auxiliary content transport (e.g., play, pause, resume, and stop).

BRIEF SUMMARY OF THE DRAWINGS

FIG 1 depicts a block diagram of an exemplary a digital cinema presentation system that includes a digital cinema master player and at digital cinema slave player for practicing the synchronization technique of the present principles;

FIG. 2A depicts a first transaction message diagram illustrating the exchange of messages between the digital cinema master player and the digital cinema slave player of FIG. 1 representing an idle state;

FIG. 2B depicts a second transaction message diagram illustrating the exchange of messages between the digital cinema master player and the digital cinema slave player of FIG. 1 representing the beginning of normal content play out;

FIG. 3 depicts a third transaction message diagram illustrating the exchange of messages between the digital cinema master player and the digital cinema slave player of FIG. 1 showing a transition between consecutive pieces of auxiliary content;

FIG. 4A depicts a fourth transaction message diagram illustrating the exchange of messages between the digital cinema master player and the digital cinema slave player of FIG. 1 showing playout stopping,

FIG. 4B depicts a fifth transaction message diagram illustrating the exchange of messages between the digital cinema master player and the digital cinema slave player of FIG. 1 showing playout resuming;

FIG. 4C depicts a sixth transaction message diagram illustrating the exchange of messages between the digital cinema master player and the digital cinema slave player of FIG. 1 showing playout ending and optionally returning to idle;

FIG. 5 shows a state transition diagram for the transport for the master digital cinema player of FIG. 1 ;

FIG. 6 shows a state transition diagram for the transport of one of the auxiliary players of FIG. 1 ;

FIG. 7A-D depict, in flowchart form, exemplary processes for auxiliary content enhanced playout, transition, stopping, and resumption, respectively, performed by the digital cinema master player of FIG. 1 ; FIG. 8A-8D depict, in flowchart form, exemplary processes for auxiliary content enhanced playout, transition, stopping, and resumption, respectively, performed by the digital cinema slave player of FIG. 1, each operation performed parallel with a corresponding one of processes depicted in FIGS. 7A-D, respectively;

FIG. 9A depicts an exemplary synchronization packet in connection with the synchronization technique of the present principles;

FIG. 9B depicts a table of parameters and values corresponding to fields of the synchronization packet in FIG. 9A;

FIG. 9C depicts a second exemplary synchronization packet in connection with the synchronization technique of the present principles

FIG. 9D depicts a table of parameters and values corresponding to fields of the synchronization packet in FIG. 9C;

FIG. 10 depicts an exemplary sequence of transactions between the digital cinema master player and the auxiliary content slave player of FIG. 1 in correspondence with a sequence of motion picture frames having a constant frame rate of 24 frames per second;

FIG. 1 1 depicts an exemplary sequence of transactions between the digital cinema master player and the auxiliary content slave player of FIG. 1 in correspondence to a sequence of motion picture frames having a constant frame rate of 48 frames per second; and,

FIG. 12 depicts an exemplary sequence of transactions between the digital cinema master player and the auxiliary content slave player of FIG. 1 in correspondence to a sequence of motion picture frames having varying frame rates.

DETAILED DESCRIPTION FIG. 1 depicts a block diagram of an auxiliary content-enabled digital cinema presentation system 100 that comprises a digital cinema master player 1 10, a digital cinema projector 120, an audio output system 130, a digital cinema slave player 150, and an auxiliary output system 160 driven by the slave player. By way of illustration and not limitation, the auxiliary output system 160 could comprise a motion seat-enhanced audio system, or some other synchronized content performance system, e.g., automated lighting controller, audio- animatronic robotics, etc. The master player 1 10 and slave player 150 typically each include a general-purpose computer and associated hardware, including, but not limited to, network communications devices. Typically, each of the master and slave players can comprise a server, as well known in the art. The master player 110 includes storage mechanisms 1 15 and 116 for storing data and/or files. The slave player 150 includes storage mechanisms 155 and 156, as well as registers 153, 154, 157, and 158. Special purpose hardware is provided in the master player 1 10 and slave player 150, for example in the master player well known special purpose hardware is provided for driving a picture signal connection 1 12, one or more audio outputs 113, and communications connection 11 1. In the slave player, special purpose hardware is provided for driving communications connection 151 (well known), for driving an auxiliary content signal output 152, and for accepting a synchronization signal 1 14.

Information represented in the synchronization signal 114 is used to set registers 153, 154, 157, 158, as described below. The setting of those registers is used to control the driving the auxiliary content signal output 152, also as described below.

A communication channel 140 provides communications between the master player 110 and the projector 120 via communications connections 11 1 and 121, respectively, and between the master player 1 10 and the slave player 150, via communications connections 11 1 and 151 respectively. The communications channel 140 can comprise a network, for example an Ethernet network, or in the alternative, the channel could comprise multiple independent connections between the master player 110 and the other devices (such as via the Internet). In addition, one or more presentation devices, e.g., a closed caption player and display(s) (none shown) could also communicate with the master player 110.

The master player 1 10 has multiple audio outputs 1 13, many of which connect to an audio output system 130, which typically comprises one or more amplifiers and one or more speakers (not shown). At least one channel of the audio outputs 1 13 carries a synchronization signal 1 14 provided to the one or more slave player 150 in accordance with the present principles. The synchronization signal 114 signals the slave player 150 which piece of content to play and when to do so. Using one of the audio outputs 1 13 as the synchronization signal 1 14 takes advantage of the requirement that the master digital cinema player 110 must provide digital audio outputs signals that comply with the AES3 (Audio Engineering Society) standard (also known as AES/EBU), which parallels part 4 of the international standard IEC 60958. Those familiar with the standard will recognize that an AES output signal carries a pair of audio channels. Receipt of a Preamble X or Z identifies the start of the left channel of the pair and that Preamble Y identifies the start of the right channel of the pair. Detecting the start of either the left or right channel in conjunction with historic audio data can serve to determine timing with sample accuracy (e.g., following receipt of an encoded sequence, the next appropriate preamble represents the beginning of the next encoded sequence with sample accuracy). This assures substantially more reliability than using the communications channel 140, usually implemented as an Ethernet network. Such networks rely on packets and remain subject to "best effort" delivery, which may result in buffering or other variable latencies that disrupt accurate timing.

The master player 1 10 and the slave player 150 can exchange presentation information such as a SMPTE Auxiliary Resource Presentation List, for example using the SMTPE Auxiliary Content Synchronization Protocol. The slave player 150 can acquire auxiliary content (e.g., content files A2 and B2 stored in the storage mechanisms 115 and 116, respectively) from the master player 110 based on the Auxiliary Content Synchronization Protocol as prescribed by SMPTE. Alternatively, the slave player 150 can load auxiliary content (e.g., the content files A2 and B2) directly in response to instructions directing the slave player to ingest content from a designated source (not shown). Further, the slave player 150 can receive such content following operator insertion of a content-carrying drive (e.g., a removable drive, not shown, containing the content files A2 and B2 for storage in the storage mechanisms 155 and 156, respectively). Additional^ an external controller (not shown) could write the content files A2 and B2 to an internal drive (not shown), for example by the slave player 150 running a File Transfer Protocol 'FTP' service to allow the external controller to write these files from the internal drive.

The master player 1 10 has a Show Play List (SPL) 1 17 that specifies which pieces of content to play and in what sequence. In the present examples, a digital cinema presentation will consist of a first digital cinema composition A followed immediately by a second digital cinema composition B, as shown in SPL 117. The master player 110 stores the pictures and audio corresponding to the two compositions A and B as resource track file Al, typically stored in the storage mechanism 1 15, and resource track file Bl typically stored in the storage mechanism 1 16, respectively. For example, the resource track file for composition A typically includes at least one picture track file and at least one audio track file, which together represent the resource track file Al in FIG. 1 although in practice, the picture track file and audio track file could exist as separate entities. A Composition Play List (CPL) (not shown) designates which resource track files correspond to a particular digital cinema composition and further designates the synchronized start points within the various files and the duration of the corresponding content. Such composition playlists and resource track files constitute well-known objects easily implemented as described by the corresponding digital cinema standards published by SMPTE (e.g., "D-Cinema Packaging - Composition Playlist ST 429-7:2006" and "D-Cinema Packaging - Sound and Picture Track File ST 429-3 :2007").

The slave player 150 has auxiliary content track files A2 and, B2 each comprising at least a portion of the corresponding digital compositions A and B, respectively. The auxiliary content file A2 and B2, stored in storage mechanisms 155 and 156, respectively, comprise either complete versions of the auxiliary content or only a portion thereof for situations where the auxiliary content gets streamed from another source (e.g., from the master player 1 10 via connection 140), as needed.

The auxiliary content tracks can exist in a proprietary format or in a standard format such as in accordance with SMPTE's track files (e.g., "D-Cinema Packaging - Sound and Picture Track File ST 429-3 :2007"). Further, the auxiliary content could exist in another standardized track capable of being referenced by a SMPTE composition playlist (CPL), which may include anticipated extensions. The SMPTE composition playlist standard incorporates certain features to allow future extensions, which in turn, could allow reference to new resource track file types and corresponding synchronizations. For example, the currently proposed SMPTE draft standard ST429-14 Auxiliary Data Track File contains corresponding extensions to the digital cinema playlist ST429-15 Auxiliary Data Composition Asset.

Each asset track bears a unique identifier, typically a Universally Unique Identifier (UUID) 128 bits long and well known in the art. The playlist can identify each component asset using this unique identifier. Thus, when the master player 110 plays out (or prepares to playout) the digital cinema composition A, the master player can identify this digital cinema composition A to the slave player 150 by sending the unique identifier for A2 (obtained from the composition playlist) as part of the synchronization signal 114 sent to the slave player 150. In an alternative embodiment, the communications channel 140 could send the identification of the digital cinema composition A2.

In an alternative version of either of these embodiments, the slave player 150 could have a copy of at least a portion of the composition A (not shown), wherein the master player 110 will indicate that it will commence playout of composition A (e.g., as part of the synchronization signal 1 14 sent on the communication channel 140). In response, the slave player 150 would determine from the composition playlist A (or portion thereof) that this would require playout of the content file A2. In still another alternative embodiment, the master player 1 10 and slave player 150 can both make use of the SMPTE's Auxiliary Content Synchronization Protocol by which the slave player 150 will receive, via communication channel 140, an Auxiliary Resource Presentation List (not shown) which identifies asset track file A2 and further provides the necessary synchronization information necessary to subsequently synchronize playout based on the signal 114.

As discussed above, the slave player 150 has two registers 153 and 154 (sometimes referred to herein as "slots"), each able to store the identity of an auxiliary asset track file. The ability of each register to store the identity of an asset track file has importance. One register (e.g., register 153) will initially store a content identifier (e.g., represented herein as "A2") because the content file A2 will soon become needed for playout in synchronization with the actions of the master player 110. Once the associated content file A2 starts to playout, the second register 154 can receive the identity of the next auxiliary asset track file needed (e.g., here, content file "B2") so that the slave player 150 can undertake the preparations necessary to have the next content available for playout when so commanded by the synchronization signal 1 14. Thus, when playing, one slot (e.g., the register 153) contains the current asset track identifier while the other slot (e.g., the register 154) might initially contain nothing, but eventually will contain the identifier for the next asset track file to undergo playout immediately following the current one.

The register 158 has a flag indicating which of the two registers 153 and 154 currently serves to identify the asset track file played by the slave player 150. For example, if the transport currently plays content A2 or the slave player remains stopped, but ready to play content A2, then register 158 will indicate the appropriate register, in this case register 153, as being current register (slot). Note that the term "transport" refers to the logical (or "virtual") transport representing the digital media analog to the mechanical magnetic tape or film transport used for tape-recorded or film-handling systems (e.g., cameras, optical printers, projectors). This use of this term remains well known, but to be unambiguous, a specific definition bears mention here.

The register 157 maintains the state of the slave player 150 transport, which can comprise one of the states" STOPPED, CURRENT_CONTENT_QUEUED, PLAYING, NEXT_CONTENT_QUEUED, and WILL_STOP. The details of the interaction between current register flag 158 and slave transport state 157 appear below, particularly in conjunction with FIG. 6. The master player 1 10 has related transport states, some of which -Clare reflected by the slave state 157. These states comprise STOPPED, WILL_PLAY, PLAYING, WILL_STOP, as discussed in more detail below, especially in conjunction with FIG. 5. The transactions sent from the master player 1 10 to the slave player 150 over at least the synchronization signal 1 14 serve to coordinate the states of the master and slave players to maintain sample accurate synchronization in their respective transport states.

There exist several conditions pertinent to the present principles in the auxiliary content-enabled digital cinema presentation system 100, shown in connection with the corresponding exemplary transactions in FIGS. 2A, 2B, 3, 4A, 4B, and 4C. In each of these figures, the master player 1 10 and slave player 150 appear only once each with the timelines 201 and 202 running vertically, with time advancing down in the figure, with simultaneous moments (not explicitly shown) appearing horizontally opposite from each other,

perpendicular to the timelines. The breaks in the timelines 201 and 202 (shown by wavy lines cutting each of the timelines and ellipses following the last transactions) represent an arbitrary passage of time wherein the condition remains the same and wherein the subsequent omitted transactions (i.e., those not shown) remain identical to the most recent transaction, or follow the pattern of the previous two or three transactions, as in those conditions where a frame counter continues to increment.

FIG. 2A depicts an interaction 200 comprising a set of transactions associated with the system 100 residing in an "idle" phase 210, which means that the transport for the slave player 150 has no content (i.e., no asset) ready to play, and there exists no imminent command to start playing. The idle transactions 211 and 212 (both identical) associated with the idle phase 210 indicate that the auxiliary transport has entered the STOPPED state, but otherwise these transactions remain essentially devoid of specific information: No need exists to specify the slot represented in the transaction. Further, no need exists to specify the identifier (e.g., UUID) of the auxiliary asset associated with the slot (or the slot may be cleared) and there exists no designated frame count. These transactions signify that the slave player 150 has essentially nothing to do. The slave player 150 need not ready any content or play anything.

Idle transactions 211 and 212 remain optional. Embodiments that consider them may interpret the absence of a signal as the equivalent to an idle transaction. One action that may optionally occur upon receipt of an idle transaction (e.g., idle Transaction 211) by the slave player 150 is release of that any resources (e.g., buffers, caches, streams, etc.) previously held ready, as may be the case when the previously playout has just finished. Some embodiments may choose to retain such resources, in case of receipt of a subsequent rewind or a restart command, or when there exists any implementation-specific optimizations that might make an implicit release less desirable.

Some embodiments may interpret a loss of signal, e.g., a failure of the synchronization signal 114, as indicating an "idle" condition. Thus, if the audio output cable carrying the synchronization signal 1 14 becomes severed or if the audio content of the connection does not represent a valid bitstream (e.g., as with silence), then the playout of auxiliary content, if ongoing from slave player 150, would immediately stop, or might stop after a predetermined interval with no intervening valid transactions received (this latter policy make the connection somewhat more resilient with respect to noise).

FIG. 2B shows an interaction 220 during which initial playout begins. This interaction has two phases, a preparation phase 230, followed by a normal playout phase 240. The master player 1 10 can initiate the preparation phase upon receipt of a "load show" command 231. This may represent an immediate command received through a user interface (not shown) of the master player 1 10 either directly or remotely, or may result from an automatic playout command, e.g., when the scheduled playout of a particular show playlist coincides with the current time.

As a consequence, the master player 1 10 issues a preparation transaction 232, still commanding that the auxiliary transport state remain STOPPED. Now, the master player 1 10 gives notice of the need for a new asset soon. This notice comprises three items. First, the preparation transaction 232 specifies a slot (here, slot "A" corresponding to register 153). Second, the preparation transaction 232 specifies an asset track file identity (here, the identifier comprises "AAA" corresponding to auxiliary asset track file "A2" but in different implementations, could comprise the identifier "A2", "A", or the identifier for the Auxiliary Resource Presentation List as discussed above). Third, the preparation transaction 232 specifies a specific start frame within the asset track file, designated here as "AAA_START". Generally, an integer can represent the start frame, with the integer identifying a particular frame, typically at or near the beginning of the designated auxiliary asset track file. The preparation transaction 232 provides sufficient information for the slave player 150 to acquire, queue, and ready the asset file "A2" stored in the storage mechanism 155 of FIG. 1 as needed by the particular architecture and latencies of the slave player 150. During the preparation transaction 232, the filling of buffers and the priming of initial signal processing pipelines (as applicable) can occur as well as other activities needed to make the transport for slave player 150 ready to play asset track file A2. The preparation transaction 232 can repeat indefinitely, i.e., the transaction can be idempotent. Subsequently, the master player 110 receives a start event 241, for example, an operator has now pressed a PLAY button (not shown), or the current time now matches a previously scheduled start time, or a predetermined amount of time after the load show event 231 has elapsed, or the master player 110 has received a "ready" signal from at least one other device, e.g., the slave player 150, or the projector 120. In some cases, the PLAY button may become enabled by at least one of these or other events. Preferably, the system 100 has a configuration that ensures for any of these conditions, the slave player 150 has sufficient time to ready the content requested called for immediate play out (e.g., A2 in preparation transaction 232)

In response to the start event 241, the master player 110 sends the "will-play" transaction 242 with the transport state command WILL_PLAY_A, thereby signaling that play out shall begin concurrently with the start of the next frame interval. This gives the transport of the slave player 150 the ability to predict when play out becomes necessary. In this example, though not strictly necessary, the will-play transaction reiterates that slot A (i.e., register 153) remains associated with the asset track file identity "AAA" and that the position within that file corresponds to the frame identified as "AAA_START", each as previously noticed by the preparation transaction 232. While no requirement exists for this

recapitulation, in this example there does not exist any other information worth providing since there currently exists no pertinent information corresponding to slot B (register 154).

The will-play transaction 242 marks the end of preparation phase 230, immediately followed by the normal play out phase 240. At the start of the next frame interval, the normal play out phase 240 begins and the transport of slave player 150 starts to playing asset A2 stored in the storage mechanism 155, as noticed by the preparation and will-play transactions 232 and 242 in the preparation phase 230.

During the normal playout phase 240, the playout transactions 243 and 244 occur periodically. In some embodiments, this period depends on the data rate, i.e., transactions occur provided as quickly as possible, but at a rate of one or more transactions per frame at low frame rates, but one transaction per several frames at higher frame rates. In other embodiments, the data rate may be fast enough so that one-per-frame transactions can occur easily, perhaps even requiring padding to fill in the data stream. A more detailed discussion of the transaction rate appears below in conjunction with FIGS. 9-12. In some embodiments, complete receipt of the first play out transaction 243 may not occur until the current frame completes play out, or even later at higher frame rates. Receipt of any part of the first play out transaction can be used to indicate that the transport of the slave player 150 should reside in the state PLAYING_A, that is, play out of the asset associated (e.g. A2) with slot A (register 153) occurs from the storage mechanism 155. The first playing transaction 242 indicates that the previously designated starting frame

"AAA_START" now constitutes the current frame. As long as the normal playout phase 240 continues, successive transactions will indicate incrementing frames, e.g., "AAA_START+1" in the playing transaction 243.

In the case where the slave player 150 connects to the master player 1 10 with a presentation already in progress, the information contained within the playing transactions 243 and 244 will receive the same treatment as the transactions in the preparation phase 230. If the slave player 150 has no correct auxiliary content at the ready, the playing messages receive the same treatment as the preparation transaction 232 until such time as content becomes ready, and until then, the transport status "PLAYING_A" called for in the transaction receives the same treatment as "STOPPED". Once the auxiliary content becomes ready and the transport is prepared, the transport reacts to the next playing transaction received as if it were a will-play transaction (e.g., transaction 242). In other words, the transport status "PLAYING_A" receives the same treatment as "WILL_PLAY_A" and with the recognition that the frame count will need increment with respect to the frame count.

Thus, if the current transaction indicates PLAYING_A and frame = AAA+n, then the current transaction is treated as if indicating WILL_PLAY_A with frame = AAA+n+1. Playout by the slave player 150 will begin at frame AAA+n+1 and will be synchronous with the corresponding frame being played by master player 110. This mechanism allows the slave player 150 to catch up and synchronize even with missed preparation and will-play transactions, after which subsequent playing transactions receive normal handling.

In some embodiments, (as exemplified by the embodiments discussed below in conjunction with FIGS. 9-12), transactions may be atomic, as represented here, but in other embodiments, transactions may be spread out and/or interleaved and/or multiplexed. For example, the 128 bits of a UUID used in a show ID might appear over multiple messages, and until receipt of a complete set of messages, the show ID remains uncertain. In some cases, receipt of multiple messages corresponding to a single transaction can occur within a single frame interval, and all of these messages might indicate the same frame (e.g., even though the transport continues to run). If the message rate exceeds the frame rate, then more than one message can indicate that the frame = "AAA_START+1"). In embodiments where a transaction takes longer to communicate than a single frame interval (e.g., if four messages become needed to communicate a transaction, but the message rate comprises one or two messages per frame), then the frame value may update more frequently than the rest of the transaction. For example, it may take four messages, at one message per frame, to provide a new show ID (e.g., "AAA"), but the frame value and transport state can undergo updating within each of those four messages.

Thus, if the transaction 244 comprises four individual messages (not shown in FIG. 2B), and in that embodiment, the synchronization signal 114 can accommodate four messages per frame at the frame rate of composition "A", then there will exist four messages each indicating "frame = AAA_START+1", whereas if each frame accommodates one message, then each consecutive message would indicate an incremented frame count (not shown in FIG. 2B, but see discussion regarding FIGS. 9B and 9D).

FIG. 3 illustrates an interaction 300 in which a transition from play out of the auxiliary asset identified by AAA (e.g., A2) concludes, immediately followed by playout of the auxiliary asset identified by BBB (e.g., B2). The playing transaction 311 appears as ending the normal playout phase 310. The playing, transaction 31 1 indicates a current frame value "AAA_END-n", comprising a frame count whose value in this illustration represent n frames before the last frame to be played of the auxiliary asset identified by AAA.

The Asset transition phase 320 begins with the "preparation-while-playing" transaction 321, in which the state of the transport of the slave player 150 is still

PLAYING_A, but slot B now becomes loaded with an identifier (e.g., a UUID) corresponding to the next auxiliary asset to undergo playout. In this example, the identifier comprises BBB and the starting frame within that auxiliary asset corresponds to BBB_START, analogous to the preparation transaction 232, except that the transport is running. As with preparation transaction 232, the preparation-while-playing transaction 321 may be idempotent and may repeat an arbitrary number of times during the asset transition phase 320.

Interspersed among the repeated preparation-while-playing transactions 321 may be still-playing transactions 322, which may reassert the identity of the currently playing asset (e.g., AAA), and which provides the current frame count for playback of the currently playing asset. Assuming an embodiment in which one transaction exists per frame in FIG. 3, then the transaction 322 occurs two frames later than playing transaction 311, and appear with a frame count incremented by two, i.e., AAA_END-n+2.

The last transaction in asset transition phase 320 comprises a will-play transaction 323 A or 323B for the next asset, either variant of which may be used. Each of the will-play transactions 323 A and 323B indicates that the transport of the slave player 150 should be

WILL_PLAY_B, meaning that after the end of the playing the current frame (i.e., AAA_END of asset A2), the previously designated frame BBB_START of the previously designated asset B2 should commence play out. Since the slave player 150 is already aware of the asset and frame numbers corresponding to both of the slots A and B (registers 153 and 154, respectively), the remainder of either transaction 323A or 323B is consistent with prior messaging.

After receipt of the last transaction (i.e., transactions 323 A or 323B) of asset transition phase, the transport of slave player 150 begins to output the asset B2 in synchronism with the output by master player 110 of asset B l. The normal play out phase 330 begins, during which master controller 1 10 issues playing transactions 331 and 332 ,which are analogous to playing transactions 243 and 244, but directed toward asset B2. Note that no requirement exists that the frame rates of assets A2 and B2 be the same.

FIG. 4A shows a pause interaction 400 wherein a normal playout phase 410 comprising a final playing transaction 411 precedes a stopping phase 420 triggered by a pause event 421 that produces a will-stop transaction 422 which warns the transport of the slave player 150 to stop, beginning with the next frame. The transport status now becomes set to WILL STOP. During the following frame (BBB STOP), the transport of the slave player 150 halts, such that frame BBB STOP is the last one presented.

In subsequent frame intervals while the transport remains stopped, and depending on the nature of the auxiliary asset, the transport may repeat the last frame or last values, or present default values. The stopped transaction 423 provides consistent interval timing between the master and slave players 110 and 150. The stopped transaction 423 is idempotent and can repeat indefinitely.

For example, if the slave player 150 connects to the auxiliary output system 160 as a picture output device, the slave player 150 can provide a freeze frame of BBB STOP, or may present black (depending on a predetermined preference or design decision). If the slave player 150 drives an enhanced audio system (not shown), the output should be silence, although if the slave player includes signal processing that provides, for example, protection against clicks and pops, or reverberation effects, a non-silent audio output may continue upon a corresponding normal decay curve. (Alternatively, the auxiliary output system 160 can provide such signal processing.) If the slave player 150 drives a motion seat, or an audio- animatronic figure (not shown), a discontinuity in motion commands might introduce too great an impulse, in which case the slave player 150 may provide low-pass filtering that allows the mechanism to return to a home, neutral, or otherwise static position, but without a first order (or perhaps even second order) commanded position discontinuity. Again, the auxiliary output system 160 may provide these protections.

The resume playout interaction 430 appears in FIG. 4B, where a resume event 441 initiates the resume-play out phase 440. A will-play transaction 442 follows the resume event 441. The will-play transaction 442 is analogous to other will-play transactions (e.g., transactions 242, 323A, and 323B), except that the frame that will undergo playout comprises the next frame (BBB_STOP+l) following the one on which the transport stopped. After resume phase 440, the system 100 of FIG. 1 enters the normal playout phase 445, comprising the first playing transaction 443 (analogous to first playing transactions 243 and 331).

The interaction 450 in FIG. 4C illustrates an end playout phase 460 triggered by a stop event 451, which most typically occurs when reaching the penultimate frame of the asset currently being played with no subsequent asset in the show playlist 1 17. In the alternative, the event could constitute a button press. The will-stop transaction 461 is similar to will-stop transaction 422, but because the playout has ended, there may or may not be a stopped transaction like transaction 423. There can be one, but one is not required. If the next transaction comprises an idle transaction 471, then that is fine: It shows the transport stopped, but any update to slot values (e.g., frame position or asset ID) is meaningless once playout has ended, since there is no need for verification of the transport status. Thus, while the transaction subsequent to will-stop transaction 461 could take the form of stopped transaction 423 (but identifying frame = BBB END, that is, the frame after that indicated in the will-stop transaction 461). The transaction could also take the form of idle transaction 471, or be absent altogether (as indicated by the optional nature of stopped transaction 471 being shown by a dotted line).

Having an actual idle transaction in the form of transaction 471, which can be idempotent, advantageously provides an explicit signal to slave player 150, if not otherwise available, that the show playlist 1 17 has concluded. The idle transaction remains unnecessary if the slave player 150 can detect the end of show playlist 117 by other means. For example, the slave player can detect an end of show playlist if the provided show "BBB" associated with asset B2 comprised an Auxiliary Resource Presentation List that spanned the interval of the entire show playlist 117 and had been acquired by slave player 150 earlier during preparation phase 230, or if the transport state commanded in transaction 461 explicitly comprised a "WILL_END" transaction (not shown) rather than "WILL_STOP".

The transport state commands such as "WILL_PLAY", "WILL_STOP",

"WILL END" and the like, comprise examples that illustrate the command taking effect in the following frame. Other embodiments could use a different predetermined frame increment, for example, an initial will-play command could appear four frames in advance, with the subsequent will-play transactions related to the same asset start, which may comprise consecutive transactions, or be interspersed with the playing transactions related to the current content counting down (not shown) to the corresponding first play transaction.

FIG. 5 shows a master player 110 transport state diagram 500 and FIG. 6 shows a corresponding slave player 150 transport state diagram 600, suitable for operating in the auxiliary content enabled digital cinema system 100. From the initial STOPPED state 510 in which the master transport (i.e., the transport of the master player 1 10) remains STOPPED, each successive frame interval would provide at least a portion of a corresponding transaction specifying the next slave transport state command to the slave transport (i.e., the transport of the slave player 150).

If the master transport remains stopped, the next slave transport state command 51 1 keeps the designation "STOPPED." If the content is loaded, the slave player 150 receives the details before being needed, as discussed above, such as during the preparation transaction 242 (which specifies the transport remain stopped). The remainder of this discussion presumes that the slave player 150 has received notification on the needed asset(s), and has had the opportunity to acquire and ready them, and if not, that the slave player 150 will at least have the opportunity to catch up.

The primary state sequence commences at time 512 upon receipt of a play event (e.g., event 241) by the master player 110, perhaps asynchronously. The master transport transitions to the WILL PLAY state 520. The next transaction message (or the next transaction, depending upon the embodiment) provides the slave transport state command

"WILL_PLAY" (e.g., as in will play transaction 242). The primary sequence also determines and indicates which content will play next. After sending the WILL_PLAY slave transport state command at 523, the master transport enters the PLAYING state 530. In the next frame interval, the master player 110 will play the appropriate frame of the master asset (e.g., the asset Al stored in storage mechanism 1 15). With each frame played after entering PLAYING state 530, including the first one, the slave transport status command PLAYING issues, as indicated by transition 531 in FIG. 5 and as seen in playing transactions 243, 244 in FIG. 2B and 31 1 in FIG. 3.

When the end of the master asset in a playlist becomes imminent, for example when the master transport starts to play the last frame AAA_END of asset Al stored in storage mechanism 1 15 and the show play list 117 now specifies a subsequent master asset Bl stored in storage mechanism 1 16, then the next message contains the slave transport status command WILL_SWITCH as shown at in transition 532 of FIG. 5, which commands the slave transport to play the other content (as illustrated in the will-play transaction 323 A and 323B of FIG. 3 as WILL_PLAY_B, since the previous state was PLAYING_A). This signals the slave transport 150 to change assets and play on after the current frame. The state of the master transport remains at PLAYING 530. Later, when the end of the last master asset in a playlist becomes imminent, for example, when the master transport starts to play the last frame BBB_END of asset Bl, or if asynchronously a stop button (not shown), commanding the master transport becomes pressed, then the master transport transitions at 534 and enters the WILL STOP state 540.

Concurrent with the next frame, the penultimate one, the corresponding next message contains the slave transport status command WILL_STOP as shown at transition 541, which commands the slave transport to stop after the current frame (as shown in the stop transaction 422 and 461. The state of the master transport transitions to STOPPED 510 and the last frame of the current asset is played. While in the state 510, if the current asset has concluded, then the slave transport status command STOPPED 511 may reside in one of the idle transactions (e.g., idle transactions 211, 212, and 471 of FIG. 2A), or if the master transport remains merely paused, then in stopped transaction 423).

In the unlikely coincidence that the last frame of a non-terminal asset (e.g., asset Al being non-terminal in show playlist 117 as it is followed by asset B l) becomes imminent during the same interval during receipt of a stop command (e.g., STOP button press), then the stop command takes precedence and the transition 534 occurs. The master transport now signals WILL_STOP during transition 541 as the last frame of the current asset (e.g., Al) plays after which the master transport stops in STOPPED state 510. Later, upon an asynchronous unpause command (like command 441, typically a button press), the transition 515 occurs. This transition puts the master transport in the WILL SWITCH state 550 so that with the next transaction 553 sent during the next frame interval (even though the both transports remain paused), the slave transport 150 receives a WILL_S WITCH status. Thus, the slave transport now knows (or will receive confirmation) that the next frame will come from the different asset (e.g., B2), much as with the transaction 323B, but where the slave transport would not have been currently running and playing asset A2.

The slave transport state diagram 600 of FIG. 6 begins with an initial STOPPED state 610 and the slave transport remains in that state while optionally receiving idle messages (e.g., the idle messages 211 and 212 of FIG. 2A), which would indicate that the slave transport should be stopped, or as preparation transaction 232 is being received, or while paused by stopped transaction 423, as shown at transition 61 1. The remainder of this discussion presumes that the slave transport 150 has received a preparation transaction (e.g., transaction 232) and the corresponding auxiliary asset has been acquired, queued, and is otherwise ready to play.

Upon receiving at least a portion of a transaction (e.g. a message) that indicates the slave transport status command WILL_PLAY (as with transaction 242), the slave transport takes transition 612 enter the CURRENT CONTENT QUEUED state 620, based on the slot indicated by the WILL_PLAY status command, as with the WILL_PLAY_A status signaled in transaction 242, (or by an equivalent indication, if for instance a particular slot is inferred as a default). Upon the start of the next frame interval (e.g., at the first sample received at the start of the next message), the slave transport initiates transition 623, enters PLAYING state 630, and begins playing the queued frame of the designated auxiliary asset (e.g. A2). Note that the master transport now resides in the WILL PLAY state 520 and transitions during the transition 523 to the PLAYING state 530 nearly a full frame in advance of the slave transport which transitioned from the STOPPED state 610 upon receipt of the WILL PLAY message sent during transition 523 to the CURRENT CONTENT QUEUED state 620. In this state, the current content begins playing at the start of the next message at transition 623 coincident with the start of the next frame interval, resulting in the PLAYING state 630. However, as the master transport 1 10 starts to play asset Al at the start of the frame interval after having achieved the PLAYING state 530 and the slave transport 150 starts to play corresponding asset A2 at the start of the frame interval following the WILL_PLAY message at transition 612, the two assets Al and A2 play together, in accurate synchronization. With each received transaction having a slave transport status command PLAYING (e.g., transactions 243, 244, 31 1, 321, and 322), the state of the slave transport loops at the transition 633 back to the playing state 630. If the master player 1 10 sends a WILL SWITCH slave transport status command, as represented by WILL_PLAY_B in the will-play transactions 323A and 323B (where the previous current content was A), then the slave transport enters the NEXT CONTENT QUEUED state 640, via WILL_SWITCH transition 634, as an indication the next asset is set to play. At the start of the next frame interval (coincident with the start of the next message received) at the transition 643, the slave transport returns to the PLAYING state 630, but now plays the next asset (e.g., B2) during the normal playout phase 330. Upon receipt of the WILL STOP slave transport control status command inducing transition 635, the slave transport will enter the WILL STOP state 650 and with the start of the next frame (which does get played) during the transition 651, the slave transport will enter the STOPPED state 610. Both the master and slave transports will have played an identical number of frames, with a synchronization accuracy established by the synchronization signal 1 14.

FIGS. 7A-7D show various playout processes performed by the master player 1 10, while FIGS. 8A-8D show corresponding playout processes performed by the slave player 150. Each master player process appears opposite the corresponding slave player process. Thus, FIGS. 7A and 8A depict the respective initial playout processes 710 and 810 performed by the master and slave players 110 and 150, respectively, to begin playout of a composition having auxiliary assets for presentation by the slave player 150 in synchronization with the main assets presented by the master player 110.

The Master and slave initial playout processes 710 and 810 begin at steps 711 and 81 1, respectively, during which each device idles in the "transport stopped" states 510 and 610, respectively. During step 712, the master player 1 10 of FIG. 1 loads a first piece of content (the main assets of a first composition, e.g., asset A 1 of composition A) as the next main content. Typically, this occurs in response to a previously defined playlist scheduled to play at a time that is approaching, but in other cases, this occurs as a result of one or more manually entered commands from an operator, e.g., a command to load a particular movie. Either case constitutes an example of a load show event 231.

During step 713, the master player 1 10 indicates to the slave player 150 the second piece of content (the auxiliary assets of the first composition). The indication from the master player to the slave player may occur during the preparation transaction 232. This transaction may occur through the communication channel 140, or via the synchronization signal 1 14, since this indication can have a relatively relaxed timing requirement, e.g., a few frames, or about a second, or perhaps longer, depending on the architecture of the system and the implementation details of the specific components. The slave player 150 receives this indication during step 812, which, in response, triggers the slave player to load the second content (the auxiliary assets of the first composition, e.g., asset A2 of composition A) as the next auxiliary content during step 813. .

During step 714, the master player 110 receives a play command 241, whether as a scheduled event or as a consequence of an asynchronous (e.g., manual) button press, which triggers the transition 512 by the transport of the master player to enter the master transport WILL PLAY state 520. During the next frame interval at step 715, the master transport indicates to the slave player via a synchronization signal transaction 242, which results in the master transport transition 523 entering the PLAYING state 530. The receipt of that indication during step 814 by the slave player 150 produces the slave transport transition 612 to the CURRENT CONTENT QUEUED state 620.

Upon the start of the next frame interval during step 716, the main transport begins playout of the current main asset (e.g., asset Al). Synchronously, as the start of the next frame interval is anticipated on the basis of previous frame intervals by the slave player at step 815, the slave transport makes the transition 623 to the slave transport PLAYING state 630 and begins playout of the current auxiliary asset (e.g., asset A2) corresponding to the current main asset (Al). Thus, the playout of the main and auxiliary content begins on the master and slave player in synchronization. This synchronization can be accurate to within a single-bit sample from the digital audio connection providing the synchronization signal 1 14.

During step 717, the master transport continues to playout subsequent frames of the current main asset, repeatedly taking the transition 531 to return to the master transport

PLAYING state 530 and generate playing transactions (e.g., transactions 243 and 244) as it does so. For its part, during step 816 the slave transport receives these transactions, triggering looping transition 633 and remaining in the slave transport PLAYING state 630.

In the case when the slave player 150 is not ready when master player 1 10 starts playout, these repeated playing transactions from step 717 of the master playout process 710 can serve as proxies for the preparation and will-play transactions 232 and 242. Thus, the transport of the slave player 150, in response to receiving a proxy preparation transaction at 812 can load the designated asset. Thereafter, upon receiving a proxy will-play transaction during step 814, the slave transport takes the transition 612 to the QUEUED state 620. Upon entering the next frame interval, the slave transport takes the state transition 623 to the slave transport PLAYING state 630. During step 815, the play out begins, synchronized with output of the master transport 110.

The initial playout processes 710 and 810 continue indefinitely during steps 717 and

816, respectively, until some other transport processes occur (as discussed below), in which case they conclude at steps 718 and 817, respectively.

FIGS. 7B and 8B show corresponding master and slave transport transition processes 720 and 820, respectively, that switch from a currently playing portion of some composition to another. Step 721 triggers the master transport transition process 720, while a first portion of a first composition undergoes playout (e.g., while step 717 continues to iterate) or earlier, where another discontinuous portion of the same or different composition will be required eventually, which may be soon. In preparation for the impending transition, the master player 110 loads the third content (e.g., main asset B l of second composition B) during step 722 and sends an indication, e.g., the preparation transaction 321 of FIG. 3, to the slave player 150. Steps 721 -722 do not affect the state of the master transport, which typically remains in the master transport PLAYING state 530, e.g., playing the first content, main asset Al.

Such switching becomes necessary as the end of one composition (e.g., A) in a show playlist 117 approaches and the players must transition to the next composition (e.g., B) specified in the show playlist 1 17. Such switching also occurs near a reel boundary within a single composition wherein that composition is divided into multiple reels, each reel in the having discrete main and auxiliary asset files. (The division of a composition into one or more reels is well known and provided in the SMPTE standard for the composition playlists). Lastly, such switching can also occur if the operator uses a manual interface to induce "trick play" events (not shown) such as skip forward, skip backward, jump to start, jump to chapter (or jump to reel), as are familiar to users of DVD players.

The slave transport transition process 820 begins at step 821, which should begin cautiously early, e.g., upon beginning of step 812 in the initial playout process 810, because (barring a policy to the contrary) there exists no specific timing for the master transport to start its transition process at step 721, and while most likely occurring no earlier than step

712, this is not strictly precluded. This ensures that slave transport transition process 820 will start in time to receive the preparation transaction 321. At step 822, the slave player 150 receives an indication of the need for the next auxiliary asset (e.g., fourth content, auxiliary asset B2 of composition B). In response, the slave player begins queuing this asset during step 823. However, these steps do not affect the state of the slave transport, which would typically remain in slave transport PLAYING state 630, e.g., playing the second content, auxiliary asset A2. Note that in some situations (e.g., "trick play" controls mentioned above), the next asset does not change, only the position within that asset, e.g., when the transport receives a command to skip backward a few minutes.

As the transition to the next asset becomes imminent during the step 724, the master player 1 10 indicates to the slave player 150 using a will-play transaction (e.g., transactions 323 A or 323B) that upon the start of the next frame interval, the next asset should begin playing. In an alternate embodiment, the master player could indicate that upon the start of a predetermined Nth frame, where N is at least one, the next asset should begin playing. In still another embodiment, the indication could represent the start of an Nth frame hence, where N is at least one where N is indicated in the will-play transaction message (not shown).

During step 824, the slave player 150 receives the will-play transaction (e.g., 323A or 323B) and accordingly, determines when the next auxiliary content (e.g., asset B2) should become current. In the preferred embodiment shown in FIG. 3, when the master transport takes the transition 532, the slave player receives will-play transaction (e.g., 323A, 323B). Consequently, the slave transport 150 takes the transition 634 to enter the slave transport NEXT CONTENT QUEUED state 640. In the alternative embodiments, discussed above, this occurs after the start of the Nth predetermined or explicitly indicated following frames.

Thus, both transports are ready to play the designated frame (e.g., BBB_Start) of their respective main and auxiliary assets, in synchronism. At the start of the next frame interval during steps 725 and 825, the master and slave transports will begin playing the corresponding next main and auxiliary assets, respectively, beginning with the corresponding and correct frames of each. The slave transport takes the transition 643, so that both transports now reside in their respective PLAYING states 530 and 630. Concurrent with this frame, the master transport takes the transition 531. Steps 726 and 826 iterate repeatedly, operating as described for corresponding steps 718 and 817.

FIGS. 7C and 8C illustrate the corresponding master and slave transport stop processes 730 and 830, respectively, which stop a currently playing composition. The master transport stop process 730 triggers during either step 731 A (corresponding to PAUSE event 421) upon receipt of an asynchronous command (e.g., from a user interface, not shown) or during step 73 IB (corresponding to RUNOUT event 451), wherein the current frame undergoing playout lies a predetermined number of frames before the end of the last asset (e.g., Bl). This frame may comprise penultimate frame of the asset, or an earlier frame, as measured by some predetermined number of frames, shown in most of the examples as the frame detected two frames before the end of the asset. The slave transport process 830 must be ready during step 831 whenever playout has started. In either case, the master transport takes the transition 534 of FIG. 5 to place the master transport in the master transport WILL STOP state 540.

At the start of the next frame interval during step 732, the master player 110 gives an indication (e.g., the will-stop transactions 422 and 461) to the slave player 150 that playout will halt. Upon receiving the will-stop transactions 422 and 461 during step 832, the slave transport takes the transition 635 to the slave transport WILL STOP state 650. Thus, upon the start of the next frame interval, both the master and slave transports will play the last corresponding frames during steps 733 and 833 and the slave transport will take the transition 651 to the slave transport STOPPED state 610.

During playout of this last frame, the master player 1 10 will indicate that the transport has stopped, e.g., with the STOPPED transaction 423 (which still provides asset and position information), or with the IDLE transaction 471 (which need not provide asset or position information), or by providing no legitimate messages in the synchronization signal 1 14. (Under such circumstances, the silence will be interpreted as an IDLE transaction.) The STOPPED and IDLE transactions differ because the STOPPED transaction provides information that allows resumption of the playout interaction 430; whereas the IDLE transaction concludes playout in such a way that requires initiation of the interaction 220 to play again.

After having stopped content playout at 734, the master player 1 10 may optionally repeatedly signal the stopped state at 735, e.g., with transaction 423 if paused, or transaction 471 if stopped or in case of content runout. When provided, these transactions are received by the slave player 150 at 835. Processes 730, 830 conclude at steps 736, 836, respectively.

FIGS. 7D and 8D show corresponding master and slave transport resumption processes 740 and 840, respectively that resume playout of a currently stopped composition.

The Master transport stop process 740 becomes triggered during step 741 upon the receipt of an asynchronous command (corresponding to RESUME event 441) (e.g., from a user interface, not shown) to continue playout. The master player 110 issues a will-play transaction 422 during step 742, indicating a frame number one past where playout had previously stopped (i.e., at the frame after the last frame shown). Upon receipt of the will-play transaction 422, the slave transport transitions to the CURRENT CONTENT QUEUED state 620 during step 842. Thus, during steps 743 and 843 both the master and slave transports resume play out of the current content at the same frame in their respective main and auxiliary assets. Steps 744 and 844 iterate repeatedly as with steps 717 and 816. Note that the resume play out processes 740 and 840 correspond to the initiate play out processes 710 and 810, except that the content is already queued and no corresponding load becomes necessary.

FIG. 9A illustrates an example embodiment of a synchronization protocol bitstream packet 900, suitable for carriage over a single audio channel of the AES output stream of the master player 1 10. A stream of such packets constitutes one exemplary embodiment of the synchronization signal 1 14 for use with the present principles. The synchronization protocol bitstream packet 900 comprises a header, here shown as a protocol identifier 901 (also called a sync word) and a frame rate selector 902; a transport state signal 910; a content

identification and current frame portion 920; a checksum 925; and padding 926 consisting of a predetermined number of bits based on the frame rate selector 902. The sync word 901 provides a mechanism for identifying candidate starting positions for a packet within a bitstream for which synchronization has not yet been obtained.

Each of the bits of packet 900 can be encoded in a digital audio signal (e.g., in a 48,000 Hz sample rate AES signal) as either a 12 kHz sine wave (e.g., to represent a zero bit) or as a 24 kHz sine wave (e.g., to represent a one bit). A single cycle of the 12 kHz waveform requires four samples at 48 kHz, which represents one exemplary bit encoding size. This representation of a bitstream signal is well known as frequency-shift keying (FSK).

Alternatively, the bits of packet 900 could be encoded using FSK in a digital audio signal at 6 and 12 kHz respectively, where four samples at 48kHz represent a half-cycle of a 6 kHz wave or a full cycle of a 12 kHz wave.

An alternative representation could instead use Manchester encoding and achieve twice this bit rate, but such an encoding might be more susceptible to the signal processing to which an audio output 1 13 might be subjected, which includes watermarking and sample rate conversion (e.g., conversion to an AES at a 96 KHz sample rate also adopted for use in digital cinema). Using the former FSK representation of 48,000 samples per second at 4 samples per bit yields a bit rate of 12,000 bits per second. At 120 fps, this bit rate yields only 100 bits per frame (12,000bps/ 120fps) so to provide a highly accurate synchronization signal that is also frame aligned since the bitstream packets used for the synchronization signal must not exceed more than 100 bits in length. At slightly lower frame rates (e.g., 100 fps), there will be more bits per frame, but not enough for an additional entire packet. Thus, the number of remaining bits varies according to frame rate, as shown in table 930.

The number of bits required for packet 900 is:

16 bits for the packet identifier 901 ;

4 bits for the frame rate selector 902;

3 bits for the transport state signal 910 to indicate one of the six states STOPPED, WILL_PLAY_A, WILL_PLAY_B, PLAYING_A, PLAYING_B, WILL_STOP discussed in more detail below;

1 bit for slot designator 921, to designate the "slot" A or B, i.e., corresponding to register A 153 or register B 154;

2 bits for UUID subindex 922 to indicate which quarter of the UUID is represented;

32 bits for a UUID subfield 923, to signal a one-quarter portion of a UUID;

24 bits to indicate the current frame index 924, allowing unique designation for a frame over more than a 24-hour period, even at 120 fps; and,

16 bits for a checksum 925, for example implemented as a cyclical redundancy check

(CRC).

This yields a total of 98 bits per packet, before adding the remaining bits 926.

As depicted in the table 930 in FIG. 9B, at a frame rate of 96 fps or higher, a frame can only represent one packet and each packet requires from 2 to 27 remaining bits to maintain frame alignment of the packet with the frame. At lower frame rates, more packets are possible, but for the examples shown in FIG. 9B, the number of packets per frame is constrained to be 1, 2, or 4, so as to make the frame alignment logic simpler. For example, if there are four packets per frame, the new frame interval can constitute any packet having a UUID sub-index field 922 of "0". If there are two packets per frame, the new frame interval can be designated as beginning with any packet having a UUID sub-index field 922 that is even (i.e., "0" or "2").

In another embodiment, rather than having the sub index field 922 and one-quarter of a UUID 923 provided each turn, a smaller value can represent the identification of an asset, e.g., a 34-bit value mapped to the 128-bit UUID, e.g., in an Auxiliary Resource Presentation List. Such mapping could occur without substantially altering the corresponding SMPTE standard, for example by constrained the Auxiliary Resource Presentation List to identify its own UUID with a lifetime-unique (or else a consecutively incrementing) least-significant 32 or 34 bits. This would make every transaction wholly representable in a single frame, rather than needing to receive four messages (potentially over four frames) to obtain a complete transaction.

Table 930 in FIG. 9B shows entries for thirteen different frame rates. The value of frame rate selector 902 corresponds to an entry in column 931. The corresponding entries in column 932 describes the actual frame rate in frames per second (fps), which all constitute values presently provided in various digital cinema standards from SMPTE, including archival frame rates 16 fps, 18 and 2/11 fps (nominally 18 fps), 20 fps, and 21 and 9/1 1 fps (nominally 22 fps). All of these frame rates were constrained to provide an exact integer number if audio samples at 48,000 samples per second, so that every frame of a composition at a particular frame rate will have exactly the same number of audio samples per frame throughout.

Column 933 shows for each frame rate selector value a corresponding number of packets provided in each frame interval. Each packet 900 corresponds to a message and each of the transactions presented in and discussed in conjunction with FIGS. 2A-B, 3, 4A-C comprise four such messages. Thus, for frame rates of 30 fps or lower, enough time exists to provide four packets, or one transaction, within the frame interval (the frame interval being the reciprocal of the number of frames per second). A curious exception is that for the nominal frame rates of 18 and 22 fps (actually prescribed to be 18 2/1 1 and 21 9/1 1 fps respectively), the number of audio samples available per frame, when further divided by four samples per bit, does not evenly divide by the expected four packets per frame, but at most, two, as shown.

The number of remaining bits 926 for each packet 900 at a particular frame rate appears in column 934. In table 930, these numbers do exceed 98 remaining bits for some of the lower frame rates, but this stems from the constraint in the embodiment discussed above of having exactly 1, 2, or 4 packets per frame for convenience in determining frame alignment.

Another alternative exemplary embodiment of a packet 950 appears shown in FIG. 9C, in which protocol identifier 951, frame rate selector 952, slot identifier 971, a content identification and current frame portion 970 (consisting of UUID sub-index field 972, UUID quarter 973, and frame index 974), and checksum 975 all have the same size as in packet 900. Only transport state portion 960 has a different size, here increased by the addition of a single frame start flag bit, in this embodiment used to indicate a packet immediately preceding the start of the subsequent frame. Thus, the packet 950 has a minimum possible number of bits of

99, before the remaining bits 976 are added.

The availability of a frame start flag bit relaxes the requirement of being able to determine which packets align with the start of a frame based on some internal counter (e.g., the UUID sub-index) that operates on one modulus not evenly divided by the number of packets in a frame and would otherwise lead to an ambiguous condition in which the start of frame could not be unambiguously associated with a particular packet. In this configuration, when the number of remaining bits exceeds the bits required for a packet, then an extra packet may be provided with each frame. Thus, in table 980 of FIG. 9D, frame rate selector column 981 and frame rate column 982 appear the same as in table 930, but for the corresponding frame rate entries, some packets per frame values in column 983 and all of the remaining bit entries in column 984 appear different.

FIG. 10 illustrates a playout sequence 1000 in which two pieces of content

(Casablanca and House of Wax) undergo playout. Both pieces of content have a frame rate of 24 fps, and in this example, the packets 900 represent the synchronization signal

corresponding to entry 935 in table 930. Playout progresses downward along timeline 1009 in

FIG. 10.

For frame interval 1001, no frame appears. The transport remains stopped and the system 100 prepares for show the playlist 117, which includes composition A (Casablanca) followed by composition B (House of Wax). In this example, these compositions appear very short, only two or three frames each, but illustrate the behavior of transactions provided as four individual messages, as in the packets 900. While the system 100 remains stopped, such as during the frame interval 1001, the synchronization signal 114 carries four individual message packets 1010-1013. In packet 1010, the transport state portion signal indicates that the transport remains STOPPED (spelled out for the message 1010 in FIG. 10, but encoded as a sequence of bits in the transport state signal 910). The slot indicator 920 indicates slot "A", which slave transport will associate with the register 153. Over message packets 1010-1013, the four quarters of the UUID representing this composition (shown here as "00-03" for the sub-index and "CasablancalD" for the UUID) accumulate in the register 153. The frame index, an integer represented here as "CasaStart", repeats in of the each packets 1010-1013. Collectively, the four packets 1010-1013 represent a single preparation transaction, such as transaction 232. During the next frame interval 1002, again no frame appears, as the master and slave transports both still remain in the STOPPED state. The transaction spread over the corresponding four message packets 1020-1023 represents a will-play transaction, such as transaction 242. The receipt of the will-play transaction 242 (which may be resiliently inferred from ANY ONE of messages 1020-1023 by virtue of so much repeated information from preparation messages 1010-1013), commands the slave player to begin playout of auxiliary content at the next frame interval, 1003. The indicator of a will-play transaction comprises a message in which the transport state signal indicates WILL_PLAY_A (where A indicates which slot contains the content that will undergo playout, here, register 153).

During frame interval 1003, both the master and slave transports start playing their respective resources for composition A, (Casablanca), and the master player provides playing transaction (e.g., transaction 243) over packets 1030-1033. At the frame interval 1004, playout of Casablanca (composition A) continues, but preparation-while-playing transaction (e.g., transaction 321), provided over message packets 1040-1043 informs the slave player 150 to ready slot B with the auxiliary asset B2 (identified by the UUID represented as HouseOJWaxlO) for composition B, beginning at integer frame position (shown as "HouseStart"). This provides the slave player advanced notice of the next content required, and could come an arbitrary amount of time before that next composition undergoes playout, though it should be enough advanced notice so that the slave player can successfully acquire and queue the content.

At frame interval 1005, playout of Casablanca reaches its last frame. A will-play transaction like 323A appears here, composed of the four message packets 1050-1053, each signaling transport state signal WILL PLAY B. The content identification portions 920 all indicate CasablancalO and the current frame index CasaStart+2 (the third frame played out), but the slave player 150 already has enough information from the preparation- while-playing transaction of frame interval 1004.

At frame interval 1006, both master and slave transports playout the first frame "HouseStart" of composition B, (House of Wax) as represented by "HouseOfflaxID" , and the master player 1 10 confirms this event by sending a playing transaction (e.g., 331) composed of message packets 1060-1063.

At frame interval 1007, the master player 1 10 signals that playout will stop in the will- stop transaction 461 composed of message packets 1070-1073. In this embodiment, the master and slave transports transition to a stopped state at the beginning of the next frame interval 1008, and output no content there. As this stop results from runout of the show playlist, in the subsequent frame interval 1008, confirmation of the stop occurs by the idle transactions (e.g., transaction 471). The actual presence of the packets 1080-1083 (as opposed to ceasing to provide the synchronization signal 1 14), indicate the transport status signal of STOPPED, but yield an empty content identification and position portion 920.

FIG. 1 1 shows a similar play out sequence 1100 in which the two pieces of content (again represented as Casablanca and House of Wax) both play, but both pieces of content have a frame rate of 48 fps, so that in this example, the packets 900 being used correspond to the entry 936 in table 930, which shows only two packets provided per frame. Playout progresses downward along timeline 1109. Thus, during the frame intervals 1101 and 1191, the message packets 1 1 10-11 13 provide the preparation transaction (identifying the auxiliary asset for slot A should be that for Casablanca). During the frame intervals 1102 and 1 192, message packets 1 120-1 123 provide the will-play transaction that indicates use of the asset identified for slot A (Casablanca). During frame intervals 1103 and 1 193, transmission of the playing transaction composed of messages 1130-1133 occurs. In frame intervals 1 104 and 1 194, transmission preparation- while-playing transaction (for House of Wax), composed of the packets 1140-1143, will occur. In the frame intervals 1105 and 1 195, transmission of the will-play transaction for the next content (House of Wax), composed of the message packets 1 150-1 153, occurs. In frame intervals 1106 and 1196, with the first frames of House of Wax, transmission of the playing transaction, composed of message packets 1 160-1163, occurs. In frame intervals 1107 and 1197, transmission of the will-stop transaction, composed of message packets 1 170-1 173, occurs, and in frame intervals 1 108 and 1 198, transmission of the idle transaction composed of message packets 1180-1183 occurs.

Generally, preparation, will-start, preparation-while-paying, and will-stop transactions will be separated by many more playing transactions. For example, constraints within the SMPTE standards require that a reel (or a composition) represent no less than one second's worth of content. Thus, many playing transactions will separate other transactions than appear here.

Note that the transport state signal portion 910 remains independent of content the identification and position portion 920. Most of the time, the content identification portion is redundant and not changing. The content position portion for each slot changes predictably, based on whether or not the slot is "current" and whether or not the transport resides in a PLAYING or WILL_STOP state. This would allow aborting of a partially delivered playing transaction or stopped transaction. For example, if in FIG. 11, Casablanca was one frame shorter, then frame interval 1 195 could be deleted along with the messages 1151 and 1 152. This would leave only messages 1 150 and 1153, issued during with final Casablanca frame 1 105, to represent the will-play transaction that indicates transport state signal

WILL_PLAY_B. Since the "CasablancalD" and "CasaStart+n" are redundant, as discussed above, the key information is that the next content frame should start after frame interval 1105, rather than later (after the now-dropped frame 1 106). This is indicated by the discontinuous sub-index count of messages 1 150 and 1 153, where the latter contains the sub- index value normally associated with the asset transition.

FIG. 12 shows a playout sequence 1200 along timeline 1209, where packet 950 provides the messages, with the frame start flag bit in transport state signal portion 960. Here, the playlist 117 provides for two pieces of content, Modern Times which runs at 18 frames per second (nominally) and Safety Last which runs at about 22 frames per second (nominally), and which, when using the packets 950, make use of the rows 985 and 986 in table 980, thus providing 6 and 5 packets per frame, respectively. In this example, those messages corresponding to the last message in a frame interval have a tag "F" indicating that the frame start flag bit is set, e.g., as in message packet 1253.

This example represents a case where it is difficult to determine in mid-run which message should correspond to the start of the frame (if not for the use of the frame start flag bit), since frames can contain different numbers of messages, and so transactions are not strictly bound to frame interval boundaries.

In this example, with no content present, an effective frame interval rate of 24 fps is presumed, thus delivering four packets 950 per frame intervals 1201 and 1202, during which a preparation transaction for Modern Times is provided with packets 1210-1213, and a will-play transaction for Modern Times is provided with packets 1220-1223. Each of these frame intervals 1201 and 1202 contains a final message 1213 and 1223 respectively (as designated by the 'F'), in which the start frame flag bit is marked.

As of frame interval 1203, in response to the will-play transaction of frame interval 1202 and the start frame flag bit being set in message 1223, Modern Times begins playing. Because of the nominal 18 fps frame rate of Modern Times, six messages will fit within frame interval 1203. Thus, four message packets 1230-1233 deliver a first playing transaction, and four more message packets 1240-1243 provide a preparation-while-playing transaction for Safety Last, where only two of the messages reside within frame interval 1203 and the other two reside in frame interval 1204. The start frame flag bit of message packet 1241, in the midst of the preparation-while-playing transaction, signals the end of the frame interval 1203. The rest of frame interval 1204 contains four more message packets 1250-1253, which constitute the will-play transaction that signals that Safety Last should begin playing following the start frame flag of packet 1253 at the end of frame interval 1204.

At frame interval 1205, both the master and slave transports play their respective assets for Safety Last. The messages 1260-1263 provide a playing transaction, followed by another, which starts with message packet 1270. Note that at the nominal 22 fps speed of Safety Last, there are only five message packets per frame interval.

The next frame interval 1206 constitutes the last frame of Safety Last, and a will-stop transaction begins with the message packet 1271, thus the playing transaction started with message 1270 now aborts. However, nothing in this instance requires restarting of the UUID sub-index count so the count proceeds from "00" in message packet 1270 to "01" in message packet 1271, and so on. The integer frame index value of "SafeStart" in message 1270 changes to "SafeStart+1" in message 1271, following the start frame flag bit having been set in message 1270.

As frame interval 1206 proceeds, the transport state signal bits continue to indicate WILL_STOP, even though more than four messages (represented by message packets 1271- 1273 and 1280-1281) have signaled this status. However, with the start frame flag bit set in message packet 1281, at the start of the frame interval 1207, both transports now stop and the master player provides idle transactions, as signaled by message packets 1282 and 1283.

The foregoing describes a technique for synchronizing auxiliary content with a digital cinema composition.