Add audioChannelFormatIDRef sub-element to audioTrackUID

[rsjbailey]

In 2076-2, audioChannelFormatIDRef sub-element was added to audioTrackUID (enabling bypassing of audioTrackFormat and audioStreamFormat for PCM only).

Reference to an audioChannelFormat description. This element is used only if an audioTrackFormat is omitted for PCM audio. Then the ‘yyyyxxxx’ parts of AC_yyyyxxxx and AT_yyyyxxxx_zz are the same number.

Definition of done

• Able to parse an adm XML document containing an audioTrackUID with an audioChannelFormat reference, and write it back without modification
• Able to create a document with and audioTrackUID referencing an audioChannelFormat and write that to xml
• Have investigated the effort required to update libbw64 to support chna chunks containing an audioChannelFormat
• Provide user feedback in cases where both audioTrackFormat and audioChannelFormat references are present in a parsed xml (it should not be possible to write such a document using the library)

Stretch goal

• Update libbw64 to support chna chunks containing audioChannelFormat reference (if necessary)

[rsjbailey]

To discuss

• Does bypassed mean not in the file, or just that it's now possible to skip this on parsing? If the latter, best option may be to keep parsing as is & simply fill in the extra reference in the ADM model
• Should we validate the condition referenced in the standard? This element is used only if an audioTrackFormat is omitted for PCM audio
• If so at what point should that take place?
• What constitutes 'use' of an element in this context? The presence of that element in an adm document or interpreting its contents when parsing?

Relevant areas of source

audio_track_uid.hpp audio_track_uid.cpp route_tracer.hpp (maybe)

[tomjnixon]

bw64 code: https://github.com/ebu/libbw64/blob/master/include/bw64/chunks.hpp#L311-L322

[kristianhentschelbbc]

There seems to be a similar case about validation in AudioObject, with the restriction not enforced.

(We think) that AudioObject should link to either (AudioTrackUID and PackFormat), or (audioObjectUID), but not both -- but that does not actually seem to be specified in the standard text (sec 5.6) so maybe isn't quite the same.

There's a test in audio_object_tests that adds all three and does not expect an error.

Edit: this restriction is only stipulated in the EBU profile, the ADM standard lets you have both.

[kristianhentschelbbc]

We'll try and work on this in TDD fashion; I'll start by adding a test that creates an ADM document and tries to add the ChannelFormat reference to a TrackUID next.

[firthm01]

Looking at libbw64, it looks like it should just work, but you would be calling trackRef() to get the channel format ref in some cases which would seem a little illogical, and you'd still need to truncate the final 3 chars before it becomes a usable channel format ID.

It seems sensible to have a channelRef() method as well to maintain backwards-compatibility. The question is, how much ADM-specific logic should be in here? It feels like trackRef() should only return if it is a track format reference, and channelRef() only return if it is a channel format reference. We could compare the first 3 chars of the ID to do this, and either throw or return a blank string if it's not the expected type.

[firthm01]

Looking at libbw64, it looks like it should just work, but you would be calling trackRef() to get the channel format ref in some cases which would seem a little illogical, and you'd still need to truncate the final 3 chars before it becomes a usable channel format ID.

Having talked this over with @kristianhentschelbbc and @tomjnixon we decided libbw64 should probably remain as it is. BS.2088-1 (pages 16-17) still names the field "trackRef" even though it can now contain a channel format reference, and it makes sense for the method to retrieve this field (regardless of its actual content) to follow the same name.

[kristianhentschelbbc]

Merged #76 into the 2076-2 branch.