WO2015038186A1 - Système et procédé de synchronisation de contenu auxiliaire - Google Patents

Système et procédé de synchronisation de contenu auxiliaire Download PDF

Info

Publication number
WO2015038186A1
WO2015038186A1 PCT/US2014/015504 US2014015504W WO2015038186A1 WO 2015038186 A1 WO2015038186 A1 WO 2015038186A1 US 2014015504 W US2014015504 W US 2014015504W WO 2015038186 A1 WO2015038186 A1 WO 2015038186A1
Authority
WO
WIPO (PCT)
Prior art keywords
digital cinema
transport
slave
content
frame
Prior art date
Application number
PCT/US2014/015504
Other languages
English (en)
Inventor
William Gibbens Redmann
Original Assignee
Thomson Licensing
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing filed Critical Thomson Licensing
Publication of WO2015038186A1 publication Critical patent/WO2015038186A1/fr

Links

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/11—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information not detectable on the record carrier
    • G—PHYSICS
    • G03—PHOTOGRAPHY; CINEMATOGRAPHY; ANALOGOUS TECHNIQUES USING WAVES OTHER THAN OPTICAL WAVES; ELECTROGRAPHY; HOLOGRAPHY
    • G03B—APPARATUS OR ARRANGEMENTS FOR TAKING PHOTOGRAPHS OR FOR PROJECTING OR VIEWING THEM; APPARATUS OR ARRANGEMENTS EMPLOYING ANALOGOUS TECHNIQUES USING WAVES OTHER THAN OPTICAL WAVES; ACCESSORIES THEREFOR
    • G03B31/00—Associated working of cameras or projectors with sound-recording or sound-reproducing means
    • G03B31/04—Associated working of cameras or projectors with sound-recording or sound-reproducing means in which sound track is not on, but is synchronised with, a moving-picture film
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel

