<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:dc="https://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"
>
    <channel>
                    <atom:link href="https://www.tvtechnology.com/feeds/tag/scte-35" rel="self" type="application/rss+xml" />
                            <title><![CDATA[ Latest from Tv Technology in Scte-35 ]]></title>
                <link>https://www.tvtechnology.com/tag/scte-35</link>
        <description><![CDATA[ All the latest scte-35 content from the Tv Technology team ]]></description>
                                    <lastBuildDate>Fri, 18 May 2018 18:14:13 +0000</lastBuildDate>
                            <language>en</language>
                                <item>
                                                            <title><![CDATA[ Making OTT Profitable for Linear Broadcasters ]]></title>
                                                                                                                                                                                                <link>https://www.tvtechnology.com/opinions/making-ott-profitable-for-linear-broadcasters</link>
                                                                            <description>
                            <![CDATA[ Distributing linear content over the internet is considerably more complex than OTT VOD or TVE distribution ]]>
                                                                                                            </description>
                                                                                                                                <guid isPermaLink="false">jThhdp1awZgYPfiNNx4j17</guid>
                                                                                                <enclosure url="https://cdn.mos.cms.futurecdn.net/oDspewgVWpFRPk3zk3N29Y-1280-80.jpg" type="image/jpeg" length="0"></enclosure>
                                                                        <pubDate>Fri, 18 May 2018 18:14:13 +0000</pubDate>                                                                                                                                                                                                                                <category><![CDATA[Opinion]]></category>
                                                    <category><![CDATA[Insights]]></category>
                                                                                                                    <dc:creator><![CDATA[ Roger Franklin, CEO, Crystal ]]></dc:creator>                                                                                                        <dc:description><![CDATA[ null ]]></dc:description>
                                                                                                                                                                                                                                                <media:content type="image/jpeg" url="https://cdn.mos.cms.futurecdn.net/oDspewgVWpFRPk3zk3N29Y-1280-80.jpg">
                                                            <media:credit><![CDATA[null]]></media:credit>
                                                                                                                                                                                                                                                                                                                                                    </media:content>
                                                    <media:thumbnail url="https://cdn.mos.cms.futurecdn.net/oDspewgVWpFRPk3zk3N29Y-1280-80.jpg" />
                                                                                                                                                                    <content:encoded >
                            <![CDATA[
                            <article>
                                <p>There is nothing new in the distribution of linear TV over the internet; TV Everywhere (TVE) is pretty much demanded by consumers and is now considered the norm. Traditional broadcasters are forced to keep up with evolving viewer habits by making content available online pretty much immediately and on any device.</p><p>But in almost all cases, they are doing so without inserting the necessary signalling which indicates where within a linear stream advertising and other content segments begin and end, and which segments can, must, or must not be replaced with alternate content. Broadcasters already consider providing content Over-The-Top (OTT) a cost of doing business–they know it is part of their future. However, without the right signalling, it is virtually impossible to realize the maximum monetization OTT has to offer broadcasters. Moreover, without the right signalling it is extremely difficult to provide the seamless professional viewing experience broadcasters and viewers expect.</p><p>By failing to invest in the technology which can make OTT so lucrative, including signal delivery and correct metadata signalling, broadcasters are not making the most of the opportunities presented by OTT, of which there are many.</p><p><strong>THE OTT CHALLENGE</strong></p><p>Although OTT should be looked at as an opportunity (as long as the right technology is in place), distributing linear content over the internet is considerably more complex than OTT VOD or TVE distribution. Even the process of reformatting content for OTT is time-consuming, let alone the challenge of correctly adhering to content distribution rights across various devices and regions.</p><p>OTT distributors must now programmatically and automatically react at the last second if a piece of content cannot be distributed to viewer X on a cell phone in California because it does not have the right to do so. Without the correct signalling in place to trigger the replacement of this content with something else, the broadcaster could be fined and the OTT distributor may just default to putting up a “slate” to blackout the content. With the current level of competition for viewing time, modern viewers simply won’t wait for this to be resolved and are likely to switch off or watch another video stream.</p><p>Linear TV advertising is big business with transactions for the priciest slots <a href="https://adage.com/article/news/tv-ad-pricing-chart/310429/" data-original-url="http://adage.com/article/news/tv-ad-pricing-chart/310429/">coming in at</a> over half a million dollars. Broadcasters are able to cover the astronomical cost of putting a channel on air with the revenue generated from this advertising. But making this content available online could involve costly duplication of workflows and costs, which are not covered by today’s OTT advertising and subscription revenues. The sad fact is, however, that it doesn’t have to be like this for broadcasters, with OTT presenting a number of opportunities to add further value to their existing linear content.</p><p><strong>[Read: <a href="https://www.tvtechnology.com/news/syncbak-to-conduct-first-ever-live-ott-broadcast-using-local-dynamic-ad-insertion">Syncbak To Conduct 'First Ever' Live OTT Broadcast Using Local Dynamic Ad Insertion</a>]</strong></p><p>One of these opportunities is dynamic insertion, or more accurately, replacement of targeted ads. But again, this simply isn’t as easily done in the case of linear TV streamed OTT. For example, it makes no sense for ads broadcast on linear TV to remain with the content for OTT VOD streaming several days later. These ads may be stale and irrelevant by then. More pressingly, the replacement ads must be the exact duration of those needing to be replaced otherwise there will be a discontinuity (a black frame if the ad is too short, or cutting off the beginning of the following content segment if too long, for example). To do this seamlessly and to make OTT as profitable as possible, the broadcaster must be able to deliver the metadata, which signals the frame boundaries and duration of every content segment, to OTT distributors so ads can be replaced dynamically.</p><p><strong>DELIVERING THE RIGHT SIGNALS</strong></p><p>Broadcasters also have the opportunity to capitalize on the expansion of Nielson Ratings to include the first few days after a linear broadcast, in order to account for on-demand viewing. Linear content streamed OTT effectively has “two bites at the apple,” but only if broadcasters are able to making this content available almost immediately within the C3 window, and cost-effectively too.</p><p>Integration with broadcast systems, like media asset management systems, automation playout systems, on-air switchers, etc., provides the most effective way to access timing data associated with content segments. This way, information including timing, asset type and unique IDs can be signalled in-band or delivered out-of-band and applied to the video stream later, with no impact on the main linear broadcast workflow.</p><p>If a broadcaster were to extract metadata describing a linear TV channel, including the start and end of each content segment, and deliver these as SCTE 35 messages, it is possible to automate a whole host of value adding applications. This includes Dynamic Ad Insertion/Replacement, the creation of on-demand assets and even interactive TV. As this is done in an automated fashion, it removes much of the cost and labor associated with making linear TV available OTT and solves many associated business challenges.</p><p>For example this solves the issue of complex rights management. A policy can be triggered downstream when metadata within a content segment indicates that a particular piece of content must be replaced according to certain parameters as further defined using SCTE 224. For example, if a stream is requested by a viewer in country X or on a particular network, the metadata signalling can indicate that a different stream must be delivered instead.</p><p>With the ability to dynamically replace ads on-the-fly, thanks to correctly delivered metadata signals, providing linear content OTT can be a much more valuable process. This is particularly the case if these ads are personalized. In fact, a <a href="https://www.rapidtvnews.com/2018042651845/ott-video-ads-drive-more-purchase-intent.html#axzz5Dsenz2q0">recent study</a> found that ads within OTT platforms are 67 percent more effective per impression than those on broadcast or cable television. This is because it is much easier to personalize ads according to individual users when delivering content over the internet, as an individual stream is sent to each viewer.</p><p>Using additional metadata about users, such as location, viewing history, browsing history etc., it is possible using a distributed playout architecture to deliver much more targeted ads to specific users. Naturally this means the ads themselves are much more valuable and therefore profitable. As long as the timing information and metadata about each segment and ad is delivered, either in-band or out-of-band, to the last video server in the distribution chain, operators can make sure the ads they insert are seamless and accurate.</p><p><strong>CONCLUSION</strong></p><p>Broadcasters have very little choice when it comes to providing OTT content if they want to remain relevant. This does present many challenges as we have discussed, but none of these are insurmountable with the right technology in place to deliver signalling and metadata information. With these measures in place, linear broadcasters can take advantage of the applications that can make OTT an attractive proposition. Everything from content replacement, rights management, automated asset creation and dynamic ad insertion/replacement are all possible, increasing the value of linear content and opening up new revenue streams. OTT is no longer a cost of doing business, it is a lucrative business. </p>
                                                            </article>
                            ]]>
                        </content:encoded>
                                                </item>
                                <item>
                                                            <title><![CDATA[ Bringing Order to the SCTE 35 Chaos ]]></title>
                                                                                                                                                                                                <link>https://www.tvtechnology.com/opinions/bringing-order-to-the-scte-35-chaos</link>
                                                                            <description>
                            <![CDATA[ Taking the cloud approach ]]>
                                                                                                            </description>
                                                                                                                                <guid isPermaLink="false">cgqELsQtePdBSNCs1rK27F</guid>
                                                                                                <enclosure url="https://cdn.mos.cms.futurecdn.net/3jBFJ35KyPx4HjkGwMh9HD-1280-80.jpg" type="image/jpeg" length="0"></enclosure>
                                                                        <pubDate>Thu, 22 Feb 2018 20:55:00 +0000</pubDate>                                                                                                                                                                                                                                <category><![CDATA[Opinion]]></category>
                                                    <category><![CDATA[Insights]]></category>
                                                                                                                    <dc:creator><![CDATA[ Alan Young ]]></dc:creator>                                                                                                        <dc:description><![CDATA[ null ]]></dc:description>
                                                                                                                                                                                                                                                <media:content type="image/jpeg" url="https://cdn.mos.cms.futurecdn.net/3jBFJ35KyPx4HjkGwMh9HD-1280-80.jpg">
                                                            <media:credit><![CDATA[null]]></media:credit>
                                                                                                                                                                                                                                                                                                                                                    </media:content>
                                                    <media:thumbnail url="https://cdn.mos.cms.futurecdn.net/3jBFJ35KyPx4HjkGwMh9HD-1280-80.jpg" />
                                                                                                                                                                    <content:encoded >
                            <![CDATA[
                            <article>
                                <p>SCTE 35 has been relied on for two decades by broadcasters and cable TV networks (“content providers”) to signal local avail breaks—the slots that are granted by the content providers to the cable system operators (and other multichannel video programming distributors) for local advertising. In the United States, these breaks are usually exactly a minute long and occur twice an hour. The content providers usually schedule promos and other non-essential filler material in these slots for cable operators to insert their local commercials over. Local commercial insertion is a mature business (and a very big business).</p><p>More recently, the use of SCTE 35 has been expanded considerably and it is now used to signal the start and end of programming and national advertising breaks. This is to enable virtual MVPDs to blackout programming where rights are limited and also to replace scheduled broadcast adverts that cannot be distributed over the Internet (either because the advertiser doesn’t want to or because they can’t—adverts have rights too). SCTE 35 can also be useful for automating live-to-VOD (e.g. C3 VOD) and delivering enhanced nDVR capability.</p><p>However, there are a number of issues with this expanded use that are hampering the effectiveness of the SCTE 35 standard and, as a direct consequence, the ability of content providers to efficiently monetize the immense opportunities OTT streaming provides.</p><p><strong>THE METADATA MESS</strong></p><p>Given the importance of the SCTE 35 standard, it has been updated multiple times with good intentions. But over the years, this has been done so many times that the standard is now ambiguous in many areas, with no real clarity as to which messages should be used to signal which events—the latest version allows for the signaling of more than 28 different types of events including chapter start, chapter end, ad break start, ad break end and so on.</p><p>The main problem with this is that no two content providers use the exact same SCTE messages to trigger the same actions (such as an ad break, for example). Different programmers will signal the same point in a video signal with an entirely different SCTE 35 message. One programmer, for example, may decide to signal the start of an ad break with “Provider Advertisement Start” and another may use the exact same message to signal the start of an individual advert. There are many other areas of ambiguity too. As a result, it’s incredibly difficult for vMVPDs to properly interpret what the content provider is trying to signal. There is no agreed way of signaling events because so many parts of SCTE 35 are optional, and not wanting to be left out, each vMVPD has developed their own requirements. It is truly a mess.</p><p>For one content provider to distribute to three vMVPDs, every single one of whom will likely require a different “version” of SCTE 35, the only way to satisfy all three would be to send slightly different versions to each (exact same video and audio but different SCTE 35). Given that SCTE 35 uses bits per second and video uses megabits per second, this rapidly becomes massively wasteful in terms of bandwidth and encoder resources—it is the ultimate tail wagging the dog (or maybe even the flee on the tail wagging the dog).</p><p><strong>NOBODY’S SAFE</strong></p><p>Even if the content provider goes to the trouble of replicating their video and audio just to provide different SCTE 35 (most of the bigger ones don’t because they have more leverage), there is no guarantee that SCTE 35 will survive transmission and processing. This is because the transcoding and other processing often corrupts the timing of the messages by failing to take into account the decoding and encoding delay. As unbelievable as this may sound, it is absolutely occurring even with established manufacturer’s software. Granted, sometimes this is due to misconfiguration by users who don’t know what a standard SCTE 35 message looks like (because there isn’t a “standard” message…). There are also few tools to inspect the timing relationship between the video and the SCTE 35 message, so it’s often left to the next process in the workflow to deal with.</p><p>When this is added to the ambiguity described in the last section it is little wonder that vMVPDs have all but given up—some have even disabled SCTE 35 altogether on some of their networks.</p><p><strong>A MICRO-SERVICE APPROACH</strong></p><p>If each vMPVD were able to associate the frame boundary in an incoming video stream with the playlist for that channel, they would be able to configure their own SCTE 35 messages and normalize them for their applications on every network. One way of doing this is to send the raw metadata (i.e. the timing of the frame boundaries for the network’s playlist) out-of-band via a cloud-based micro-service to the vMVPD. At the vMVPD, the raw metadata can then be used to construct SCTE 35 messages to the vMVPDs own requirements (or whatever messaging the vMVPD desires).</p><p>[<em><a href="https://www.tvtechnology.com/opinions/scte10435-and-beyond-a-look-at-ad-insertion-in-an-ott-world" data-original-url="http://www.tvtechnology.com/expertise/0003/scte10435-and-beyond-a-look-at-ad-insertion-in-an-ott-world/280536">SCTE-104/35 and Beyond: A Look at Ad Insertion in an OTT World</a></em>]</p><p>Crystal decided to take this cloud-based micro-service approach with its Metadata Cloud product, but in order to do so it needed a way of synchronizing the metadata to the video at the vMVPD. Crystal developed a temporal fingerprinting system that can be applied at source and then used to match the frames of video at any receive location exactly. Once the timing is recovered, it is a very straightforward matter to apply the metadata in whatever format is required. This means that a single broadcast feed can be decorated with multiple different SCTE 35 profiles downstream, at any time—even if the video is processed or delayed for any period of time. The out-of-band “raw” metadata and temporal fingerprints require less than 100 bits per second on average, making cloud processing and delivery for large numbers of networks and storage for months or even years practical at extremely low cost (AWS charges cents per Gigabyte).</p><p><strong>OTHER BENEFITS OF SENDING METATDATA OUT-OF-BAND</strong></p><p>Sending metadata out-of-band means that SCTE 35 is no longer a constraint on what can be sent (it is now a subset of the metadata that can be delivered). This means that it is possible to send graphics—lower thirds, logos, tickers, etc.—as pure metadata and then apply them in whatever format makes sense for the device being used. For example, a ticker on the bottom of a news channel or business network may be viewable on a flat screen TV but would be hard to see on an iPhone. If a clean video feed with no graphics was delivered to the vMVPD (this is straightforward for a content provider to do—they just pick off the video before the graphics are overlaid), it would be possible for the vMVPD to customize those graphics for their users’ devices. The graphics could even become “clickable” and user selectable–it’s HTML5 after all.</p><p>Another important benefit of sending metadata out-of-band is that the same metadata does not need to be broadcast to everyone (as is obviously the case with SCTE 35, which is specified to be in-band in the current standard). This has the obvious benefit of allowing customized/personalized metadata to be mixed in by the vMVPD. Think personalized “clickable” buttons on adverts.</p><p>The temporal fingerprinting has the added side benefit of measuring the transmission delay from source to the receive point. This enables a second screen device to have content synchronized precisely to the broadcast being received in each home—the transmission delay varies widely depending upon the network, MVPD and even TV (it can be anywhere from a second or so for over-the-air, to a minute or more if you are watching on an internet connected TV). Being able to send data about an advert to a second screen that is precisely synchronized to what a broadcast viewer is watching will be enormously beneficial when it comes to enhancing viewer engagement.</p><p><strong>CONCLUSION</strong></p><p>The metadata currently being sent via SCTE 35 is so important to the future of television that its problems cannot be ignored. By sending metadata regarding the video and audio in a linear television network out-of band, the issues of ambiguity and corruption during delivery can effectively be eliminated. It also enables additional metadata (such as graphics) and interactivity to be added without changing the broadcast infrastructure, thereby providing the opportunity to truly unify broadcast and OTT delivery for the first time.</p><p><em>Alan Young is COO for Crystal.</em></p>
                                                            </article>
                            ]]>
                        </content:encoded>
                                                </item>
            </channel>
</rss>