Constraints missing..

[a1800bert]

Our device ENCAP (SDI to 2110 for example) does not accept having no audio channel, which makes sens for us, why sending st2110 stream without any audio channel...

But there is no way to indicate that constraint in the IS08 (or we missed it). Therefore, we fail some test in the testsuite, because they are setting all channels to NULL.. therefore, not sending anything, and our business validation reject this... So we will not pass the testsuite.. for something that make sens for us...

Is there a way to do so?

[garethsb]

After some discussion, I think there is general agreement that it would be beneficial to allow devices to indicate that an Output does not support null.

In fact, I see that the schema for the output /caps endpoint allows that "routable_inputs" include an explicit null in the array.

Does that imply that a device that supports nullable Outputs MUST include null, and that one that doesn't simply omits this? @simonrankine?

[simonrankine]

Indeed - if memory serves that was my intention here as I think this came up in the original IS-08 discussions. As you say, a device without the capability to disconnect outputs would omit null from the array in /caps.

[a1800bert]

That is not the exact same issue I was referring to.

Out device support having some output set to NULL, but does not allow all output to be set to NULL. For example, an st2110-30 IP stream does not make sens with a 0 channel configuration.

[garethsb]

Sorry, @a1800bert, I'm not sure I quite follow.

a 0 channel configuration

By this do you mean N channels of silence?
An 8-channel Output will always transmit 8 channels, right? Putting null just makes a channel silent?

If you can have up to 7 channels of silence (null), but not 8, that seems more of an edge case.

[a1800bert]

I agree it would end up in 8 channel silence... but was is the use case to send 8 channels of silence? This will end up in consuming bandwidth for nothing no?

[garethsb]

It means there's a stream, which a Receiver can be connected to now, on which the channel mapping could be changed in the future?

[a1800bert]

Currently in one of our implementation, it is ALMOST the case. The channel mapping CAN be changed, but cannot be set to silence... It is not the best use case, I agree...

If the channel count changes, then a SDP patch is necessary in that case anyway. But once the channel mapping is done, our IP stream sender cannot send mute (in that product)