Definitions

  • This invention relates to a technique for synchronizing auxiliary content with a digital cinema composition
  • 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.
  • SMPTE Society of Motion Picture and Television Engineers
  • 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.
  • 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.
  • 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.
  • the bit stream does not provide any information about the content other than the content currently playing out.
  • an auxiliary content player monitoring the signal cannot recognize the content until at least the first frame of content has already played out.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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;
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • AES3 Audio Engineering Society
  • AES/EBU parallels part 4 of the international standard IEC 60958.
  • 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.
  • 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).
  • 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.
  • 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.
  • an external controller 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.
  • SPL Show Play List
  • 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.
  • 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 (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.
  • CPL SMPTE composition playlist
  • 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.
  • UUID Universally Unique Identifier
  • the playlist can identify each component asset using this unique identifier.
  • 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.
  • the communications channel 140 could send the identification of the digital cinema composition A2.
  • 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.
  • 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.
  • 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.
  • A2 content identifier
  • 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.
  • 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).
  • register 158 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.
  • auxiliary content-enabled digital cinema presentation system 100 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.
  • 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,
  • the breaks in the timelines 201 and 202 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.
  • UUID e.g., UUID
  • 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.
  • a loss of signal e.g., a failure of the synchronization signal 114
  • 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)
  • 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.
  • 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.
  • the preparation transaction 232 specifies a slot (here, slot "A" corresponding to register 153).
  • 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).
  • the preparation transaction 232 specifies a specific start frame within the asset track file, designated here as "AAA_START".
  • 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.
  • 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.
  • 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.
  • the PLAY button may become enabled by at least one of these or other events.
  • 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)
  • 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.
  • 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
  • the will-play transaction 242 marks the end of preparation phase 230, immediately followed by the normal play out phase 240.
  • 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.
  • 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
  • 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.
  • 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.
  • transactions may be atomic, as represented here, but in other embodiments, transactions may be spread out and/or interleaved and/or multiplexed.
  • 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.
  • 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.
  • AAA show ID
  • 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
  • slot B now becomes loaded with an identifier (e.g., a UUID) corresponding to the next auxiliary asset to undergo playout.
  • 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.
  • 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.
  • AAA currently playing asset
  • 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.
  • the transport of slave player 150 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.
  • BBB STOP the transport of the slave player 150 halts, such that frame BBB STOP is the last one presented.
  • 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.
  • 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.
  • the auxiliary output system 160 can provide such signal processing.
  • 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.
  • 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.
  • 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.
  • 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.
  • the idle transaction remains unnecessary if the slave player 150 can detect the end of show playlist 117 by other means.
  • 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.
  • the master transport i.e., the transport of the master player 1
  • 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).
  • 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
  • the master transport 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.
  • 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.
  • 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).
  • WILL_SWITCH the slave transport status command
  • the state of the master transport remains at PLAYING 530.
  • 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).
  • 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.
  • 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.
  • idle messages e.g., the idle messages 211 and 212 of FIG. 2A
  • 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.
  • the slave transport 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).
  • the slave transport 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the slave transport returns to the PLAYING state 630, but now plays the next asset (e.g., B2) during the normal playout phase 330.
  • the slave transport 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.
  • 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.
  • 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.
  • a first piece of content the main assets of a first composition, e.g., asset A 1 of composition A
  • 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.
  • 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. .
  • 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.
  • 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.
  • the main transport 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.
  • the current main asset e.g., asset Al
  • 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).
  • the playout of the main and auxiliary content begins on the master and slave player in
  • 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.
  • step 717 of the master playout process 710 can serve as proxies for the preparation and will-play transactions 232 and 242.
  • the transport of the slave player 150 in response to receiving a proxy preparation transaction at 812 can load the designated asset.
  • the slave transport takes the transition 612 to the QUEUED state 620.
  • the slave transport Upon entering the next frame interval, the slave transport takes the state transition 623 to the slave transport PLAYING state 630.
  • 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
  • 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.
  • 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).
  • 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
  • slave transport transition process 820 will start in time to receive the preparation transaction 321.
  • 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).
  • the slave player begins queuing this asset during step 823.
  • 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.
  • 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.
  • 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.
  • a will-play transaction e.g., transactions 323 A or 323B
  • 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.
  • 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).
  • 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.
  • 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.
  • both transports are ready to play the designated frame (e.g., BBB_Start) of their respective main and auxiliary assets, in synchronism.
  • 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.
  • 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.
  • 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.
  • the slave transport takes the transition 635 to the slave transport WILL STOP state 650.
  • 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.
  • 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.
  • 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).
  • the slave transport transitions to the CURRENT CONTENT QUEUED state 620 during step 842.
  • 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.
  • 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
  • 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).
  • 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).
  • sample rate conversion e.g., conversion to an AES at a 96 KHz sample rate also adopted for use in digital cinema.
  • the number of bits required for packet 900 is:
  • 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;
  • checksum 925 16 bits for a checksum 925, for example implemented as a cyclical redundancy check
  • 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.
  • 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").
  • 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.
  • frame rates 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).
  • 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.
  • FIG. 9C 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.
  • the packet 950 has a minimum possible number of bits of
  • FIG. 10 illustrates a playout sequence 1000 in which two pieces of content
  • composition A Cosmetic A
  • composition B “House of Wax”.
  • 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.
  • the synchronization signal 114 carries four individual message packets 1010-1013.
  • 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.
  • 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).
  • 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.
  • playout of Casablanca composition A
  • preparation-while-playing transaction e.g., transaction 321
  • 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.
  • 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.
  • a playing transaction e.g., 331
  • the master player 1 10 signals that playout will stop in the will- stop transaction 461 composed of message packets 1070-1073.
  • the master and slave transports transition to a stopped state at the beginning of the next frame interval 1008, and output no content there.
  • 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.
  • the message packets 1 1 10-11 13 provide the preparation transaction (identifying the auxiliary asset for slot A should be that for Casablanca).
  • message packets 1 120-1 123 provide the will-play transaction that indicates use of the asset identified for slot A (Casablanca).
  • preparation will-start, preparation-while-paying, and will-stop transactions will be separated by many more playing transactions.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

