Questions about "Other transports" sections

[garethsb]

It's obviously hard to talk about "other" transports in a generic but helpful way.

E.g. Other single essence or mux transports could use a "manifest" a.k.a. "transport file" format that was something other than SDP?

If the main concern is the parameter sets flow/transport modes, would it make sense to focus very tightly on those?

[alabou]

Other transport could be NDI or UDP ... Having the concept of "other transports" allows the current specification to indicate how non-RTP transports support an H.264 Flow. Once we know more about those other transports (becoming supported by NMOS) we would be able to add more information (ex some manifest format or requirements) while still being compliant with the actual requirements.

I think it is useful to consider the possibility of other transports in order to properly structure the specification.

[garethsb]

Certainly useful to consider, but I'm less convinced that such consideration should be in the spec itself before particular other transport mappings are defined.

[alabou]

I'm not expecting to open and update all the format specifications every time a new transport is defined. My understanding is that NMOS has the objective to be able to add new transports easily in the future. We already have NDI and MPEG2-TS activities to add new transports. We should at least consider them in current and new format specifications.