Live streaming has been an integral part of the video technology at Disney Streaming Services (DSS). DSS has multiple teams whose main functions are to preserve the highest possible video quality, and that the content transportation technologies are working as they should 24/7. In order to do this, DSS built and staffed Transmission Operations Centers (TOCs) in San Francisco and New York City, providing state-of-the-art video monitoring systems that allowed the TOC Staff to view and perform quality control on any of the thousands of IP-based streams that we might be processing at a given time. As cases of COVID-19 in the United States increased, the decision was made to move the DSS workforce home. While this resulted in a variety of challenges for all of our employees, the challenges for the TOC Operators were unique. The live video content that DSS uses for its sources tends to be high-bitrate, broadcast-quality streams. These streams are intended to be consumed via satellite or fiber. Some of them run in the neighborhood of 100 Mb/s. If people tried to consume these streams in their native format, the streams would be chewing up a huge amount of bandwidth, both on the DSS VPN and on users’ home internet connections. In order to allow TOC Operators to watch this content remotely, we had to generate proxy streams which would look good enough to monitor video, yet also reduce bandwidth to the point that any home internet connection could consume a few of these streams simultaneously. Aside from bandwidth, it was also important to provide these streams as close to real-time as possible, as our operators needed to see the streams “as they are,” not “as they were 30 seconds ago.” Luckily, DSS has years of experience compressing high-quality video so that it can be consumed on devices at a low bitrate. DSS’s homegrown video transcoder, xCoder (the same transcoder which makes content for Disney+ and ESPN+, among other properties) had a solid foundation on which to build the Remote TOC monitoring platform. If you’ve ever watched anything on Disney+, ESPN+ or MLB.tv, you’d know that the video that xCoder produces looks amazing, so that provided a huge advantage. Using xCoder for this purpose, however, created a new set of challenges. For both live and linear uses, xCoder was built to consume “groomed” transport streams. These streams are processed by DSS’s Broadcast Infrastructure environment, which standardizes incoming transport streams and sets the structures for Packet Identifiers (PIDs) and Program Map Tables (PMTs) to follow company standards. The advantage of having this environment is that it simplifies the setup of the xCoder for any given transcode job. Each 188-byte packet of data in a transport stream has a packet identifier (PID) that tells a receiving device what it is (video, audio, metadata, etc.). The PMT defines to a receiver of a transport stream what each of these PIDs are. Each elementary stream has its own PID number. With the thousands of streams out there, made by thousands of different encoders, the PID structures of each stream can be unique. Standardizing the structure in our broadcast environment allows the xCoders to just “worry” about decoding and encoding. TOC Operators needed to be able to monitor both groomed and ungroomed streams to make sure that this infrastructure is functioning correctly. xCoder uses presets to determine the types of content coming in, and also the types of content to encode. One of the goals of the stream standardization system is to utilize as few presets as possible for a given partner. For example, for ESPN+, the system allows us to only have one preset for all events, from UFC to Ivy League Water Polo. xCoder was built as part of a signal flow that takes in the groomed broadcast contribution sources on one end and produces video and audio segments for HTTP-based streaming on the other. In order to reduce latency, a few steps needed to be removed from that signal flow: the broadcast infrastructure that grooms the streams, the segmenter that generates the segments, the origin, and the CDN. As a bit of background, from an end user’s perspective, the segmenter actually produces and encrypts the media files that the viewer gets (short “chunks” of the video and audio). The CDN acts as a distributor of the media files so that everyone in the world trying to access the same media isn’t requesting from a single point, which would certainly cause a bottleneck. xCoder, as a standalone, produces a proprietary TCP stream. In order for the Remote TOC project to succeed, we needed a way for these streams to be transported to, and decoded by, users on their computers at home. Presented at Demuxed 2020.