Consider adding media thumbnail exchange with media servers

[nickspencer-gh]

You can use the Preview tab ^ above to see final rendering of your report.

Is your feature request related to a problem? Please describe.
There is no "modern" solution to CITP thumbnail exchange. NDI is great for the streaming previews, however when selecting media in a media server personality, having thumbnail references can be extremely useful

Describe the solution you'd like
Include thumbnail exchange in some capacity with MVR exchange, or if more applicable in GDTF however I think MVR may be the more accurate place to contain this information.

Describe alternatives you've considered
Continuing use of CITP - this is not ideal as it is outdated and extremely difficult to keep working as everyone seems to be dropping support for CITP
Require users to have a GUI interface of media servers FOH - This is a good alternative but in an ideal world not having this as a requirement for programming is better

Additional context

Ultimately trying to find a suitable replacement for CITP. Many users report wanting CITP thumbnail exchange back but lack a unified method of doing so with CITP support dwindling amongst manufacturers.

[petrvanekrobe]

Hi @nickspencer-gh ,

thank you for reaching out and some of the details. Honestly curious questions. We (at Robe) had previously implemented MSEX into some of our Digital products (media server based moving heads) and the MSEX was a suitable protocol to allow our products to interact with other applications. What is preventing other applications to implement/keep the existing implementation of the MSEX? What are the limitations for you and what might be the reasons for others to drop support for it? How would a new thumbnail exchange protocol improve the situation of applications be willing to implement it? Can you list some of the issues that MSEX has and how a new thumbnail exchange would solve it?

Thank you
Petr

[nickspencer-gh]

Hello @petrvanekrobe ,

Thanks for your feedback! Sorry for the delay in replying I got a bit side tracked.
We at Green Hippo have also implemented MSEX/CITP over the years as well into the product and that has worked to varying degrees of success over the years.
I think there are a couple of barriers to entry utilizing MSEX/CITP moving forward

One issue is that it appears the actual spec sheet has gone away. While we can still access the bitbucket and get the code etc it poses more of a challenge to any newcomer into the space who wants to participate. For us specifically it is not the end of the world to continue MSEX support and we're happy to do so, just trying to think of others who may not have that currently implemented or the desire to spend the time to implement. It also appears from an outsider perspective as though this isn't something which is widely supported or in any active use since it is now stuck in a sort of archival state.

Another is full interoperability / adoption of the protocols. Not all manufacturers seem to be willing to commit to implementing this in their product, both from media server side and lighting console side. So it to date is not accepted everywhere.
Arguably I am not necessarily advocating that we re-invent the wheel and if the broader audience thinks it's best to use MSEX that is fine, I just think it should then officially be part of the spec for MVR.

Ultimately I think that defining a standard for thumbnail exchange is very important, whether thats utilizing MSEX or developing something different as to my knowledge there is nothing currently in the spec of MVR to facilitate this. (that being said I am not fully versed end to end if that satement is correct, so there could be something provisioned for that I am missing).

Thanks,
-Nick

[AndriiVoitenko]

Hello @petrvanekrobe and @nickspencer-gh

earnestly speaking there is already a possibility to transport thumbnails over GDTF. And as far as you are already speaking about CITP protocol, then CITP for thumbnail exchange used a MSEX- EThn message, which contained among others a library number (or up version 1.2 library ID, which was nothing else then just array from 4 numbers for folder and up to 3 level of subfolders) + element number and thumbnail.
Similar to that you can already now in GDTF for each library create a wheel, for each element in a library create a wheel slot and link channel functions from your clip controlling channel to a wheel and channel sets to a wheel slots. Of course, you would also need to create a mode dependency between clip channel functions and library control channel functions.

Example let’s say we have 2 library, in a first library we have 2 clips, and in a second library 1 clip. Here are the wheels:

<Wheel Name="Library 1">
    <Slot Name="Thumbnail 1" MediaFileName="thubnail_1_1.png"/>
    <Slot Name="Thumbnail 2" MediaFileName="thubnail_1_2.png"/>
</Wheel>
<Wheel Name="Library 2">
    <Slot Name="Thumbnail 1" MediaFileName="thubnail_2_1.png"/>
</Wheel>

And here is a dmx channel part

<DMXChannel DMXBreak="1" Offset="1" DefaultChannelFunction="MEDIA BANK.Library selection">
    <LogicalChannel Attribute="MEDIA BANK">
        <ChannelFunction Name="Library selection" Attribute="MEDIA BANK">
            <ChannelSet Name="Library 1" DMXFrom="0/1"/>
            <ChannelSet Name="Library 2" DMXFrom="1/1"/>
            <ChannelSet DMXFrom="2/1"/>
        </ChannelFunction>
    </LogicalChannel>
