Материал: part17

Figure PPPP.7-3. Example of implementation for Augmented reality based on digital image​

PPPP.8 Storage Considerationa​

PPPP.8.1 Creating IOD From DICOM-RTV Streams​

It is reasonable to take some or all of an DICOM-RTV stream to create storage DICOM IOD. Transcoding the patient metadata and​ video content should be relatively straightforward. Some of the issues that have to be considered include how to get information de-​ scribing origin equipment, etc.​

Storage of video data, even received in real-time, is possible. However, how to initiate a DICOM-RTV stream based on a stored video​ is presently not described in the standard. Also, how to encode directly a received DICOM-RTV stream into a DICOM Video Instance​ is not fully described. An external decision (manual or automatic) is required to specify at least the start time and the end time of the​ portion of the stream to be stored. However, some principles can be established to ensure that receiving applications will actually find​ in the DICOM-RTV flow all the data items needed for the replay or storage of this data using DICOM Storage services. Regarding​ storage of this data using DICOM Storage services:​

•​"Pixel Data" and "Waveform Data" attributes of the DICOM (video) Composite Objects should be mapped from the corresponding​ payloads in media (e.g., video and audio) flows and associated SDP objects;​

- Standard -​

•​The metadata attributes of the DICOM composite objects should be mapped from the DICOM-RTV metadata flows; attributes ap-​ plicable to all frames (e.g., included in the Current Frame Functional Group Sequence) should be mapped from the static part of​ the DICOM-RTV metadata; attributes applicable to a single frame (e.g., Per-frame Functional Group Sequence) should be mapped​ from the dynamic part of the DICOM-RTV Metadata;​

•​The "Cine" and "Multi-frame" modules, as well as the "Number of Waveform Samples" attribute, not present in the DICOM-RTV​ Metadata, are built from the values of the RTV Meta Information (e.g., Sample Rate) , the dynamic payload of the relevant flows​ (e.g., Frame Numbers) and the external decisions (e.g., Start Time) ;​

•​Based on the choice of the application and on the possible presence of a DICOM-RTV Rendition flow, the DICOM composite object​ to be stored may gather or not the individual essences of the DICOM-RTV flows (e.g., video and audio contents in a single SOP​ instance using a MPEG2 Transfer syntax).​

PPPP.8.2 Streaming DICOM-RTV From Stored IOD​

Regarding initiating a DICOM-RTV stream from a stored instance, the application should be able to regenerate the different DICOM-​ RTV flows, with the same synchronization characteristics, in compliance with SMPTE ST 2110-10.​

•​Subcase 1 is conventional video IODs e.g., ultrasound video/multi-frame or angio video/multi-frame.​

•​Subcase 2 is one or more video IODs that were previously DICOM-RTV, e.g., stored like PPPP.8.1.​

•​If the multiple stored IOD of the subcase 2 contain synchronization information extracted from DICOM, it should be possible to​ playback them with a good synchronization.​

PPPP.9 Example of Engineering Implementation​

AnexampleofimplementationoftheVideo-to-DICOMconverterpresentedintheusecasesPPPP.2abovecouldrespectthefollowing​ approach:​

•​The metadata are sent from the Departmental System to the Video-to-DICOM converter through TCP/IP using classical protocols​ as DICOM Worklist or HL7 ORM.​

•​The video/multi-frame is sent through coaxial cable using classical video protocol (e.g., uncompressed HD video over Serial Digital​ Interface SDI).​

•​The time ("timestamp") is sent through IP respecting PTP, for synchronizing all the senders and receivers, through "time alignment"​ mechanism described in SMPTE ST 2110-10.​

•​All this information is used to produce several RTP sessions over IP:​

•​SMPTE ST 2110-20 compliant video flow.​

•​SMPTE ST 2110-10 compliant DICOM Metadata Flow, including payload header (RTV Meta Information) as well as dynamic​ payload part (DICOM Current Frame Functional Groups Module) for every frame, and including additionally the static payload​ part (DICOM Real-Time Video Endoscopic/Photographic Image IOD Modules) at least every second.​