L'invention concerne un procédé pour synchroniser un dispositif de lecture de cinéma numérique auxiliaire avec un dispositif de lecture de cinéma numérique principal, lequel procédé commence par la réception, au niveau du dispositif de lecture de cinéma numérique auxiliaire, d'un signal de synchronisation codé avec l'identification de contenu courant, une identification de contenu futur suivant et une signalisation qui précède des actions entreprises par le transport du dispositif de lecture de cinéma numérique principal. Le dispositif de lecture de cinéma numérique auxiliaire se synchronise lui-même avec le dispositif de lecture de cinéma numérique principal sur la base du signal de synchronisation par acquisition et mise en tampon d'un contenu avant sa lecture. En réponse au signal de synchronisation, le dispositif de lecture de cinéma numérique auxiliaire peut fournir une réponse précise d'échantillon à trames alignées à des instructions basées sur une trame dirigeant un transport de contenu auxiliaire (par exemple, lecture, pause, reprise et arrêt).
PCT/US2014/015504 2013-09-16 2014-02-10 Système et procédé de synchronisation de contenu auxiliaire WO2015038186A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361878126P 2013-09-16 2013-09-16
US61/878,126 2013-09-16

Publications (1)

Publication Number Publication Date
WO2015038186A1 true WO2015038186A1 (fr) 2015-03-19

Family

ID=50231525

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/015504 WO2015038186A1 (fr) 2013-09-16 2014-02-10 Système et procédé de synchronisation de contenu auxiliaire

Country Status (1)

Country Link
WO (1) WO2015038186A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104867513A (zh) * 2015-04-20 2015-08-26 广东欧珀移动通信有限公司 一种播放控制方法及设备
CN107710770A (zh) * 2015-09-28 2018-02-16 谷歌有限责任公司 时间同步的多区域媒体流式传输
US10907371B2 (en) 2014-11-30 2021-02-02 Dolby Laboratories Licensing Corporation Large format theater design
US11885147B2 (en) 2014-11-30 2024-01-30 Dolby Laboratories Licensing Corporation Large format theater design

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0372155A2 (fr) * 1988-12-09 1990-06-13 John J. Karamon Méthode et système de synchronisation d'une source auxiliaire de son contenant des canaux de langages multiples, avec un film d'images, bande vidéo, ou autre source d'images contenant une piste son
WO2002053246A2 (fr) * 2001-01-05 2002-07-11 D-Box Technology Inc. Systeme transducteur de mouvements
US20030002689A1 (en) * 2001-06-29 2003-01-02 Harris Corporation Supplemental audio content system with wireless communication for a cinema and related methods
WO2006114000A1 (fr) * 2005-04-26 2006-11-02 D-Box Technologies Inc. Procede et appareil de codage d'un signal de mouvement avec un signal sonore
EP1729173A2 (fr) * 2005-05-27 2006-12-06 Telegraf ApS Système générant des informations supplémentaires synchronisées
WO2007011683A2 (fr) * 2005-07-14 2007-01-25 Thomson Licensing Procede et appareil pour la fourniture d'un support auxiliaire dans une liste de diffusion de compositions cinematographiques numeriques
WO2013133863A1 (fr) * 2012-03-09 2013-09-12 Thomson Licensing Commande distribuée d'un contenu synchronisé

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0372155A2 (fr) * 1988-12-09 1990-06-13 John J. Karamon Méthode et système de synchronisation d'une source auxiliaire de son contenant des canaux de langages multiples, avec un film d'images, bande vidéo, ou autre source d'images contenant une piste son
WO2002053246A2 (fr) * 2001-01-05 2002-07-11 D-Box Technology Inc. Systeme transducteur de mouvements
US20030002689A1 (en) * 2001-06-29 2003-01-02 Harris Corporation Supplemental audio content system with wireless communication for a cinema and related methods
WO2006114000A1 (fr) * 2005-04-26 2006-11-02 D-Box Technologies Inc. Procede et appareil de codage d'un signal de mouvement avec un signal sonore
EP1729173A2 (fr) * 2005-05-27 2006-12-06 Telegraf ApS Système générant des informations supplémentaires synchronisées
WO2007011683A2 (fr) * 2005-07-14 2007-01-25 Thomson Licensing Procede et appareil pour la fourniture d'un support auxiliaire dans une liste de diffusion de compositions cinematographiques numeriques
WO2013133863A1 (fr) * 2012-03-09 2013-09-12 Thomson Licensing Commande distribuée d'un contenu synchronisé

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
SMPTE: "SMPTE D-Cinema Operations - Auxiliary Content Synchronization Protocol ST 430-10:2010", SMPTE D-CINEMA OPERATIONS - AUXILIARY CONTENT SYNCHRONIZATION PROTOCOL ST 430-10:2010, vol. ST 430-10:2010, 2 November 2010 (2010-11-02), XP055110665 *
SMPTE: "SMPTE D-Cinema Operations - Auxiliary Resource Presentation List ST 430-11:2010", SMPTE D-CINEMA OPERATIONS - AUXILIARY RESOURCE PRESENTATION LIST ST 430-11:2010, vol. ST 430-11:2010, 2 November 2010 (2010-11-02), XP055110673 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10907371B2 (en) 2014-11-30 2021-02-02 Dolby Laboratories Licensing Corporation Large format theater design
US11885147B2 (en) 2014-11-30 2024-01-30 Dolby Laboratories Licensing Corporation Large format theater design
CN104867513A (zh) * 2015-04-20 2015-08-26 广东欧珀移动通信有限公司 一种播放控制方法及设备
CN104867513B (zh) * 2015-04-20 2017-09-29 广东欧珀移动通信有限公司 一种播放控制方法及设备
CN107710770A (zh) * 2015-09-28 2018-02-16 谷歌有限责任公司 时间同步的多区域媒体流式传输
US10587908B2 (en) 2015-09-28 2020-03-10 Google Llc Time-synchronized, multizone media streaming
CN107710770B (zh) * 2015-09-28 2021-02-09 谷歌有限责任公司 用于时间同步的多区域媒体流式传输的系统和方法
US11051066B2 (en) 2015-09-28 2021-06-29 Google Llc Time-synchronized, multizone media streaming
US11463762B2 (en) 2015-09-28 2022-10-04 Google Llc Time-synchronized, multizone media streaming
US11871067B2 (en) 2015-09-28 2024-01-09 Google Llc Time-synchronized, multizone media streaming

