A live skating stream may need only kilobytes of data if it sends skeletons and camera angles, not video frames

Why a frozen arena keeps getting re-sent

A frozen arena looks almost still on screen, yet ordinary video keeps paying for it again and again. Each frame carries the ice, boards, seats, and lights even when nothing there has changed at all. That habit comes from codecs that treat every pixel as if it might be new information in the next frame. In a skating broadcast, the moving part is often one person on a large static surface of ice. The rest of the scene repeats, but the encoder still spends bits describing it frame after frame. Multiple cameras can make this waste worse because they show the same arena from different sides during one event. A shared 3D model of the venue removes that repeated background from the live stream before playback begins. Once clients already have the rink, the sender can stop describing its walls and ice in every frame. Instead, the stream carries only what changes: skater position, body pose, and camera angle for each moment. This is a small set of numbers rather than a full picture of the arena or its surroundings. The idea is to send structure, not scenery, so the network can focus on motion and meaning. For a frozen arena, that distinction changes what counts as useful video data in a live feed. It also makes the stream less dependent on pixel by pixel fidelity for parts that never move. A viewer still sees a complete broadcast, but the repeated background is supplied from a model instead of reencoded. The saved space comes from recognizing that an arena can be known in advance and reused many times. Only the live action needs to travel through the network as fresh information while the venue stays fixed.

A skater as seventeen numbers and a camera angle

Instead of sending a moving picture, the system sends a short list of body points for each skater. Each frame carries seventeen skeletal landmarks that mark joints and limbs. A bounding box also travels with them, giving a rough outline of where the person stands on the ice. The camera angle is reduced to seven numbers rather than twelve, fixing how the rink should be viewed.

Those values are small enough to fit into tight numeric formats. In high definition, body coordinates can sit in about eleven bit integers, while four K versions need about twelve bits. Camera values use standard floating point numbers, which keeps the viewpoint compact without losing precision. The result is a stream made of structure rather than pixels.

Sending cropped pictures of the skater would seem simpler, but crop sizes change as the body moves and turns. Padding each crop to a fixed size wastes bandwidth. Sending every crop as its own image stream also loses compression between frames. The skeleton therefore acts as a minimal structured substitute for pixels.

In a fifty second clip, the stream held about sixty four kilobytes of skater pose motion. It also held under four kilobytes of bounding boxes and about forty two kilobytes of camera viewpoints. The test used 1080p video at thirty frames per second. Those numbers show why the broadcast can shrink so far below ordinary encoded video.

The viewer’s computer becomes the studio

In the skating example, GenStream sends a small set of scene numbers to the viewer. The background is not re-sent as pixels in every frame. Instead, the viewer already has a pre-made three-dimensional model of the venue. The server sends joint positions, outline boxes, and camera angles for each frame. On the viewer’s machine, an AI generator turns those points into a full body. That figure is then placed inside the three-dimensional rink model. The supplied camera angle decides where the viewer sees the skater from. This local rendering step is what makes the computer act like a studio. The machine must build a plausible body and blend it into the scene. That is more work than simply decoding an ordinary video file. Ordinary codecs send finished pictures, while this design sends instructions for rebuilding them. The viewer’s device becomes the place where pixels are finally created. The result can be rendered at different quality levels depending on the device. A faster machine may show a sharper skater, while a slower one shows a simpler one. The studio is no longer only the broadcast truck outside the arena. It is now partly inside the viewer’s own computer. That shift changes what a live stream must carry. It also changes where the creative and technical load lands.

Olympic skating shows how small the stream can be

In the Olympic skating test, a fifty-second clip of figure skating was compared with an ordinary high-definition video file. The source material ran in 1080p at thirty frames per second for about fifty seconds. As an HEVC-encoded file, it took roughly one hundred thirty-four megabytes. The continuous stream produced by GenStream needed only about one hundred ten kilobytes while the same action played on screen. That is a reduction of more than ninety-nine point nine percent in the data rate that must keep moving during playback.