•​If sound is provided:​

•​SMPTE ST 2110-30 compliant audio flow.​

•​SMPTE ST 2110-10 compliant DICOM Metadata Flow, including payload header (RTV Meta Information) as well as dynamic​ payloadpart(DICOMCurrentFrameFunctionalGroupsModule)foreverysample,andincludingadditionallythestaticpayload​ part (DICOM Real-Time Audio Waveform IOD Modules) at least every second.​

•​SMPTE ST 2110-10 compliant DICOM Metadata Flow, including payload header and static payload part (DICOM Rendition​ Selection Document IOD Modules) , at least every second, in order to associate the two flows above.​

Note​

Eventually, the laparoscope systems will embed the Video-to-DICOM converter, as shown in the Integrated Product box of​ the Figure PPPP.2-1.​

- Standard -​

PPPP.20 Transmitting a Stereo Video​

The particular case of stereo vision, may either be solved by combining the contents into a single flow (Multiview video Coding) with​ inclusion of the C.7.6.28 Real-Time Acquisition Module in the metadata, or by separating contents into two flows (left content apart​ from right content) and then pairing them by using a (RTV Stereo Video) Rendition.​

- Standard -​

- Standard -​

QQQQ Transport of Elementary Stream over​ IP (Informative)​

Carriage of audiovisual signals in their digital form across television plants has historically been achieved using coaxial cables that​ interconnect equipment through Serial Digital Interface (SDI) ports. The SDI technology provides a reliable transport method to carry​ a multiplex of video, audio and metadata with strict timing relationships.​

The features and throughput of IP networking equipment having improved steadily, it has become practical to use IP switching and​ routing technology to convey and switch video, audio, and metadata essence within television facilities.​

Existing standards such as SMPTE ST 2022-6:2012 have seen a significant adoption in this type of application where they have​ brought distinct advantages over SDI, albeit only performing Circuit Emulation of SDI (i.e.; Perfect bit-accurate transport of the SDI​ signal contents).​

However,theessencemultiplexproposedbytheSDItechnologymaybeconsideredassomewhatinefficientinmanysituationswhere​ a significant part of the signal is left unused if little or no audio and/or ancillary data has to be carried along with the video raster, as​ depicted in Figure QQQQ-1 below:​

Figure QQQQ-1. Structure of a High Definition SDI signal​

Note​

Acronyms on the Figure QQQQ-1 stand for: LN: line number; EAV: end of active video; SAV: start of active video; CRC:​ Cyclic Redundancy Code; HANC & VANC: horizontal & vertical ancillary data. The parentheses indicate the number of 8,​ 10 or 12 bits words used for each information.​

As new image formats such as UHD get introduced, the corresponding SDI bit-rates increase, way beyond 10Gb/s and the cost of​ equipment at different points in a video system to embed, de-embed, process, condition, distribute, etc. the SDI signals becomes a​ major concern.​

Consequently there has been a desire in the industry to switch and process different essence elements separately, leveraging the​ flexibility and cost-effectiveness of commodity networking gear and servers.​

The Video Services Forum (VSF) has authored its Technical Recommendation #3 (a.k.a. VSF-TR03) describing the principles of a​ systemwherestreamsofdifferentessences(namelyvideo,audio,metadatatobeginwith)canbecarriedoveranIP-basedinfrastructure​ whilst preserving their timing characteristics.​

The TR03 work prepared by VSF has been handed off to the Society of Motion Picture & Television Engineers (SMPTE) for due​ standardization process, resulting in the SMPTE ST 2110 family of standards. SMPTE ST 2110-10, 20 and 30 were approved on​ September 18, 2017:​

•​ST 2110-10: System Timing and definitions;​

•​ST 2110-20: Uncompressed active video;​

- Standard -​