RP-NDI-KLV_2022_07
proposal for carriage of KLV information in NDI metadata
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.
NB: The use of this specification for military or defence applications is strictly prohibited.
This proposal defines a standardised wrapper to carry decoded KLV real time metadata over NDI by way of a recommended practice technical note.
Basic Premise:
This recommended practice provides a mechanism for an MPEGTS decoder to extract KLV data from a stream and pass this onto an NDI system to action the message. The same specification can be used to pass this data via NDI into a transport stream encoder which supports this protocol.
In this proposal, the KLV Data is carried in an KLV stream within an MPEG Transport Stream. It translates into the real time (non frame based) NDI Metadata stream, with KLV message data enclosed as <KLV>
Sent Messages are wrapped in the outer XML tag <KLV>
The KLV data content should be either of 2 forms implied by the content in the KLV tag, raw, or decoded. In the case of raw it should conform to SMPTE 336M, written as Base64 encoded text within a <ST336M> tag. When presented as decoded, it should take the form of a single Key Value pair, where the Key is the 16 byte SMPTE Universal Label in text based hexidecimal with a dot between each 4 byte segment (for readability), and the value is tagged as either uft8 (where the value is unambiguously pure text data), or binary data - and where binary it should be Base64 encoded and for text UFT8.
The decoded data does not include the length data, since once of the main reasons to decode prior to carriage in NDI is to bypass the complexities of the 336M length encoding. The data length is implied by the value tag extents.
It is allowed to include both representations, but in this case it is absolutely essential that the two representations are identical in content such that there is no ambiguity when reading the data in another system which can take either representation for the same content.
KLV data in Transport 336M is designated as unsynchronised, so the reference time for the data is simply real time in context.
Note that BER "indefinite" length data is not supported in this specification which is by definition, finite.
NDIlib_metadata_frame_t meta_data
meta_data.p_data =
<KLV>......</KLV>
Examples
<KLV>
<ST336M encoding="Base64">Bg4rNAILAQEOAQMBAQAAAIGRAggABGyOIAODhUEBAQUCPTsGAhWABwIBUgsDRU9ODA5HZW9kZXRpYyBXR1M4NA0ETcTcuw4Esahs/g8CH0oQAgCFEQIASxIEIMjSfRME/N0C2BQE/rjLYRUEAI8+YRYEAAAByRcETd2MKhgEsb6e9BkCC4UoBE3djCopBLG+nvQqAguFOAEuOQQAjdQpAQIcXw==</ST336M>
</KLV>
<KLV>
<key>060E2B34.020B0101.0E010301.01000000</key>
<value encoding="Base64">AggABGyOIAODhUEBAQUCPTsGAhWABwIBUgsDRU9ODA5HZW9kZXRpYyBXR1M4NA0ETcTcuw4Esahs/g8CH0oQAgCFEQIASxIEIMjSfRME/N0C2BQE/rjLYRUEAI8+YRYEAAAByRcETd2MKhgEsb6e9BkCC4UoBE3djCopBLG+nvQqAguFOAEuOQQAjdQpAQIcXw==</value>
</KLV>
<KLV>
<key>060E2B34.020B0101.0E010301.01000000</key>
<value encoding="UTF8">Some plain text data</value>
</KLV>
<KLV>
<ST336M encoding="Base64">Bg4rNAILAQEOAQMBAQAAAIGRAggABGyOIAODhUEBAQUCPTsGAhWABwIBUgsDRU9ODA5HZW9kZXRpYyBXR1M4NA0ETcTcuw4Esahs/g8CH0oQAgCFEQIASxIEIMjSfRME/N0C2BQE/rjLYRUEAI8+YRYEAAAByRcETd2MKhgEsb6e9BkCC4UoBE3djCopBLG+nvQqAguFOAEuOQQAjdQpAQIcXw==</ST336M>
<key>060E2B34.020B0101.0E010301.01000000</key>
<value encoding="Base64">TBC</value>
</KLV>
If you have any questions, or you would like to engage Sienna for NDI Consultancy or Custom Development, please contact info @ sienna.tv