1. Synchronization in Broadcasting ~various components of a coded service in broadcasting need to maintain synchronization and a fixed end-to-end delay between the service provider and the end-user ~need for a common understanding of time ~periodically insertion of clock reference (timestamping)

2. Timestamp Acquisition Live: timestamp acquired from an external source. Recorded: timestamp written for every frame of every motion file. Simulated: timestamp produced for every frame sent

3. Timestamp Format hh:mm:ss:frame hh:mm:ss:frame ~a string “hhmmssfr” (8 bytes) ~can be reduced to 22 bites ~number of frames per second vary at present

4. Timestamp in a Packet packet mask time (2 bytes) data size (2 bytes) block of data timestamp (8 bytes) checksum (2 bytes) Packet size: - uncompressed: 9 bones or reminder - compressed: data size + 14 bytes Data size: - uncompressed: 0 -compressed: number of encoded bones

5. Sync Code Development Phase 1: time acquired from a system clock, files played from a list in a code Phase 2: time acquired from an external source, files played from a list in a file with the reference to time or motion played live Phase 3: GUI editing

6. Phase 1 files played from a list or individually timestamps provided from system clock and sent for every frame drawbacks: can’t stop and start - files have to include a pause move of a certain length; can’t use individual frames; time depends on the system clock

7. Broadcast Applications: Client/Server

8. Phase 2 time acquired from an external source mask clock replaced with an external clock to provide frame timestamp information change of motion capture applications to include the external sync source drawbacks: still can’t stop and start nor use the desired range of frames

9. Phase 3: GUI editing time during recording m1 m2 m3m4 m’1 m’2m’3m’4pause playing time