Similar Documents

Publication Publication Date Title
EP1478182B1 (fr) Dispositif et logiciel pour l'accès à des informations audiovisuelles numériques avec la précision d'une trame
US7058721B1 (en) Dynamic quality adjustment based on changing streaming constraints
US7870281B2 (en) Content playback device, content playback method, computer-readable storage medium, and content playback system
JP4270379B2 (ja) デジタル情報の効率的な伝送および再生
JP2007074608A (ja) 再生装置および再生方法
US9154834B2 (en) Fast switching of synchronized media using time-stamp management
EP1239674A2 (fr) Procédé et appareil d'enregistrement de données radiodiffusées
JP5116664B2 (ja) 同期化されたストリーム・パッキング
TW200303497A (en) Enhanced navigation system using digital information medium
US9456243B1 (en) Methods and apparatus for processing time-based content
WO2015038186A1 (fr) Système et procédé de synchronisation de contenu auxiliaire
KR101117601B1 (ko) 재생목록으로부터 검색된 이벤트 정보에 기반을 둔 기능성을 제공하기 위한 재생장치 및 방법
JP2015220517A (ja) 受信装置、および送信装置、並びにデータ処理方法
TW200524294A (en) Coding controller and coding system
JP5672409B1 (ja) 受信装置、およびデータ処理方法
JP6590043B2 (ja) 受信装置、および送信装置、並びにデータ処理方法
JP5672411B1 (ja) 受信装置、およびデータ処理方法
JP2005197839A (ja) トランスポートストリームの特殊再生方法及びトランスポートストリームの記録再生装置
CA2328230C (fr) Procede pour creer une chaine de donnees numeriques
JP5672410B1 (ja) 受信装置、およびデータ処理方法
JP2023179125A (ja) デジタル音声信号同期装置及びプログラム
US20170206933A1 (en) Systems and methods for indexing media streams for navigation and trick play control
JP2009260669A (ja) 再生方法、および再生装置
JP2008072718A (ja) 符号化記録装置
JP2007202156A (ja) デジタルビデオおよびデータ記録装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14708166

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14708166

Country of ref document: EP

Kind code of ref document: A1