Материал: part17

•​ST 2110-21: Traffic Shaping Uncompressed Video;​

•​ST 2110-30: Uncompressed PCM audio;​

•​ST 2110-40: Ancillary data.​

TheST2110familyofstandardsexpandsovertimeandthecorrespondingDICOMcomponentsmayconsideradoptingtheseextensions​ (e.g., compressed video, large metadata support…).​

Thesystemisintendedtobeextensibletoavarietyofessencetypes,itspivotalpointbeingtheuseoftheRTPprotocol.Inthissystem,​ essence streams are encapsulated separately into RTP before being individually forwarded through the IP network.​

A system is built from devices that have senders and/or receivers. Streams of RTP packets flow from senders to receivers, however​ senders have no explicit awareness or coordination with the receivers. RTP streams can be either unicast or multicast, in which case​ multiple receivers can receive the stream over the network.​

Devices may be adapters that convert from/to existing standard interfaces like HDMI or SDI, or they may be processors that receive​ one or more streams from the IP network, transform them in some way and transmit the resulting stream(s) to the IP network. Cam-​ erasandmonitorsmaytransmitandreceiveelementaryRTPstreamsdirectlythroughanIP-connectedinterface,eliminatingtheneed​ for legacy video interfaces.​

Proper operation of the ST 2110 environment relies on a reliable timing infrastructure that has been largely inspired by the one used​ in AES67 for Audio over IP.​

Inter-stream synchronization relies on timestamps in the RTP packets that are sourced by the senders from a common Reference​ Clock. The Reference Clock is distributed over the IP network to all participating senders and receivers via PTP (Precision Time​ Protocol version 2, IEEE 1588-2008).​

Synchronization at the receiving device is achieved by the comparison of RTP timestamps with the common Reference Clock.​

DICOM devices, which typically support NTP, will need to handle PTP to use this functionality, which may involve hardware changes.​ Each device maintains a Media Clock which is frequency locked to its internal time-base and advances at an exact rate specified for​ thespecificmediatype.Themediaclockisusedbysenderstosamplemediaandbyreceiverswhenrecoveringdigitalmediastreams.​ For video and ancillary data, the rate of the media clock is 90 kHz, whereas for audio it can be 44.1 kHz, 48 kHz, or 96 kHz.​

For each specific media type RTP stream, the RTP Clock operates at the same rate as the Media Clock.​

ST2110-20specifiesaverygenericmechanismforRTPencapsulationofavideoraster.Itsupportsarbitraryresolutions,framerates,​ and introduces a clever pixel packing accommodating an extremely wide variety of bit depths and sampling modes. It is very heavily​ inspired from IETF RFC4175.​

ST 2110-21 specifies traffic shaping and delivery timing of uncompressed video, in order to enable transport of multiple videos on​ the same physical network.​

ST 2110-30 specifies a method to encapsulate PCM digital audio using AES67 to which it applies a number of constraints. AES67 is​ a technical standard for audio over IP and audio over Ethernet. The standard was developed by the Audio Engineering Society.​

ST 2110-40 specifies a simple method to tunnel packets of SDI ancillary data present in a signal over the IP network and enables a​ receiver to reconstruct an SDI signal that will embed the ancillary data at the exact same places it occupied in the original stream.​

Sender devices construct one SDP (Session Description Protocol) object per RTP Stream. These SDP objects are made available​ through the management interface of the device, thereby publishing the characteristics of the stream they encapsulate, however no​ methodisspecifiedtoconveytheSDPobjecttothereceiver.ImplementationscanrelyonwebURLs,filesordocumentationonmedia,​ or it can be configured on the receiver from product documentation since it can be relatively static. This SDP object provides the basic​ information a system needs in order to identify the available signal sources on the network.​

It is worth noting that although ST 2110 currently describes the method for transporting video and audio, the same principles may be​ appliedtoothertypesofmediabyselectingtheappropriateRTPpayloadencapsulationscheme,andcomplyingtothegeneralprinciples​ defined by ST 2110-10.​

Some details of the ST 2110-10 are reproduced below for convenience. Refer to the original specifications for implementation.​

The RTP header bits have the following format:​

- Standard -​

Figure QQQQ-2. RTP Header​

The RTP header extension bits have the following format:​

header extension

...

In complement to the SMPTE ST 2110 family of standards, AMWA (Advanced Media Workflow Association) has authored a recom-​ mendation called NMOS (Networked Media Open Specifications) which specifies the following header extensions:​

PTP Sync Timestamp​ provides an absolute capture or playback timestamp for the Grain essence data, which consists of a​ 48-bit seconds field followed by a 32-bit nanosecond field. The length value in the extension header is​ 9.​

- Standard -​

PTP Origin Timestamp​ provides an absolute capture timestamp for the Grain essence data, which consists of a 48-bit seconds​ field followed by a 32-bit nanosecond field. The length value in the extension header is 9.​

Figure QQQQ-4. RTP Grain Flags​

- Standard -​

RRRR Encapsulated OBJ, 3D Model​

Grouping, & Color (Informative)​

RRRR.1 Overview​

This section explains the encapsulation of a 3D manufacturing model file of the OBJ type inside a DICOM instance. The goal of en-​ capsulating a model rather than transforming the data into a different representation is to facilitate preservation of the 3D file in the​ exact form that it is used with extant manufacturing devices. At the same time encapsulation populates DICOM header elements that​ record clinical information absent from the OBJ format, including unambiguously associating it with the patient for whose care the​ model was created. Encapsulation also makes it possible to link to the images from which the model was derived, even if these came​ from different studies.​

The OBJ encapsulation case is slightly more complicated than that of STL (Annex IIII). The OBJ has supporting files (material library​ and texture maps). The relationship between the multiple original files and the corresponding DICOM instances is shown in Fig-​ ure RRRR.1-1.​

Figure RRRR.1-1. Relationship between OBJ, MTL and Texture Map image files and corresponding​ DICOM Instances​

RRRR.2 Example Encoding of OBJ & MTL​

This Section contains example excerpts for encoding OBJ files and associated preview icons (optional), materials library file (MTL)​ (optional), and texture map images (optional).​

RRRR.2.1 Example A​

A patient, Kevin Franz-Lopez, with Medical Record Number 547892459, will shortly be undergoing a complex partial nephrectomy to​ remove lesions on their left kidney. A 3D manufacturing model (encoded in OBJ) was created to manufacture a surgical planning aid​ representing the patient's unique anatomy.​

AmodelwasconstructedfromaCTdataset(CT1).ThemodelwascreatedonJuly16,2017at1:04:34PM.Themodelwasexpressed​ as a single OBJ file (kidneymodel.obj) which makes use of two texture maps encoded using PNG (ntissue.png and fluid.png) and one​ texture map encoded using JPEG (distissue.jpg). The relationship between the OBJ and texture maps is captured in the materials​ list file (matlist.mtl). This set of files corresponds to the Encapsulated MTL and DICOM Images elements in Figure RRRR.1-1.​

A preview icon was created showing the rendered 3D object for inclusion with the OBJ file when encapsulated.​

Table RRRR.2-1 shows the Encapsulated OBJ.​

- Standard -​

Page 970​ DICOM PS3.17 2020a - Explanatory Information​

Table RRRR.2-1. Encapsulated OBJ Example A​

(mm, UCUM, "mm")​ %enditem​

...​

- Standard -​