Specifying the order of virtual tracks

[dtatut]

Some businesses require/mandate that the virtual tracks must be present in the CPL in a specific order. Currently this is not really possible or obvious (initially the order of presence in the delivery schema was suggested, but that was too weak). Therefore I suggest the following:

• for the VirtualTrackList element, add an attribute called "sequence"
• that attribute shall have two possible values: unordered and ordered
• the default value for the sequence attribute shall be "unordered"

[fschleich]

I would prefer to learn more about the need for this and the use-case first, before discussing solutions to a problem that I don't understand. Could some of those businesses elaborate?

[palemieux]

Could some of those businesses elaborate?

+1

I am having a hard time thinking of a reason to require a specific Virtual Track ordering since ordering is not used/enforced by the specifications.

[dtatut]

@fschleich @palemieux : This problem is not related to the way IMF CPLs specify tracks, but unfortunately related to the way some "IMF-ready" tools (available in the market) expect tracks to be arranged. Moreover, some studios seem to have expectations on the track order as well.

For the upcoming call, Dave Kneeland/Fox is supposed to clarifiy the position of his team on this matter.

In general this problem is only related to the audio tracks. The real question is how to clearly identify the presence (or absence) of a certain audio virtual track, especially when the soundfield group and channel layout identical across several tracks. Obviously a good way would be to make a better use of the MCA metadata. Unfortunately, so far, we only had very limited feedback.

Any thoughts, feedback and alternatives are obviously welcome.

[palemieux]

related to the way some "IMF-ready" tools (available in the market) expect tracks to be arranged.

Thanks for the clarification. It would be good to understand if this is related to a deficiency in the specifications, or merely a bug in a tool.

[dtatut]

@palemieux : most of the time it's a limitation of the tool. But not only. In general the order of the audio tracks (often confused with audio channels) follows what I like to call a "natural order". Delivery specifications are in most cases, highly inspired by their defunct (crossing fingers!) counterparts for tape-based workflows.

My problem here is how can we help with the transition process. My proposal above is meaningless for modern workflows, especially for proper IMF implementations. Nevertheless, I cannot ignore the reality and this transition that will certainly take longer than expected.

While I agree with @fschleich and yourself, the proposal above is only to be used by those who need it. If a studio does not want to rely on such legacy, then the studio can simply omit the attribute, as explained. So the attribute is not impacting everyone, but only those who need a specific track layout.

[fschleich]

My problem here is how can we help with the transition process. My proposal above is meaningless for modern workflows, especially for proper IMF implementations. Nevertheless, I cannot ignore the reality and this transition that will certainly take longer than expected.

My concern is that giving this some "legitimacy" by supporting it in the schema might lead users to specifying track orders simply because they don't know better. I don't want to miss the opportunity to discuss this with the folks that rely on an ordered sequence, to make sure this requirement is based on a real need and not misunderstandings.

[palemieux]

Can a test vector be designed to trigger this behavior? It could included in an upcoming plugfest.

In the meantime I would resist enshrining a behavior that fundamentally conflicts with object-based / component-based media.

[MarcAntoine-Arnaud]

Do you think it can start a discussion to generate some exhaustive CPL cases to provide a list of required support (IMF tools can build their unit tests with them).
It's already done for lot of W3C specifications (like IMSC, RDF, etc.)

[dtatut]

@fschleich : I think we need to create that oppotunity and we have a platform for doing this: the IMFUG. Let's bring up this topic and ask the members at the next UG session. Maybe not to get a final decision, but at least to ask them to collect feedback for the session after.

@palemieux : yes definitely. Also since this is essentially related to audio tracks, I would suggest to combine this with (apparently) a necessary test vector on MCA.

@MarcAntoine-Arnaud : like I said above, IMFUG seems the right platform for me.

What do you think?

[dkneeland]

For the upcoming call, Dave Kneeland/Fox is supposed to clarifiy the position of his team on this matter.

I don’t think that type of check should be within the Delivery Schema, due to the fact that the IMF standard does not mandate what the order of tracks should be. If we decide as a group that we do care about the track order, then it should be added to the standard first and then inherited by the Delivery Schema.

With that said, I do agree with @dtatut that the track order is an important thing due to legacy IMF implementations, and that this should be a conversation we should have at the next IMFUG.