Mixed 2022-6/2110 inputs are not supported

[kierank]

2022-6 is type "mux" and 2110 is "video". This means than an input can't be selectable as either 2022-6 or 2110 in the real world.

Duplicating our UUIDs and making them codependent to solve this problem is unworkable (e.g what to do if user sets master_enable on both)

Allow 2022-6 to be of type video as by definition it will contain video.

[garethsb]

e.g what to do if user sets master_enable on both

Reject the PATCH that sets a second master_enable --> true?

[kierank]

e.g what to do if user sets master_enable on both

Reject the PATCH that sets a second master_enable --> true?

So then it requires parking (master_enable=false) boths inputs to be able to switch over?

What vendors (e.g GV) have done in reality is make 2022-6 a video and it's by far a better solution. Forcing 2022-6 mux is doing so purely in the name of intellectual purity.

[garethsb]

So then it requires parking (master_enable=false) boths inputs to be able to switch over?

Or go the other way and accept the PATCH and at activation, set master_enable to false automatically on the other one...

But...

What vendors (e.g GV) have done in reality is make 2022-6 a video and it's by far a better solution. Forcing 2022-6 mux is doing so purely in the name of intellectual purity.

Agreed... it's worth the experiment whether the current spec would allow, and existing Controllers would handle, connecting:

• a Sender associated with a Flow compliant with video_coded.json schema, with format of video and media_type of video/SMPTE2022-6
• a Receiver with format of video and media_types including video/SMPTE2022-6

I think they might.

[kierank]

So then it requires parking (master_enable=false) boths inputs to be able to switch over?

Or go the other way and accept the PATCH and at activation, set master_enable to false automatically on the other one...

But...

What vendors (e.g GV) have done in reality is make 2022-6 a video and it's by far a better solution. Forcing 2022-6 mux is doing so purely in the name of intellectual purity.

Agreed... it's worth the experiment whether the current spec would allow, and existing Controllers would handle, connecting:

* a Sender associated with a Flow compliant with _video_coded.json_ schema, with format of video and media_type of video/SMPTE2022-6

* a Receiver with format of video and media_types including video/SMPTE2022-6

I think they might.

Either the logic is in the controller or in the node but this codependency needs to be done somewhyere.

[garethsb]

One question: would your Receiver, when in 'video/SMPTE2022-6' mode, be doing something with the audio and ancillary data It received?

[kierank]

I believe there are a small number of facilities that do TR-04 and would expect to process the audio. In our case I think we'd probably have our NMOS node set master_enable=false to the audio/ancillary in 2022-6 mode as we don't use it. Kieran

…

On Tue, 19 Dec 2023, 19:25 Gareth Sylvester-Bradley, < ***@***.***> wrote: One question: would your Receiver, when in 'video/SMPTE2022-6' mode, be doing something with the audio and ancillary data It received? — Reply to this email directly, view it on GitHub <#211 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABDEEF3WZPSD77TZ2VSLL3YKHS2DAVCNFSM6AAAAABAWY244CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRTGM2TCNRRHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>