The difference comes from what is sent after the viewer already has the large pieces needed to build the scene. The model of the rink and the software used to rebuild human figures are assumed to be available before the stream starts. Once those assets are in place, each frame no longer needs a full picture made of millions of pixels. Instead, the system sends compact information about the moving performer and the camera position. In the skating example, most of that small payload described how the skater moved through time. A smaller part marked where the skater appeared in the frame, and another part carried the viewpoint needed to place the scene correctly on the viewer’s screen.

The size is easy to miss until it is put next to ordinary video. One hundred thirty-four megabytes can hold a long stretch of high-definition footage, while one hundred ten kilobytes is close to the amount used by a short text exchange or a small image thumbnail. The skating test therefore shows that a live sports picture may not need to be carried as a full moving photograph at all. If the background is already known and only a few people are changing, the essential content can shrink from megabytes per minute to kilobytes per second.

What still stands between a demo and a live broadcast

A live broadcast would have to survive conditions that a laboratory clip does not face. The current prototype has been checked on four figure skating performances from the 2018 Pyeongchang Olympics, more than 40,000 frames in total across 48 short clips. Those clips share one rink, mostly still spectators, and a single skater moving through the center of the ice. That narrow setting makes the result easy to read, but it leaves open whether the method would hold on a football match, a concert, or a crowded stage.

The biggest obstacle is speed. A careful two-stage process first detects every person and then builds a precise mask, but that second stage is too slow for live use. A faster one-pass method can keep up with real-time processing, yet its output is less stable. Until those two needs are reconciled, a broadcaster would have to choose between missing the action and risking a shaky picture.

The camera work is another unfinished edge. The demo can estimate where the lens was pointing, but that part of the pipeline still produces geometric mismatches when moved into the rendering engine. One route uses a prebuilt 3D map of the venue and tries to match live frames to it. Another optimizes the camera directly against a rendered scene, which is too expensive for every frame in a live feed. The present workaround only solves the first frame fully and then tracks small changes from one frame to the next.

The background model also matters. In the test, the ice rink was built by hand in a game engine, with lines, lighting, and reflections adjusted to match broadcast footage. A live event would need such a model before the show begins, or it would have to be created quickly from organizer assets and earlier footage. That is not impossible, but it adds preparation work that ordinary streaming does not require.

The viewer side brings its own constraint. The prototype needs a powerful graphics card to build moving figures and composite them into the scene, and that hardware is not typical on phones or smart TVs. If the method is to reach ordinary living rooms, it must run with lighter models, compressed calculations, or some of the work moved to nearby servers. Without that step, the savings in bandwidth would be offset by devices that cannot keep up.

There are also quality questions that have not been settled by numbers alone. Standard video metrics may score the reconstructed picture lower because it does not match every pixel of the original broadcast. Semantic content may remain clear for replays, analysis, or low-bandwidth viewing, but a formal perceptual test is still needed. The system should be more tolerant of dropped frames and jitter because missing detail can be regenerated, but that advantage has not been evaluated under real network stress.

Taken together, these gaps define the distance from a proof of concept to a service a broadcaster could trust. The idea explains why ordinary video wastes bandwidth on stable arenas and repeated pixels. What remains is the unglamorous work of making every stage fast, robust, and usable on devices people actually own.

A lighter stream, a heavier viewer

The skating test points toward a different contract for live video. Instead of pushing every pixel across the network, the system sends a small description of what is moving and lets each screen rebuild the picture. That shift can make broadcasts much cheaper to carry, especially when one performer moves through a large stable arena. It also opens doors that ordinary streams leave closed: replays from angles no camera captured, versions tuned to different devices, or highlights assembled from semantic data rather than stored footage.

The promise is real, but it rests on an uneven exchange. The network gets relief while the viewer’s machine takes on more work. A phone or smart TV must generate a believable body, place it in a 3D venue, and keep the result smooth enough for live viewing. Today that task needs serious graphics power, so the savings are not yet available to the devices most people actually use. The same caution applies beyond ice rinks. Crowds, overlapping performers, changing lighting, and unfamiliar venues will test whether the method can generalize without losing plausibility or speed.

If those obstacles shrink, semantic streaming could change what a broadcast is allowed to be. It would become less like a fixed recording and more like a shared scene that each viewer can enter differently. The harder question is whether audiences will accept a picture built by inference when the original pixels are no longer being sent at all.