Sending CMCD-compatible data with MSF

[wilaw]

Ian raised the good question on Slack - "has anyone thought about how CMCD will work with MoQ?".

Since MOQT is media-agnostic and CMCD is media centric, the CMCD data should be sent by a media-aware streaming format such as MSF.

For this, we have the new Event TimelIne tracks, which are designed precisely to carry this type of information. I propose as part of MSF we define a new Event timeline type of "cta.wave.cmcdv2" (TBD) along with a data structure as illustrated below, in which a subset of CMCDv2 key-value pairs (those not dependent on HTTP requests) can be reported. The indexing would be media-time based. The player can use delta updates to dispatch new records.

[
    {
        "m": 502002,
        "data": {
            "sid":"6e2fb550-c457-11e9-bb97-0800200c9a66",
            "bl": 4068,
            "br": "(5000;v 320;a)",
            "bsd": 321,
            "e":"t"
            "sta": "p"
            "ts": 1756885678361,
        }
    },
    {
        "m": 536006,
        "data": {
            "sid":"6e2fb550-c457-11e9-bb97-0800200c9a66",
            "bl": 5172,
            "br": "(3000;v 164;a)",
            "e":"t"
            "sta": "p"
            "ts": 1756885621933,
        }
    }
]

One question is whether we should define this format as part of MSF (as there are quite some details in mapping CMCDv2 events to a non-HTTP environment), or specifiy this in a separate draft?

[gwendalsimon]

Great.

I initially wanted to combine performance logs and CMCD reports in the same log message at every group reception, but I concur that having a separate Event timeline for CMCD is much easier, more flexible, and more generic. So 100% aligned on the principle. Here are some remarks.

In the catalog, it could be interesting to add a special keyword to express the event that triggers the emission of CMCD reports. For example, a player can publish multiple CMCDv2 timeline tracks, one where the trigger is t=10sec, one where the trigger is t=1sec, one where the trigger is e (error), one where the trigger is abs;abe (ad break starts and ends)... If we don't have any keyword for this, the Subscriber would need to guess from the track name what is the trigger (note that rr cannot be supported).

You suggest the indexing to be the media time. However, in CMCDv2 spec, it is said that, in the event mode, the key ts is mandatory, which is wall-clock time. It may be simpler to have wall-clock time as index. But overall, I would let it open.

In essence, it shifts the direction of the connection. In CMCDv2 for HLS/DASH, the player decides the endpoints that will receive the reports. This is done offline (out of CMCDv2 spec). We have discussed many times the addition of endpoints in the manifest/playlists. In CMCDv2 for MOQ, the client becomes a Publisher and, in theory, anybody can subscribe to the tracks. Fortunately it is possible in MOQ to add authorization access to the tracks, so I am not sure we need any particular process to keep privacy. Thoughts here?

One question is whether we should define this format as part of MSF (as there are quite some details in mapping CMCDv2 events to a non-HTTP environment), or specifiy this in a separate draft?

Do you mean you would like to MOQify the CMCD keys, typically transforming all segment-related keys into groups-related ones? It may be a long process although we are not even sure MOQ-based CMCD reports will be used (e.g. Ian and Mike are both suggesting a quick and dirty HTTP-based forwarding mechanism). I would keep it as part of MSF and not over-complexify the spec.