decklink: Mode enum order has changed since 1.16

added Blocker label

Are we going to do anything about this or just document it as a breakage?

Seems somewhat unfortunate if it's just for aesthetic reasons since the mode property is pretty widely used/essential for decklink elements, no?

I'm fine with reverting it but I'm worried people will be confused about things being in the wrong order and file bugs because they think some mode is not implemented (and instead is just in the middle of all the other modes).

@tpm What do you think? I'm fine with reverting if you think the above is not going to be a problem.

I'm fine with reverting it but I'm worried people will be confused about things being in the wrong order and file bugs because they think some mode is not implemented (and instead is just in the middle of all the other modes).

Maybe we could add a param spec flag like SORT_HINT_NICK or SORT_HINT_DESCRIPTION and then sort the output in gst-inspect/docs?

That would sort 1080, 2160 (4k), 2k, 720, NTSC, PAL :) Not really an improvement without having some kind of "sort key" that can be specified by the plugin.

Well it would sort things together by resolution, which should address your concern of users not seeing options because they're not grouped together, no?

Not clear to me that it matters that the resolutions are not 'in order'.

I don't see how we can accommodate a sort key, unless we include it as part of the description string, e.g. 0001|Here goes description or 'Description [0001]` and split it off or remove it before outputting that.

This is the only thing I can think off to address your concern.

Personally I don't think it's a big problem if things aren't grouped and if users complain about that we'll just have to close it as 'look harder / wontfix' ;)

Ok, let's revert to random order then while keeping backwards compatibility with 1.16 with the integer values and if this becomes a problem we can either a) sort it once and for all when moving to -good, b) implement some kind of sort key (we could add some qdata to the type...)