<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:dcterms="http://purl.org/dc/terms/"
     xmlns:media="http://search.yahoo.com/mrss/"
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:cf="https://www.futureplc.com/rss/content-flags"
>
    <channel>
                    <atom:link href="https://www.tvtechnology.com/feeds/tag/tr-03" rel="self" type="application/rss+xml" />
                            <title><![CDATA[ Latest from Tv Technology in Tr-03 ]]></title>
                <link>https://www.tvtechnology.com/tag/tr-03</link>
        <description><![CDATA[ All the latest tr-03 content from the Tv Technology team ]]></description>
                                    <lastBuildDate>Tue, 24 Nov 2015 09:28:00 +0000</lastBuildDate>
                            <language>en</language>
                                <item>
                                                            <title><![CDATA[ New Rec for Studio Video Over IP Approved ]]></title>
                                                                                                <dc:content><![CDATA[ <p><em>Editor’s note: The headline on Wes’s contribution originally said a new “standard” had been approved.</em> TV Technology <em>regrets the error.</em><br/><strong>ORANGE, CONN.—</strong>On Oct. 21, the Video Services Forum published TR-03 “Transport of Uncompressed Elementary Stream Media over IP” to define an interoperable way to format and identify media streams for IP network transport. This recommendation was developed specifically to address the need within modern media production facilities to have an efficient, flexible method to transport uncompressed signals of various types.<br/><br/></p><p>Previously approved standards, such as SMPTE 2022-6, require video signals to be first formatted into SDI (Serial Digital Interface) streams before they are placed into IP packets. Related audio and metadata signals are commonly embedded in the horizontal and vertical ancillary spaces (HANC and VANC) that are present within the SDI signal. This is somewhat inefficient, due to the need to de-embed the individual signals from the SDI stream before they can be processed, and then possibly re-embed them before being passed along to the next step in the processing workflow.</p><p><strong>DIFFERENT APPROACHES</strong><br/>With TR-03, each media type is transported individually as elementary streams. In the case of audio signals, the raw audio samples are placed directly into RTP/IP packets using AES67. For video, pixels from the active picture area are placed directly into RTP/IP packets in accordance with IETF RFC 4175. Metadata is handled using another IETF-proposed standard “draft-ietf-payload-rtp-ancillary-02.”</p><p>Chuck Meyer, chief technology officer, production for Grass Valley, noted the significance of the new standard. “TR-03 is very much about essence, and really separating out the media types be it video, audio, metadata and timing events,” he said. It’s just so important to keep those separate.”</p><figure class="van-image-figure pull-" data-bordeaux-image-check ><div class='image-full-width-wrapper'><div class='image-widthsetter' ><p class="vanilla-image-block" style="padding-top:56.25%;"><img id="WYMsELMCEqUUbScMd3mvtZ" name="" alt="" src="https://cdn.mos.cms.futurecdn.net/WYMsELMCEqUUbScMd3mvtZ.jpg" mos="https://cdn.mos.cms.futurecdn.net/WYMsELMCEqUUbScMd3mvtZ.jpg" align="" fullscreen="" width="" height="" attribution="" endorsement="" class="pull-"></p></div></div></figure><p><em>Fig. 1 shows the different approaches used by 2022-6 and TR-03.</em> Fig. 1 shows the different approaches used by 2022-6 and TR-03. Part A shows audio and metadata being embedded into an SDI stream that is then packetized using 2022-6 and sent through an IP network. Part B shows audio, video and metadata each being packetized into separate IP streams in accordance with TR-03. The crucial difference between these two approaches is illustrated in the steps needed to perform an audio processing function (such as loudness adjustment). In the 2022-6 process, the entire video stream must first be de-packetized and then the audio signal must be de-embedded from the SDI stream. When processing is completed, the audio must be re-embedded in the SDI before the SDI signal can once again be packetized. Contrast this with the TR-03 process shown in Part B of Fig. 1, where only the packets containing audio samples are required to be depacketized, before they are processed, and then repacketized back into an IP stream. Not only does this process remove the need for audio embedding and de-embedding, it also greatly reduces the volume of packet traffic that needs to be routed to the audio processor. As an added benefit of TR-03, note that only the active video pixels of TR-03 need to be packetized, thereby reducing the amount of network traffic generated by uncompressed video.</p><p><strong>TIMING AND IDENTIFICATION</strong><br/>Two important elements that underpin TR-03 are timing and identification. Timing is handled by distributing a common clock to every node on the network using IEEE 1588 Precision Time Protocol, and by referencing all of the media clocks to the SMPTE Epoch defined in 2059-1. Streams are identified, and, more importantly, associated with each other using SDP (Session Description Protocol; IETF RFC 4566 and The SDP Grouping Framework; IETF RFC 5888). Using these capabilities, audio and video streams can be identified as belonging to the same lip sync group and be referenced to a common clock so that they can be sent as separate IP packet streams through a network and then synchronized at the streams’ destination. Going back to Part B in Fig. 1, once the video, audio and data streams are synchronized at their source using a common clock, the streams can take different paths, with different amounts of delay, yet still be able to be realigned to a common clock at the output. An SDP file is created to indicate that the video, audio and data signals shown in Part B in Fig. 1 are part of the same lip sync group; the information in this file tells the receiving device where to find the streams and how to synchronize them.</p><p>When asked why a new standard is needed at this time, John Mailhot, CTO networking and infrastructure for Imagine Communications said “IP is a new infrastructure for the industry. 2022 has a place for interconnection between facilities and between rooms. The SVIP group was formed to address needs in the production studio. TR-03 has the flexibility that is a paramount need for this application.</p><p>“TR-03 can deliver the promise of IP networks,” he said. “It creates an extensible way to organize video, audio and metadata that can deliver all these media types in a media-agnostic fashion.”</p><p>There already appears to be a great deal of interest in this new TR, at least according to Meyer. “People noticed my name on the list of contributors to TR-03 and are calling me out of the blue—this never happened to me before. They are saying ‘Hey Chuck this is a really a cool thing. I think I’m seeing how this could really help me with my 4K transitions. Can you give me more technical details?’”</p><p>A copy of the TR-03 Draft Recommendation can be downloaded at <a href="https://www.videoservicesforum.org/technical_recommendations.shtml" data-original-url="http://www.videoservicesforum.org/technical_recommendations.shtml"><em>www.videoservicesforum.org/technical_recommendations.shtml</em></a><em>.</em></p><p><em>Wes Simpson is a member of the SVIP team that developed TR-03 within the VSF, along with representatives from dozens of other companies within the media industry.</em></p> ]]></dc:content>
                                                                                                                                            <link>https://www.tvtechnology.com/opinions/new-standard-for-studio-video-over-ip-approved</link>
                                                                            <description>
                            <![CDATA[ This recommendation was developed specifically to address the need within modern media production facilities to have an efficient, flexible method to transport uncompressed signals of various types. ]]>
                                                                                                            </description>
                                                                                                                                <guid isPermaLink="false">wvPDaxxEuzHkHtMfEEAH8K</guid>
                                                                                                <enclosure url="https://cdn.mos.cms.futurecdn.net/yMfAD5wsLGBb5eXHcQeMqa-1280-80.jpg" type="image/jpeg" length="0"></enclosure>
                                                                        <pubDate>Tue, 24 Nov 2015 09:28:00 +0000</pubDate>                                                                                                                                                                                                                                <category><![CDATA[Opinion]]></category>
                                                    <category><![CDATA[Insights]]></category>
                                                                                                                    <dc:creator><![CDATA[ Wes Simpson ]]></dc:creator>                                                                                                        <dc:description><![CDATA[ null ]]></dc:description>
                                                                                                                                <cf:isSponsored>false</cf:isSponsored>
                <cf:hasAffiliateLinks>false</cf:hasAffiliateLinks>
                <cf:isPaid>false</cf:isPaid>
                                                                                                                                <media:content type="image/jpeg" url="https://cdn.mos.cms.futurecdn.net/yMfAD5wsLGBb5eXHcQeMqa-1280-80.jpg">
                                                            <media:credit><![CDATA[null]]></media:credit>
                                                                                                                                                                                                                                                                                                                                                    </media:content>
                                                    <media:thumbnail url="https://cdn.mos.cms.futurecdn.net/yMfAD5wsLGBb5eXHcQeMqa-1280-80.jpg" />
                                                                                                                                                                    <content:encoded >
                            <![CDATA[
                            <article>
                                <p><em>Editor’s note: The headline on Wes’s contribution originally said a new “standard” had been approved.</em> TV Technology <em>regrets the error.</em><br/><strong>ORANGE, CONN.—</strong>On Oct. 21, the Video Services Forum published TR-03 “Transport of Uncompressed Elementary Stream Media over IP” to define an interoperable way to format and identify media streams for IP network transport. This recommendation was developed specifically to address the need within modern media production facilities to have an efficient, flexible method to transport uncompressed signals of various types.<br/><br/></p><p>Previously approved standards, such as SMPTE 2022-6, require video signals to be first formatted into SDI (Serial Digital Interface) streams before they are placed into IP packets. Related audio and metadata signals are commonly embedded in the horizontal and vertical ancillary spaces (HANC and VANC) that are present within the SDI signal. This is somewhat inefficient, due to the need to de-embed the individual signals from the SDI stream before they can be processed, and then possibly re-embed them before being passed along to the next step in the processing workflow.</p><p><strong>DIFFERENT APPROACHES</strong><br/>With TR-03, each media type is transported individually as elementary streams. In the case of audio signals, the raw audio samples are placed directly into RTP/IP packets using AES67. For video, pixels from the active picture area are placed directly into RTP/IP packets in accordance with IETF RFC 4175. Metadata is handled using another IETF-proposed standard “draft-ietf-payload-rtp-ancillary-02.”</p><p>Chuck Meyer, chief technology officer, production for Grass Valley, noted the significance of the new standard. “TR-03 is very much about essence, and really separating out the media types be it video, audio, metadata and timing events,” he said. It’s just so important to keep those separate.”</p><figure class="van-image-figure pull-" data-bordeaux-image-check ><div class='image-full-width-wrapper'><div class='image-widthsetter' ><p class="vanilla-image-block" style="padding-top:56.25%;"><img id="WYMsELMCEqUUbScMd3mvtZ" name="" alt="" src="https://cdn.mos.cms.futurecdn.net/WYMsELMCEqUUbScMd3mvtZ.jpg" mos="https://cdn.mos.cms.futurecdn.net/WYMsELMCEqUUbScMd3mvtZ.jpg" align="" fullscreen="" width="" height="" attribution="" endorsement="" class="pull-"></p></div></div></figure><p><em>Fig. 1 shows the different approaches used by 2022-6 and TR-03.</em> Fig. 1 shows the different approaches used by 2022-6 and TR-03. Part A shows audio and metadata being embedded into an SDI stream that is then packetized using 2022-6 and sent through an IP network. Part B shows audio, video and metadata each being packetized into separate IP streams in accordance with TR-03. The crucial difference between these two approaches is illustrated in the steps needed to perform an audio processing function (such as loudness adjustment). In the 2022-6 process, the entire video stream must first be de-packetized and then the audio signal must be de-embedded from the SDI stream. When processing is completed, the audio must be re-embedded in the SDI before the SDI signal can once again be packetized. Contrast this with the TR-03 process shown in Part B of Fig. 1, where only the packets containing audio samples are required to be depacketized, before they are processed, and then repacketized back into an IP stream. Not only does this process remove the need for audio embedding and de-embedding, it also greatly reduces the volume of packet traffic that needs to be routed to the audio processor. As an added benefit of TR-03, note that only the active video pixels of TR-03 need to be packetized, thereby reducing the amount of network traffic generated by uncompressed video.</p><p><strong>TIMING AND IDENTIFICATION</strong><br/>Two important elements that underpin TR-03 are timing and identification. Timing is handled by distributing a common clock to every node on the network using IEEE 1588 Precision Time Protocol, and by referencing all of the media clocks to the SMPTE Epoch defined in 2059-1. Streams are identified, and, more importantly, associated with each other using SDP (Session Description Protocol; IETF RFC 4566 and The SDP Grouping Framework; IETF RFC 5888). Using these capabilities, audio and video streams can be identified as belonging to the same lip sync group and be referenced to a common clock so that they can be sent as separate IP packet streams through a network and then synchronized at the streams’ destination. Going back to Part B in Fig. 1, once the video, audio and data streams are synchronized at their source using a common clock, the streams can take different paths, with different amounts of delay, yet still be able to be realigned to a common clock at the output. An SDP file is created to indicate that the video, audio and data signals shown in Part B in Fig. 1 are part of the same lip sync group; the information in this file tells the receiving device where to find the streams and how to synchronize them.</p><p>When asked why a new standard is needed at this time, John Mailhot, CTO networking and infrastructure for Imagine Communications said “IP is a new infrastructure for the industry. 2022 has a place for interconnection between facilities and between rooms. The SVIP group was formed to address needs in the production studio. TR-03 has the flexibility that is a paramount need for this application.</p><p>“TR-03 can deliver the promise of IP networks,” he said. “It creates an extensible way to organize video, audio and metadata that can deliver all these media types in a media-agnostic fashion.”</p><p>There already appears to be a great deal of interest in this new TR, at least according to Meyer. “People noticed my name on the list of contributors to TR-03 and are calling me out of the blue—this never happened to me before. They are saying ‘Hey Chuck this is a really a cool thing. I think I’m seeing how this could really help me with my 4K transitions. Can you give me more technical details?’”</p><p>A copy of the TR-03 Draft Recommendation can be downloaded at <a href="https://www.videoservicesforum.org/technical_recommendations.shtml" data-original-url="http://www.videoservicesforum.org/technical_recommendations.shtml"><em>www.videoservicesforum.org/technical_recommendations.shtml</em></a><em>.</em></p><p><em>Wes Simpson is a member of the SVIP team that developed TR-03 within the VSF, along with representatives from dozens of other companies within the media industry.</em></p>
                                                            </article>
                            ]]>
                        </content:encoded>
                                                </item>
                                <item>
                                                            <title><![CDATA[ SDI vs. IP: Fox’s Thomas Edwards on VSF TR-03 ]]></title>
                                                                                                <dc:content><![CDATA[ <p><strong>LOS ANGELES</strong>—A technology-driven migration is taking place in the television engineering community, from baseband SDI-based equipment to IP-based and sometimes virtual technology. The discussion on the virtues and drawbacks of each continue. Last week, the Video Services Forum published a draft Technical Recommendation for “Transport of Uncompressed Elementary Stream Media over IP.” (<em>See “<a href="https://www.tvtechnology.com/news/vsf-publishes-draft-technical-rec-for-studio-videooverip" data-original-url="http://www.tvtechnology.com/news/0002/vsf-publishes-draft-technical-rec-for-studio-videooverip/277253">VSF Publishes Draft Technical Rec. for Studio Video-over-IP</a>.”</em>)<br/><br/>Thomas Edwards, vice president of Engineering & Development at Fox Networks Engineering and Operations, has been at the forefront of testing and developing IP-based technologies for video transport for several years. Edwards participated in the group that developed the VSF draft, TR-03. <em>TV Technology</em> asked Edwards why this is significant.<br/><br/><strong><em>TV Technology</em></strong><em>: How does TR-03 differ from SMPTE 2022-6? Is non-SDI encapsulation the differentiator?</em><br/><br/><strong>Edwards:</strong> SMPTE ST 2022-6 is encapsulation of the entire SDI signal in IP. VSF TR-03 allows the individual elements of video, audio, and ancillary data to be separately forwarded through a network, and re-composed into different combinations as needed for production purposes.<br/><br/>One interesting aspect is that the ancillary space in HD-SDI uses 16 percent to 38 percent of SDI bandwidth depending on resolution and frame rate, so there is significant bandwidth savings from only transmitting the active video. Now we can finally let go of the legacy of the blanking regions of the CRT by using TR-03.<br/><br/><strong><em>TV Technology</em></strong><em>: TR-03 mentions “specific concentration on live production,” meaning real time?</em><br/><br/><strong>Edwards:</strong> Yes, this effort is all about a real-time, low-latency, production-oriented format.<br/><br/><strong><em>TV Technology</em></strong><em>: Does this reflect the work you’ve been doing at Fox?</em><br/><br/><strong>Edwards:</strong> Fox has been supporting this work in the VSF Studio Video over IP (SVIP) Activity Group, and we are currently working with Aperi Corp. to create FPGA code to convert between SDI and RFC 4175, the uncompressed video format specified by VSF TR-03.<br/><br/><strong><em>TV Technology</em></strong><em>: Is there a limitation to the payload?</em><em><br/></em><br/><strong>Edwards:</strong> RFC 4175 can handle video of any bit depth, up to 32,767x32,767 resolution, 4:2:0, 4:2:2, and 4:4:4 color subsamplings, and both progressive and interlace. TR-03 adds BT.2020 color space as well as a SMPTE 2084 HDR EOTF. We feel that RFC 4175 is extensible for any video format we are thinking about.<br/><strong><br/></strong>TR-03 carries audio using AES67, the AES standard for uncompressed audio over IP. This lets the broadcast video industry immediately become compatible with a large number of networked audio systems.<br/><br/>For ancillary data, TR-03 uses IETF draft-ietf-payload-rtp-ancillary, which allows interesting new workflows. No ANC embedders/disembedders are needed, instead devices can contribute or consume ANC data independent of video streams, while maintaining synchronization.<br/><br/><strong><em>TV Technology</em></strong><em>: The press release states,</em> “The group studied and documented requirements within the broadcast plant including video, audio, ancillary data, grouping, timing, sequencing, identities, and latency.” <em>Are all of these elements transported independently, without encapsulation, and if so, how is synchronization achieved and maintained?</em><em><br/><br/></em><strong>Edwards:</strong> Video, audio, and ancillary data are transported separately. A network clock is distributed using IEEE 1588 Precision Time Protocol. Streams and synchronized groups of streams are described with IETF Session Description Protocol (SDP).<br/><br/>Sessions are announced with IETF Session Announcement Protocol (SAP). More complex capabilities of identities, registration, and discovery may be addressed by future work of the VSF SVIP AG. Synchronization is provided through IETF RFC 7273 RTP [real-time protocol] Clock Source Signalling, which links PTP time to the RTP media clock.<br/><br/><strong><em>TV Technology</em></strong><em>: Further, it states,</em> “It then researched current and proposed solutions, and developed a gap analysis between the requirements and existing solutions.” <em>What were the gaps?</em><em><br/></em><br/><strong>Edwards:</strong> I feel that TR-03 did a great job of fulfilling the requirements. Higher level capabilities of identity, registration, and discovery need some additional work. Fortunately, BBC Research & Development has been doing great work in these areas, and may prove them out during the <a href="https://www.amwa.tv/downloads/2015-09-04_AMWA_NMI_press_release.pdf" data-original-url="http://www.amwa.tv/downloads/2015-09-04_AMWA_NMI_press_release.pdf">AMWA Networked Media Incubator</a> project. [<a href="https://www.amwa.tv/" data-original-url="http://www.amwa.tv/">Advanced Media Workflow Association</a>]<em><br/></em><br/><strong><em>TV Technology</em></strong><em>:</em><em>I seem to remember somone suggesting that the work on this in VSF might at some point be adopted or otherwise included in SMPTE-2022. Is that the case? Will this become part of SMPTE-2022?<br/></em><br/><strong>Edwards:</strong> SMPTE ST 2022-6 also uses RTP, like the RTP payloads specified in VSF TR-03. Since SMPTE ST 2022-6 is SDI encapsulated in IP, it will likely have some use in the short term for solutions that need to expose SDI inputs and outputs for mixed SDI/IP installations. But to achieve the maximum flexibility of IP production, there was a need to break these out in elementary streams—audio, video and anciliary data.<br/><br/>For example, one may want to connect different languages of audio with a video, or one may have a device that can generate closed captions, timecode, etc., and those don’t have to be encapsulated in SDI.<br/><br/>On video, there is some bandwidth savings of only sending the active video area than carrying all of SDI because there is less overhead. For the people who are 50p, especially 720p50, the waste of bandwidth in ancillary data space of SDI is significant.<br/><br/><strong><em>TV Technology:</em></strong><em>Will this become a part of SMPTE standard.<br/></em><strong>Edwards:</strong> Yes, it is believed that this will go to a SMPTE committee for standardization. The VSF effort involved 60 people from 30 companies who took part in the teleconference meetings to produce the TR, so we know that we have input from a large portion of the industry. From the Fox point of view, that’s very important.<br/><br/><strong><em>TV Technology:</em></strong>Does this eliminate some of the latency of encapsulation?<br/><strong>Edwards:</strong> TR-03 defines the transport and synchronization protocols. How they are used is up to the implementer. There will certainly be subframe latency implementations.<br/>I don’t think latency would necessarily be any less or more than SMPTE 2022-6. Both are using the real-time protocol—RTP. In both protocols, you put a section of uncompressed video into a packet and then send it out over the network. The latency depends on how the how much buffering is required for network jitter. A millisecond or less would suffice for most LAN implementations.<br/><br/><strong><em>TV Technology:</em></strong><em>What is the concern with synchronization?<br/></em><strong>Edwards:</strong> There is a real concern among users that synchronization (lip sync, audio imaging, clean switching, etc.) goes out the window when you move to IP media. With a proper implementation, this is not true. Actually when every packet is time stamped accurately, we should have better synchronization between media streams than SDI solutions could provide. Synchronization was an important set of requirements for the development of TR-03.<br/><br/><strong><em>TV Technology:</em></strong><em>How does this fit with ASPEN, TICO, et al?<br/></em><strong>Edwards:</strong> It’s true that lots of transport protocols are being announced. That’s why we thought it was important to encourage the industry to adopt a common transport protocol. And so Fox decided to support the SVIP AG. The VSF was able to develop this Technical Recommendation in a year and a half.<br/><br/>Hopefully, we won’t have the situation that happened with networked audio, with 10 different audio formats. It delayed widespread implementation by over ten years, because you’d buy one device from one vendor, and it wouldn’t work with another device from another vendor. After a long period of multiple, incompatible transport protocols, the AES developed AES67, which many networked audio vendors are now supporting. Because of this, the VSF SVIP AG adopted AES67 in TR-03 to continue that interoperable compatibility.<br/><br/><strong><em>TV Technology:</em></strong><em>Does this accommodate a hybrid world?<br/></em><strong>Edwards:</strong> This is looking toward a world that’s all IP, but there will be a period of hybrid SDI/IP. I will be giving a talk at the SMPTE 2015 Annual Technical Conference on elementary streams over IP, which with the publication by the VSF will basically be about TR-03.<br/><br/><strong><em>TV Technology:</em></strong><em>Will this be real time?<br/></em><strong>Edwards:</strong> Yes.<br/><br/><strong><em>TV Technology:</em></strong><em>What would you like to add?</em><br/><strong>Edwards:</strong> We’re not doing this just for fun. The move to IP is about improving the agility of our broadcast operation. How do we get there? By moving to a virtualized facility. And how do we get to a virtualized facility? Using COTS hardware equipment and IP. It’s all part of a strategy to improve the agility of the broadcast plant.<br/><br/>There are other advantages in the short term as well. Fox Sports’ new Encore production truck, for example, was able to dramatically impove signal density by putting a large number of video flows over 10 GbE.<br/><br/>There may not be a cost advantage today—I think the costs are nearly equivalent now. But IP solutions will get cheaper over time. We know that IP networking technology is being driven by the hyperscale data centers, which are now moving from 10 Gbps this year to 25 Gbps, 50 Gbps, and 100 Gbps in the LAN shortly.<br/><br/><strong><em>TV Technology:</em></strong><em>Why is TR-03 important?<br/></em><strong>Edwards:</strong> It represents a key element of cooperation in the industry on a common protocol. This is the beginning of a revolution.<br/><br/>The draft TR is “<a href="https://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_DRAFT_2015-10-19.pdf" data-original-url="http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_DRAFT_2015-10-19.pdf">TR-03 - Transport of Uncompressed Elementary Stream Media over IP</a>“ (Published as a draft.)<br/><br/><em>Also see...<br/>October 23, 2015<br/></em>“<strong><a href="https://www.tvtechnology.com/news/vsf-publishes-draft-technical-rec-for-studio-videooverip" data-original-url="http://www.tvtechnology.com/news/0002/vsf-publishes-draft-technical-rec-for-studio-videooverip/277253">VSF Publishes Draft Technical Rec. for Studio Video-over-IP</a></strong>“<br/>The VSF SVIP Activity Group was tasked with developing a standard for video-over-IP without SDI encapsulation with a specific concentration on live production.<strong><br/></strong><em><br/>October 22, 2015</em><br/>“<strong><a href="https://www.tvtechnology.com/broadcast-engineering/uhd-in-a-hybrid-sdiip-world" data-original-url="http://www.tvtechnology.com/broadcast-engineering/0029/uhd-in-a-hybrid-sdiip-world/277249">UHD In a Hybrid SDI/IP World</a></strong>“<br/>“There are more and more technology partnerships between vendors; this is something I’m seeing more and more of, which I haven’t seen in the past.”<br/><br/><em>October 20, 2015</em><br/>“<strong><a href="https://www.tvtechnology.com/opinions/sdi-vs-ip-packet-to-packet" data-original-url="http://www.tvtechnology.com/opinions/0004/sdi-vs-ip-packet-to-packet/277232">SDI vs. IP: Packet to Packet</a></strong>“<br/>If one looks at the delay through an IP switch, it is due to the necessity to buffer the packets as they arrive, are processed and then sent out. Depending on the switch design, the traffic load, and the packet size, the performance required in terms of packet loss dictates the buffer sizes.<br/><br/><em>October 19 2015<br/></em>“<strong>Global HDR TV Shipments to Exceed 32 Million in 2019</strong>“<strong><br/></strong>IHS forecasts that unit shipments of HDR TVs globally will grow from 2.9 million in 2016 to 32.6 million in 2019.<br/><strong><br/></strong><em>October 19 2015<br/></em>“<strong>AES Delves Into IP Audio, OTT</strong>“<br/>Television broadcasting has gone through numerous significant changes since the first station went on-air more than 80 years ago, but nothing may prove to have such an impact on the medium as IP technology.<em><br/></em><br/><em>October 14, 2015</em><br/>“<strong><a href="https://www.tvtechnology.com/opinions/sdi-vs-ip-which-switch-is-which" data-original-url="http://www.tvtechnology.com/opinions/0004/sdi-vs-ip-which-switch-is-which/277159">SDI vs. IP: Which Switch is Which?</a></strong>“<br/>If major industries, including manufacturing, transportation, telecommunications, commerce and banking, have adopted IP, why not real-time video production?<br/><br/><em>July 23, 2015<strong><br/></strong></em>“<strong><a href="https://www.tvtechnology.com/news/test-vendors-straddle-the-worlds-of-sdi-and-ip" data-original-url="http://www.tvtechnology.com/equipment/0005/test-vendors-straddle-the-worlds-of-sdi-and-ip/276655">Test Vendors Straddle the Worlds of SDI and IP</a></strong>“<strong><em><br/></em></strong>It doesn’t really matter what is broken these days, it’s either deemed disposable or worthy of repair.<br/><br/><em>June 10, 2015<strong><br/></strong></em>“<strong><a href="https://www.tvtechnology.com/opinions/ip-for-broadcast-a-conversation-with-thomas-edwards-of-fox" data-original-url="http://www.tvtechnology.com/expertise/0003/ip-for-broadcast-a-conversation-with-thomas-edwards-of-fox/276295">IP for Broadcast: A Conversation with Thomas Edwards of Fox</a></strong>“<br/>The main drive for moving from SDI/AES to IP is the need to enhance flexibility and agility of the broadcast plant.<br/><br/><em>October 22, 2014</em><strong><br/></strong>“<strong><a href="https://www.tvtechnology.com/news/smpte-2014-uncompressed-video-over-cots-ethernet-switches" data-original-url="http://www.tvtechnology.com/events/0025/smpte-2014-uncompressed-video-over-cots-ethernet-switches/272983">SMPTE 2014: Uncompressed Video Over COTS Ethernet Switches</a></strong>“<br/>How many packets are dropped by Ethernet switches moving video? Thomas Edwards of Fox set about with Aperi Corp. to find out.<strong><br/></strong><br/><em>June 28, 2010<br/></em><a href="https://www.tvtechnology.com/news/uncompressed-video-over-ip" data-original-url="http://www.tvtechnology.com/miscellaneous/0008/uncompressed-video-over-ip/206200">“<strong>Uncompressed Video Over IP</strong></a>“ ~ <strong><em>by Thomas Edwards</em></strong><em><br/></em>Today, the use of compressed video (such as MPEG-2 or H.264) over IP is no longer unusual.<br/><br/></p> ]]></dc:content>
                                                                                                                                            <link>https://www.tvtechnology.com/news/sdi-vs-ip-foxs-thomas-edwards-on-vsf-tr03</link>
                                                                            <description>
                            <![CDATA[ VSF TR-03 allows the individual elements of video, audio, and ancillary data to be separately forwarded through a network, and re-composed into different combinations as needed for production purposes. ]]>
                                                                                                            </description>
                                                                                                                                <guid isPermaLink="false">e1PorNfhBkAKJaZe6StSaz</guid>
                                                                                                <enclosure url="https://cdn.mos.cms.futurecdn.net/Wvb4f76oDxZF9jmhiG2x3o-1280-80.jpg" type="image/jpeg" length="0"></enclosure>
                                                                        <pubDate>Tue, 27 Oct 2015 08:22:00 +0000</pubDate>                                                                                                                                                                                                                                <category><![CDATA[Business]]></category>
                                                                                                                    <dc:creator><![CDATA[ Deborah D McAdams ]]></dc:creator>                                                                                                        <dc:description><![CDATA[ null ]]></dc:description>
                                                                                                                                <cf:isSponsored>false</cf:isSponsored>
                <cf:hasAffiliateLinks>false</cf:hasAffiliateLinks>
                <cf:isPaid>false</cf:isPaid>
                                                                                                                                <media:content type="image/jpeg" url="https://cdn.mos.cms.futurecdn.net/Wvb4f76oDxZF9jmhiG2x3o-1280-80.jpg">
                                                            <media:credit><![CDATA[null]]></media:credit>
                                                                                                                                                                                                                                                                                                                                                    </media:content>
                                                    <media:thumbnail url="https://cdn.mos.cms.futurecdn.net/Wvb4f76oDxZF9jmhiG2x3o-1280-80.jpg" />
                                                                                                                                                                    <content:encoded >
                            <![CDATA[
                            <article>
                                <p><strong>LOS ANGELES</strong>—A technology-driven migration is taking place in the television engineering community, from baseband SDI-based equipment to IP-based and sometimes virtual technology. The discussion on the virtues and drawbacks of each continue. Last week, the Video Services Forum published a draft Technical Recommendation for “Transport of Uncompressed Elementary Stream Media over IP.” (<em>See “<a href="https://www.tvtechnology.com/news/vsf-publishes-draft-technical-rec-for-studio-videooverip" data-original-url="http://www.tvtechnology.com/news/0002/vsf-publishes-draft-technical-rec-for-studio-videooverip/277253">VSF Publishes Draft Technical Rec. for Studio Video-over-IP</a>.”</em>)<br/><br/>Thomas Edwards, vice president of Engineering & Development at Fox Networks Engineering and Operations, has been at the forefront of testing and developing IP-based technologies for video transport for several years. Edwards participated in the group that developed the VSF draft, TR-03. <em>TV Technology</em> asked Edwards why this is significant.<br/><br/><strong><em>TV Technology</em></strong><em>: How does TR-03 differ from SMPTE 2022-6? Is non-SDI encapsulation the differentiator?</em><br/><br/><strong>Edwards:</strong> SMPTE ST 2022-6 is encapsulation of the entire SDI signal in IP. VSF TR-03 allows the individual elements of video, audio, and ancillary data to be separately forwarded through a network, and re-composed into different combinations as needed for production purposes.<br/><br/>One interesting aspect is that the ancillary space in HD-SDI uses 16 percent to 38 percent of SDI bandwidth depending on resolution and frame rate, so there is significant bandwidth savings from only transmitting the active video. Now we can finally let go of the legacy of the blanking regions of the CRT by using TR-03.<br/><br/><strong><em>TV Technology</em></strong><em>: TR-03 mentions “specific concentration on live production,” meaning real time?</em><br/><br/><strong>Edwards:</strong> Yes, this effort is all about a real-time, low-latency, production-oriented format.<br/><br/><strong><em>TV Technology</em></strong><em>: Does this reflect the work you’ve been doing at Fox?</em><br/><br/><strong>Edwards:</strong> Fox has been supporting this work in the VSF Studio Video over IP (SVIP) Activity Group, and we are currently working with Aperi Corp. to create FPGA code to convert between SDI and RFC 4175, the uncompressed video format specified by VSF TR-03.<br/><br/><strong><em>TV Technology</em></strong><em>: Is there a limitation to the payload?</em><em><br/></em><br/><strong>Edwards:</strong> RFC 4175 can handle video of any bit depth, up to 32,767x32,767 resolution, 4:2:0, 4:2:2, and 4:4:4 color subsamplings, and both progressive and interlace. TR-03 adds BT.2020 color space as well as a SMPTE 2084 HDR EOTF. We feel that RFC 4175 is extensible for any video format we are thinking about.<br/><strong><br/></strong>TR-03 carries audio using AES67, the AES standard for uncompressed audio over IP. This lets the broadcast video industry immediately become compatible with a large number of networked audio systems.<br/><br/>For ancillary data, TR-03 uses IETF draft-ietf-payload-rtp-ancillary, which allows interesting new workflows. No ANC embedders/disembedders are needed, instead devices can contribute or consume ANC data independent of video streams, while maintaining synchronization.<br/><br/><strong><em>TV Technology</em></strong><em>: The press release states,</em> “The group studied and documented requirements within the broadcast plant including video, audio, ancillary data, grouping, timing, sequencing, identities, and latency.” <em>Are all of these elements transported independently, without encapsulation, and if so, how is synchronization achieved and maintained?</em><em><br/><br/></em><strong>Edwards:</strong> Video, audio, and ancillary data are transported separately. A network clock is distributed using IEEE 1588 Precision Time Protocol. Streams and synchronized groups of streams are described with IETF Session Description Protocol (SDP).<br/><br/>Sessions are announced with IETF Session Announcement Protocol (SAP). More complex capabilities of identities, registration, and discovery may be addressed by future work of the VSF SVIP AG. Synchronization is provided through IETF RFC 7273 RTP [real-time protocol] Clock Source Signalling, which links PTP time to the RTP media clock.<br/><br/><strong><em>TV Technology</em></strong><em>: Further, it states,</em> “It then researched current and proposed solutions, and developed a gap analysis between the requirements and existing solutions.” <em>What were the gaps?</em><em><br/></em><br/><strong>Edwards:</strong> I feel that TR-03 did a great job of fulfilling the requirements. Higher level capabilities of identity, registration, and discovery need some additional work. Fortunately, BBC Research & Development has been doing great work in these areas, and may prove them out during the <a href="https://www.amwa.tv/downloads/2015-09-04_AMWA_NMI_press_release.pdf" data-original-url="http://www.amwa.tv/downloads/2015-09-04_AMWA_NMI_press_release.pdf">AMWA Networked Media Incubator</a> project. [<a href="https://www.amwa.tv/" data-original-url="http://www.amwa.tv/">Advanced Media Workflow Association</a>]<em><br/></em><br/><strong><em>TV Technology</em></strong><em>:</em><em>I seem to remember somone suggesting that the work on this in VSF might at some point be adopted or otherwise included in SMPTE-2022. Is that the case? Will this become part of SMPTE-2022?<br/></em><br/><strong>Edwards:</strong> SMPTE ST 2022-6 also uses RTP, like the RTP payloads specified in VSF TR-03. Since SMPTE ST 2022-6 is SDI encapsulated in IP, it will likely have some use in the short term for solutions that need to expose SDI inputs and outputs for mixed SDI/IP installations. But to achieve the maximum flexibility of IP production, there was a need to break these out in elementary streams—audio, video and anciliary data.<br/><br/>For example, one may want to connect different languages of audio with a video, or one may have a device that can generate closed captions, timecode, etc., and those don’t have to be encapsulated in SDI.<br/><br/>On video, there is some bandwidth savings of only sending the active video area than carrying all of SDI because there is less overhead. For the people who are 50p, especially 720p50, the waste of bandwidth in ancillary data space of SDI is significant.<br/><br/><strong><em>TV Technology:</em></strong><em>Will this become a part of SMPTE standard.<br/></em><strong>Edwards:</strong> Yes, it is believed that this will go to a SMPTE committee for standardization. The VSF effort involved 60 people from 30 companies who took part in the teleconference meetings to produce the TR, so we know that we have input from a large portion of the industry. From the Fox point of view, that’s very important.<br/><br/><strong><em>TV Technology:</em></strong>Does this eliminate some of the latency of encapsulation?<br/><strong>Edwards:</strong> TR-03 defines the transport and synchronization protocols. How they are used is up to the implementer. There will certainly be subframe latency implementations.<br/>I don’t think latency would necessarily be any less or more than SMPTE 2022-6. Both are using the real-time protocol—RTP. In both protocols, you put a section of uncompressed video into a packet and then send it out over the network. The latency depends on how the how much buffering is required for network jitter. A millisecond or less would suffice for most LAN implementations.<br/><br/><strong><em>TV Technology:</em></strong><em>What is the concern with synchronization?<br/></em><strong>Edwards:</strong> There is a real concern among users that synchronization (lip sync, audio imaging, clean switching, etc.) goes out the window when you move to IP media. With a proper implementation, this is not true. Actually when every packet is time stamped accurately, we should have better synchronization between media streams than SDI solutions could provide. Synchronization was an important set of requirements for the development of TR-03.<br/><br/><strong><em>TV Technology:</em></strong><em>How does this fit with ASPEN, TICO, et al?<br/></em><strong>Edwards:</strong> It’s true that lots of transport protocols are being announced. That’s why we thought it was important to encourage the industry to adopt a common transport protocol. And so Fox decided to support the SVIP AG. The VSF was able to develop this Technical Recommendation in a year and a half.<br/><br/>Hopefully, we won’t have the situation that happened with networked audio, with 10 different audio formats. It delayed widespread implementation by over ten years, because you’d buy one device from one vendor, and it wouldn’t work with another device from another vendor. After a long period of multiple, incompatible transport protocols, the AES developed AES67, which many networked audio vendors are now supporting. Because of this, the VSF SVIP AG adopted AES67 in TR-03 to continue that interoperable compatibility.<br/><br/><strong><em>TV Technology:</em></strong><em>Does this accommodate a hybrid world?<br/></em><strong>Edwards:</strong> This is looking toward a world that’s all IP, but there will be a period of hybrid SDI/IP. I will be giving a talk at the SMPTE 2015 Annual Technical Conference on elementary streams over IP, which with the publication by the VSF will basically be about TR-03.<br/><br/><strong><em>TV Technology:</em></strong><em>Will this be real time?<br/></em><strong>Edwards:</strong> Yes.<br/><br/><strong><em>TV Technology:</em></strong><em>What would you like to add?</em><br/><strong>Edwards:</strong> We’re not doing this just for fun. The move to IP is about improving the agility of our broadcast operation. How do we get there? By moving to a virtualized facility. And how do we get to a virtualized facility? Using COTS hardware equipment and IP. It’s all part of a strategy to improve the agility of the broadcast plant.<br/><br/>There are other advantages in the short term as well. Fox Sports’ new Encore production truck, for example, was able to dramatically impove signal density by putting a large number of video flows over 10 GbE.<br/><br/>There may not be a cost advantage today—I think the costs are nearly equivalent now. But IP solutions will get cheaper over time. We know that IP networking technology is being driven by the hyperscale data centers, which are now moving from 10 Gbps this year to 25 Gbps, 50 Gbps, and 100 Gbps in the LAN shortly.<br/><br/><strong><em>TV Technology:</em></strong><em>Why is TR-03 important?<br/></em><strong>Edwards:</strong> It represents a key element of cooperation in the industry on a common protocol. This is the beginning of a revolution.<br/><br/>The draft TR is “<a href="https://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_DRAFT_2015-10-19.pdf" data-original-url="http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_DRAFT_2015-10-19.pdf">TR-03 - Transport of Uncompressed Elementary Stream Media over IP</a>“ (Published as a draft.)<br/><br/><em>Also see...<br/>October 23, 2015<br/></em>“<strong><a href="https://www.tvtechnology.com/news/vsf-publishes-draft-technical-rec-for-studio-videooverip" data-original-url="http://www.tvtechnology.com/news/0002/vsf-publishes-draft-technical-rec-for-studio-videooverip/277253">VSF Publishes Draft Technical Rec. for Studio Video-over-IP</a></strong>“<br/>The VSF SVIP Activity Group was tasked with developing a standard for video-over-IP without SDI encapsulation with a specific concentration on live production.<strong><br/></strong><em><br/>October 22, 2015</em><br/>“<strong><a href="https://www.tvtechnology.com/broadcast-engineering/uhd-in-a-hybrid-sdiip-world" data-original-url="http://www.tvtechnology.com/broadcast-engineering/0029/uhd-in-a-hybrid-sdiip-world/277249">UHD In a Hybrid SDI/IP World</a></strong>“<br/>“There are more and more technology partnerships between vendors; this is something I’m seeing more and more of, which I haven’t seen in the past.”<br/><br/><em>October 20, 2015</em><br/>“<strong><a href="https://www.tvtechnology.com/opinions/sdi-vs-ip-packet-to-packet" data-original-url="http://www.tvtechnology.com/opinions/0004/sdi-vs-ip-packet-to-packet/277232">SDI vs. IP: Packet to Packet</a></strong>“<br/>If one looks at the delay through an IP switch, it is due to the necessity to buffer the packets as they arrive, are processed and then sent out. Depending on the switch design, the traffic load, and the packet size, the performance required in terms of packet loss dictates the buffer sizes.<br/><br/><em>October 19 2015<br/></em>“<strong>Global HDR TV Shipments to Exceed 32 Million in 2019</strong>“<strong><br/></strong>IHS forecasts that unit shipments of HDR TVs globally will grow from 2.9 million in 2016 to 32.6 million in 2019.<br/><strong><br/></strong><em>October 19 2015<br/></em>“<strong>AES Delves Into IP Audio, OTT</strong>“<br/>Television broadcasting has gone through numerous significant changes since the first station went on-air more than 80 years ago, but nothing may prove to have such an impact on the medium as IP technology.<em><br/></em><br/><em>October 14, 2015</em><br/>“<strong><a href="https://www.tvtechnology.com/opinions/sdi-vs-ip-which-switch-is-which" data-original-url="http://www.tvtechnology.com/opinions/0004/sdi-vs-ip-which-switch-is-which/277159">SDI vs. IP: Which Switch is Which?</a></strong>“<br/>If major industries, including manufacturing, transportation, telecommunications, commerce and banking, have adopted IP, why not real-time video production?<br/><br/><em>July 23, 2015<strong><br/></strong></em>“<strong><a href="https://www.tvtechnology.com/news/test-vendors-straddle-the-worlds-of-sdi-and-ip" data-original-url="http://www.tvtechnology.com/equipment/0005/test-vendors-straddle-the-worlds-of-sdi-and-ip/276655">Test Vendors Straddle the Worlds of SDI and IP</a></strong>“<strong><em><br/></em></strong>It doesn’t really matter what is broken these days, it’s either deemed disposable or worthy of repair.<br/><br/><em>June 10, 2015<strong><br/></strong></em>“<strong><a href="https://www.tvtechnology.com/opinions/ip-for-broadcast-a-conversation-with-thomas-edwards-of-fox" data-original-url="http://www.tvtechnology.com/expertise/0003/ip-for-broadcast-a-conversation-with-thomas-edwards-of-fox/276295">IP for Broadcast: A Conversation with Thomas Edwards of Fox</a></strong>“<br/>The main drive for moving from SDI/AES to IP is the need to enhance flexibility and agility of the broadcast plant.<br/><br/><em>October 22, 2014</em><strong><br/></strong>“<strong><a href="https://www.tvtechnology.com/news/smpte-2014-uncompressed-video-over-cots-ethernet-switches" data-original-url="http://www.tvtechnology.com/events/0025/smpte-2014-uncompressed-video-over-cots-ethernet-switches/272983">SMPTE 2014: Uncompressed Video Over COTS Ethernet Switches</a></strong>“<br/>How many packets are dropped by Ethernet switches moving video? Thomas Edwards of Fox set about with Aperi Corp. to find out.<strong><br/></strong><br/><em>June 28, 2010<br/></em><a href="https://www.tvtechnology.com/news/uncompressed-video-over-ip" data-original-url="http://www.tvtechnology.com/miscellaneous/0008/uncompressed-video-over-ip/206200">“<strong>Uncompressed Video Over IP</strong></a>“ ~ <strong><em>by Thomas Edwards</em></strong><em><br/></em>Today, the use of compressed video (such as MPEG-2 or H.264) over IP is no longer unusual.<br/><br/></p>
                                                            </article>
                            ]]>
                        </content:encoded>
                                                </item>
            </channel>
</rss>