The workers would handle both ingress and egress. The ingress feed should already be encoded for distribution by whatever system is pushing it. The durable objects in the middle would hold a moderate buffer of content which would be referred to on the egress routes. Archival would be a separate system that listens to all egress sessions at the same time. A 3rd websocket CF worker route could be used to exclusively manage video player/streamer/editor events.
One low-latency system I had in mind would go: individual streamer frames (jpeg) -> PUT CF route -> route adds durable object per frame -> GET CF route w/ current frame counter returns newer frames -> Client web UI displays the jpeg frames with appropriate timing via a 2-3 frame buffer.
This has much higher bandwidth requirements due to the loss of interframe compression effects, but it is compatible with 100% of platforms and very fast. It also allows for very simple seeking.
If you are willing to leverage cloudflare and your target audience can handle a ~25 mbps download requirement, then this model could fit. You can get more mileage per bps if you reduce quality/resolution too.
You can also put some intelligence in the stream path. Distributed compositing pipelines and other fun ideas. It's infinitely easier when everything is natively "just an image". Maybe some server's only job is to draw the hud on top of a frame received from a datacenter across the street.