Proposal for Standardised NDI Contribution Markup
This page contains a technical proposal which is not currently a published or formal standard. If you have comments or feedback on the content of this proposal PLEASE contact us with your contribution.
The published NDI IP Video protocol SDK does not currently offer any guidance on carriage of encoded Dolby E streams within NDI Streams. Since NDI uses floating point rather than integer audio, Dolby E cannot simply be carried in the normal way using a stereo integer audio track. However, NDI has metadata mechanisms which could easily carry this information. This document is a proposal to provide simple standardised support for NDI carriage of Dolby E, in order to prevent different implementations by each vendor by way of a recommended practice technical note.
The focus is based on the need to carry an encoded Dolby E stream within an NDI video stream such that it can be replicated, decoded or otherwise reconstructed later in the production workflow.
The mechanism used leverages NDI's option to attach packet specific metadata to standard floating point NDI audio data packets. The encoded Dolby E data is base64 encoded and wrapped in a <DOLBY_E> XML tag - then attached to audio packets as metadata. The Dolby E data which should have the equivalent pacing and data rate as uncompressed stereo audio should be aligned with equivalent sized audio packets. For example a floating point NDI audio packet with 1920 stereo audio floating point samples would contain 7680 original Dolby E bytes, encoded base64 which would then represent something over 10000 characters of ascii metadata attached to the audio packet. This relationship of Dolby E to Floating point samples is essential to ensure the timestamping of the audio packet continues to correlate with the timing of the Dolby E encoded audio.
An important part of this standard is to define best practice - and in this case the floating point audio track to which the Dolby E metadata is applied *must* be an unencoded (typically stereo) representation of the same audio data carried by the Dolby E, for example the left / right channels extracted from the Dolby E. Note that the 'carrier' audio track does not have to be stereo, and it could even be a 6 channel floating point track which carries all the same unencoded data as the Dolby E metadata attached.
The intention is that NDI devices incapable of processing Dolby E can access an 'equivalent' audio stream using the floating point data within that NDI Audio stream rather than the Dolby E metadata, thus providing a consistent and predictable viewer experience.
Basic Example :
NOTE : Care should be taken when NDI Streams are fed through downstream NDI frame synchronisers since this will affect the carriage of DOLBY E metadata. NDI Frame Synchroniser stages should be avoided in the NDI:DOLBY_E process chain.
Since Dolby E has a defined 'frame' structure which is intended to be aligned with picture frames, it is strongly recommended that NDI Streams containing Dolby E have precisely aligned audio and video packets, where one audio packet corresponds to one video packet. This will ensure that Dolby E 'frames' are always complete within the boundaries of a frame and should mean that NDI Routing processes which change stream connections will offer a 'clean' switch when moving between Dolby E data sources.
NB: If this is a concern, it may be advisable to connect the <DOLBY_E> packets as metadata to the VIDEO frames, instead of the AUDIO. In this case a typical NDI Frame Sync process would repeat or skip entire Dolby E Frames, something which is anticipated in the Dolby E standard and which should be tolerated. A follow up to this recommended practice will clarify 'best practice' once that has been determined through implementation.
If you have any questions, or you would like to engage Sienna for NDI Consultancy or Custom Development, please contact info @ sienna.tv
useful reference: http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP175.pdf
appsupport @ gallery.co.uk