</DMXChannel>
<DMXChannel DMXBreak="1" Offset="2" DefaultChannelFunction="MEDIA CLIP.Clip selection library 1">
    <LogicalChannel Attribute="MEDIA CLIP">
        <ChannelFunction Name="Clip selection library 1" Attribute="MEDIA CLIP" Wheel="Library 1" ModeMaster="Geometry_MEDIA BANK.MEDIA BANK.Library selection" ModeFrom="0/1" ModeTo="0/1">
            <ChannelSet Name="Clip 1 Bank 1" DMXFrom="0/1" WheelSlotIndex="1"/>
            <ChannelSet Name="Clip 2 Bank 1" DMXFrom="1/1" WheelSlotIndex="2"/>
            <ChannelSet DMXFrom="2/1"/>
        </ChannelFunction>
        <ChannelFunction Name="Clip seletion library 2" Attribute="MEDIA CLIP" Wheel="Library 2" ModeMaster="Geometry_MEDIA BANK.MEDIA BANK.Library selection" ModeFrom="1/1" ModeTo="1/1">
            <ChannelSet Name="Clip 1" DMXFrom="0/1" WheelSlotIndex="1"/>
            <ChannelSet DMXFrom="1/1"/>
        </ChannelFunction>
    </LogicalChannel>
</DMXChannel>

Now it is a question, is this thumbnail exchange should be a part of GDTF or MVR. My personal opinion - both. Most probably media server manufacture already has some default libraries and clips on board, so to be able use it "out of the box" it must be defined in a GDTF file. On the other hand, I assume that operators will add their content to a media server and most probably different content to a different layer, so thumbnails will be instance specific and not a type specific. Therefore MVR should overwrite / extend thumbnails defined in a GDTF file. And overwrite is a correct term for that, as far as we have an Overwrites child in a fixture node of MVR, which allows overwrite for each Fixture one or more wheels (means also thumbnails).

So earnestly speaking we already have a thubnails exchange over MVR. One issue which I currently see, is that MVR can overwrites a Wheel but not a channel functions and channel sets. In previous example there is only 2 channel sets defined in "Clip selection library 1" channel fucntion. And even if MVR file overwrites wheel "Library 1" with a new wheel, which contains 20 clips new channel sets would not be created. So to solve it initial GDTF file for layer must contain a maximum amout of channel sets and channel functions, which are allowed.

[petrvanekrobe]

Thank you @AndriiVoitenko for the comment, i think this is a good concept and if we are to expand on it, it would be valuable to have @nickspencer-gh 's feedback.

[nickspencer-gh]

Thanks @AndriiVoitenko and @petrvanekrobe . I agree that it should live in both MVR and GDTF for exactly the reasons you describe.

I think solving in the initial GDTF with the max amount of channel sets and functions makes sense, the only question is would the Name field for those channel sets update at all? I seem to remember that with CITP you could get Clip names across and to update (although my memory could be wrong). I assume not as if we're not able to create new channel sets then I also assume we would not be able to "update" said channel sets.
I don't think this is necessarily a barrier that should stop us from pushing forward with this, but do know it is something users would appreciate. Not sure what it would take to define that in the spec and if it's even possible at this point.

[AndriiVoitenko]

Hi @nickspencer-gh , you are right, overwrite in MVR will not change channel set name, but it would change wheel slot name. So, the clip names would be in a wheel slot and it is up receiver application to use wheel slot names instead of channel set names if channel set linked to a wheel slot.

[petrvanekrobe]

@AndriiVoitenko right now the overwrites refer to a single universal template, it perhaps would be beneficial to allow linking to another GDTF?

[AndriiVoitenko]

@petrvanekrobe yes. Here is a current overwrite description from a specification:

Ans if there is 20 Mediaservers in MVR file and each has his own overwrites, then it will ends up with 20 sets of wheels in one GDTF file. The question would be is it a valid use case, that media servers shares clips and folders, or in other words should it be overwritten with universal template, or directly in overwrites as individual part for a fixture.

[nickspencer-gh]

@AndriiVoitenko Typically (at least in my experiences) It's common to have all servers on a show share the same media clip/folder indexing as this makes it more straight forward to program. There are some instances where this is not the case, however I'm not sure it's something we absolutely need to cater to (CITP never did without additional fixture types I believe).

If it's easy enough to allow for the direct overwrite then it might be a cool thing to explore