Track updates

[kixelated]

The current draft allows tracks within a catalog to be updated. This causes a few problems:

• What happens if a track is changed (ex. new profile)?
• When does this update occur?
• What happens when the catalog update is delayed?

If the publisher changes the codec/profile in the middle of a track, the decoder will blow up. There's no way to know when the change will take place.

[kixelated]

I don't see how we could easily support tracks being updated.

At the very least we would need a group ID when the change occurs, but that won't work in the face of packet loss, because the catalog update could arrive after the starting group. I think the only way to fix this is to put the init information at the start of each group (ex. SPS/PPS) which is not desirable.

I would prohibit it for now. At the very least, some text to say that the init payload MUST NOT change on subsequent updates. We can only add or remove tracks.

[kixelated]

IMO we start with no catalog updates for interop. Then we can build an ADD and REMOVE track message to avoid retransmitting the entire catalog on each update.

[wilaw]

@kixelated

I don't see how we could easily support tracks being updated.

By 'update', I agree that we shouldn't allow their media characteristics (anything described in the init segment or the init itself) to change. But we should allow them to be added and deleted .

I would prohibit it for now. At the very least, some text to say that the init payload MUST NOT change on subsequent updates. We can only add or remove tracks.

Agree

IMO we start with no catalog updates for interop. Then we can build an ADD and REMOVE track message to avoid retransmitting the entire catalog on each update.

I think that having no catalog updates in v1 is unnecessarily restrictive and would lead to missed use-cases, rather than better interop. We also don't need to invent ADD and REMOVE track messages if we allow the CATALOG (and its updates) to define the availability of tracks. The whole purpose of the CATALOG track is to do exactly that. This point is up to MOQ base protocl however and we need to resolve it there. And "avoiding retransmitting the entire catalog on each update" can be addressed by either ignoring (because catalog updates are small to begin even with their init payloads), or by allowing delta updates on the catalog, which wouldn't be complex and I can mock that up if you'd like to see what it might look like?

[kixelated]

Yeah, the ADD and REMOVE messages would be delta updates. I think we need some timing information about when a track starts and ends, although I'm not sure.

[wilaw]

Discussion 4/20: Need to add a delta update mechanism Same group, second or subsequent object Each object is a list of delta updates. Sync'd tracks should be added in the same object. Some text to instruct player to process all available tracks before performing track selection.

[wilaw]

Also, if removing track, publisher should send remove along with a last Group, Object number.
Update with all tracks removed signals EOS.