Question about `parameter_sets_flow_mode` and `parameter_sets_transport_mode`

[garethsb]

Informative note: When an H.264 Flow is not directly associated with a Sender but with a multiplexed Flow through the Flow's parents attribute, the Sender does not provide H.264 format-specific attributes. A Sender provides such attributes only when the H.264 Flow is directly associated with it.

Sender attributes should describe aspects of the transport mapping. A transport mapping may of course be format-specific (all the RTP payload mappings).

The attributes parameter_sets_flow_mode and parameter_sets_transport_mode associated with an H.264 Flow that are described in this section get their respective default value of dynamic and in_band.

This therefore doesn't sit quite right for me. If these are related directly to the format, i.e. codestream, they should be Flow properties. If they are related to transport of the format, they could apply to other transports besides the basic RTP payload mapping, couldn't they? Why should these properties be fixed for all mux or alternative single essence transports of H.264?

An H.264 Flow's behviour is dictated by the dynamic and in_band modes when there is no associated Sender. See the Sender's format specific (multiplexed) specification for details.

bcp-006-02/docs/NMOS With H.264.md

Line 135 in 400435c

Informative note: When an H.264 Flow is not directly associated with a Sender but with a multiplexed Flow through the Flow's parents attribute, the Sender does not provide H.264 format-specific attributes. A Sender provides such attributes only when the H.264 Flow is directly associated with it. The attributes `parameter_sets_flow_mode` and `parameter_sets_transport_mode` associated with an H.264 Flow that are described in this section get their respective default value of `dynamic` and `in_band`. An H.264 Flow's behviour is dictated by the `dynamic` and `in_band` modes when there is no associated Sender. See the Sender's format specific (multiplexed) specification for details.

[alabou]

"Why should these properties be fixed for all mux or alternative single essence transports of H.264?"

Out of band parameter sets are transported through an SDP transport file or some other unspecified out-of-band transport. In the case of MPEG2-TS they are required to be transported in-band and as we do not have a parameter_sets_transport_mode attribute on a Sender of format MUX the default value specifying the behavior must be "in-band"

We have the same reasoning for the flow mode. As we do not have a parameter_sets_flow_mode attribute on a Sender of format MUX the default value specifying the behavior must be "dynamic". An MPEG2-TS stream does not have restriction about changing parameters of a stream.

Note that when an H.264 Flow is directly associated with a Sender, such Sender has the parameter_sets_flow_mode and parameter_sets_transport_mode attributes, so "alternative single essence transports of H.264" assuming here non-RTP, have all the flexibility of using these parameters. It is only multiplexed Senders that automatically get the default behavior.

[garethsb]

You state this as fact:

as we do not have a parameter_sets_transport_mode attribute on a Sender of format MUX

When that is just a fact of the current work in progress.

If it causes issues such as having to specify a default that may not be appropriate for all mux transports, then why not revisit this?

[alabou]

The issue with MUX transport is that there may be multiple Flows in a stream associated with a Sender. For the attributes parameter_sets_transport_mode and parameter_sets_flow_mode to make sense for a MUX it would mean that ALL the Flows follow the same behavior. If this seems a possible scenario then we could allow a MUX format specification to define those attributes such that ALL the Flows getting into the MUX will behave not according to the default but according to the MUX definition (a MUX Sender can override the default provided by the format specification of all the Flows). Would it be better? Note that the default value are not restrictive at all. Is it the objective to be able to restrict the MUX?

[garethsb]

That's a really good point. Does it tell us this information would be better represented in a different way, I'm not sure... certainly another issue related to mux transports in general.

[alabou]

It would be nice to look at an example where you see the current approach of defaulting to dynanic and in_band is causing a problem for mux Senders.

At today's meeting Andrew Krupiczka was also of the opinion that for a mux Sender there should be no restrictions and that transporting the parameter_sets in_band and not having any restriction on the flow was appropriate.