slhck
commented
5 months ago This is a great suggestion! It would really help if CMCD could be used to derive an accurate representation of what was going on for the user watching the media.
There are some aspects I believe need to be clarified. First, the described states actually happen at two layers:
- Buffer layer (buffering, not buffering, choosing what representation to buffer)
- Presentation layer (stalling, playing, seeking, paused, ended)
The current suggestion is a bit of a mix between those two. The important buffer-level aspects (buffer length and buffer starvation) seem to be already handled by existing keys. With a focus on what the user perceived, I'd prefer transmitting information about the presentation layer.
There's a catch though: the time of sending those states may not correspond to the actual time at which they occurred on the client, because they are bound to the client making a request. This obviously does not apply to the transport mode where an independent JSON request is being sent. But it could lead to the receiving end getting a wrong representation of what actually happened at the client level.
This could be easily mitigated by requiring that, when a state transition is sent, the time of its change is also sent in a separate field (e.g., expressed as an absolute wall clock timestamp, or the ∆(current wall clock time, wall clock time of state change), to minimize the request footprint).
I would also suggest renaming/splitting up some states in line with the above considerations.
- Startup: maybe this should be separated into “loading” and “playing” states, where the first request made while the player is still waiting to play sends a “loading” state, and only when it has started playing, a “playing” state is sent. This would apply to both initial startup and any stalling happening during the presentation.
- Steady state: I am not sure if this is needed at all, when it could be inferred from the buffer length.
- Seeking: This is maybe a misnomer; seeking is already completed when this is fired with a new request, so probably “seeked”? We ideally also want know the media timestamp of where the user seeked (although that could be inferred from the request parameters or byte ranges etc.)
- Switching up/down: This would be good to have for cases where the
brvalue has already changed (because, e.g., the buffer layer loads a higher-resolution content), but the presentation itself is still using the old rendition to avoid quality oscillations. Note that a switch may not be up/down one level, so we must explicitly send thebrvalue to which the switch corresponds. - Paused: This would not be possible to transmit unless a player makes a request despite having just been told to pause (which I guess should stop any future requests in steady state). Can only be transmitted once playback resumes.
Edit:
- Ended: This could be included to signal a clean end of a session (although again, no media request will be sent for this).
ZmGorynych
acbegen
We should create a key to be able to track different states of playback. Candidate states might be
We might be able to repleace the SwitchingUp|Down with a single 'Switching state' and let the 'br' values describe the direction.