5 ms·

> When the live programming ends at 1100, the video experience would break and the user would need to hit refresh to see the next show on the schedule. If that

> When the live programming ends at 1100, the video experience would break and the user would need to hit refresh to see the next show on the schedule. If that was the only problem, why wouldn't changing the stream with a small amount of JS have worked rather than having to add a muxing layer in front of the streams?

kevmo314 6y ago
I wonder if they have plans to expand to non-browser viewports?
- vanshg 6y ago
  They do. From the last section of the article, entitled "Thinking Ahead..." > Bring Cloudflare TV to platforms like Apple TV and Roku
kick 6y ago
Breaks/introduces annoying amount of lag for people using things like mpv for an "actual" live television experience would be my guess.
phn 6y ago
This is just a guess, but JS only works in the context of a website, and it might actually be simpler to control the server side muxer without having a whole bunch of logic and the systems to support it.
yazaddaruvala 6y ago
1. This might not be built in a browser. e.g. Hulu or ESPN iOS app. Although any client of the byte stream could implement the "refreshing" protocol on the client, its more work for each client to do. 2. Given this is Cloudflare they are probably trying to find optimal ways to use bandwidth and their edge fleet. Like TV, maybe there will be no "rewind", and each Cloudflare edge server fans out the same "currently live" bytes to all available clients (i.e. shared state across all client connections, rather than independent state for each client connection). Which can't happen if there is a "refresh" event from each client that needs to be synchronized. 3. "refreshing" implies new state, added latency, and a "janky" feel. If "transitioning" is all server side, bytes from the next "episode" can be pipelined before the previous episode is finished and the refresh event has occurred. |-Episode A->| |-Episode A->| |-Episode A->| | <-| | <--Refr| |<--Refresh--| |-> | |de B-> | |-Episode B->| |-Episode B->| |-Episode B->| Rather than: |-Episode A->| |-Episode A/B->| |-Episode A/B->| |-Episode B->| |-Episode B->| |-Episode B/C->|

kevmo314 6y ago

I wonder if they have plans to expand to non-browser viewports?

vanshg 6y ago
They do. From the last section of the article, entitled "Thinking Ahead..." > Bring Cloudflare TV to platforms like Apple TV and Roku

kick 6y ago

Breaks/introduces annoying amount of lag for people using things like mpv for an "actual" live television experience would be my guess.

phn 6y ago

This is just a guess, but JS only works in the context of a website, and it might actually be simpler to control the server side muxer without having a whole bunch of logic and the systems to support it.

yazaddaruvala 6y ago

1. This might not be built in a browser. e.g. Hulu or ESPN iOS app. Although any client of the byte stream could implement the "refreshing" protocol on the client, its more work for each client to do. 2. Given this is Cloudflare they are probably trying to find optimal ways to use bandwidth and their edge fleet. Like TV, maybe there will be no "rewind", and each Cloudflare edge server fans out the same "currently live" bytes to all available clients (i.e. shared state across all client connections, rather than independent state for each client connection). Which can't happen if there is a "refresh" event from each client that needs to be synchronized. 3. "refreshing" implies new state, added latency, and a "janky" feel. If "transitioning" is all server side, bytes from the next "episode" can be pipelined before the previous episode is finished and the refresh event has occurred. |-Episode A->| |-Episode A->| |-Episode A->| | <-| | <--Refr| |<--Refresh--| |-> | |de B-> | |-Episode B->| |-Episode B->| |-Episode B->| Rather than: |-Episode A->| |-Episode A/B->| |-Episode A/B->| |-Episode B->| |-Episode B->| |-Episode B/C->|