Document best practice for signalling additional codecs and transports

[andrewbonney]

Whilst the signalling of many codecs and transport types should be obvious, some may be less clear. A couple of specific cases are noted below:

• J2K (or other) coded video in MPEG TS wrapper A J2K Flow may be transported via RTP within an MPEG transport stream. The Flow media type would be 'video/mj2' or 'video/jpeg2000', but the media type within the SDP file may be 'video/MP2T'. Alternatively the Flow could first be transformed into a new Flow with a 'video/MP2T' media type prior to it being passed on to the Sender. Clarity on the preferred signalling here is necessary to assist clients in identifying the codec used in wrapped transport formats. Similar care is necessary in identifying the matching Receiver capabilities.

• RP 2110-23 Where a video Flow is split into four (or more) pieces for transport via (draft) SMPTE RP.2110-23, there are multiple ways this could be signalled. In order to maintain consistency in the NMOS model the likelihood is that each portion of the signal should first be generated as a new Source and Flow before being sent via multiple Senders. These could then be re-combined into a single Source and Flow at the receive side. An alternative would be to use a single logical Sender and Receiver, but this presents control (and modelling) challenges, particularly where a Receiver may wish to intentionally receive a single video quadrant. This would also overload the documented purpose of the interface_bindings attributes.

[garethsb]

Rather than guidance in IS-04, perhaps we need some BCPs or just AMWA white papers covering these and some ST 2110-22 cases.

[peterbrightwell]

These two examples seem suitable for a future BCP.