This page contains a Flash digital edition of a book.
22 TVBEurope Cloud for Broadcast


Understanding the cloud for broadcast production


Broadcasters and media companies remain suspicious of the cloud: they are keenly aware that their content is their revenue lifeblood and many are unwilling to outsource it to third party sources and servers. At the same time, the shift to IP broadcasting and next-generation IT services do provide real opportunities for broadcasters in applications such as ingest, review & approval, storage & archiving, transcoding & rendering


By Eric Dufossé, vice president Marketing, Grass Valley


’THE CLOUD’. Just the phrase makes broadcasters uneasy. As an industry, we want to embrace the cost and performance benefits of the cloud just as other industries have. But our needs are unique: our data can be enormous and we really need it now.


Based on the nature of


broadcast — primarily playout, live production and news — there are three major dimensions for cloud services: storage, bandwidth and rendering/processing. There's also one major caveat: the cloud should never be used for online or critical (ready-to-air) media — even the biggest pipe and most brilliant secondary and tertiary connectivity schemes are subject to disruption, both man- made and natural. Simply, the cloud is not a ‘just


in time’ strategy for broadcasters. But it can be a near-line strategy that makes perfect operational, technical and business sense.


Live production What the cloud offers is the ability to have media everywhere and at every time (at least in theory — you do need connectivity and a certain level of performance). But perhaps the biggest driver to the cloud is financial: changing infrastructure and operations paradigms from CapEx to OpEx, with less of an initial investment. Simply start small and grow, complete with versioning and backups. But look very carefully, as the


cost of ownership varies greatly by application. Storage can be very efficient with great economies of scale. Bandwidth availability and management is almost the same for everyone, although in some areas (like the US), the last mile can be served by multiple connectivity


providers instead of just one. For ingest and playout, the cloud makes perfect near-line sense, but only when combined with on-site buffered playout storage. On-site storage could hold hours or days worth of air- critical media depending on your operation and business plan. For non-critical activities such as approval, the cloud might be the perfect place to store low-resolution proxies. For multisite playout


distribution (such as to primary and secondary air sites), the cloud can make sense, but you want the media to hit local storage hours if not days ahead of time to maintain critical on- air operations. Live production is


problematic for the cloud: almost all content is manipulated in realtime — slo- mo, editing, browsing, etc. Even archive material is needed immediately. But the cloud does have a place in some live productions ... as a remote production network. Today, we're just seeing the beginning of this as a split of resources (equipment and people) between primary production on-site and secondary production somewhere else.


Eric Dufossé: Perhaps the


biggest driver to the cloud is financial – changing infrastructure and


operations paradigms from CapEx to OpEx


www.tvbeurope.com February 2013


local access to files. For example, although there are various flavours of 4K, one minute of a popular format would be about 250MB. A 90- minute movie would be 22.5GB.


Live production is problematic: almost all content is manipulated in realtime. But the cloud does have a place in some live productions, as a remote production network


Rendering and processing is


where the cloud gets interesting. Virtual machines in the cloud are very efficient, but don't even come close to the performance of an in-house, well-tuned dedicated hardware solution -- especially if you also consider


That's a lot of bits and bytes to transfer, especially if what you're doing is low-resolution encoding (which could easily be done for 3G content within a server). News and the cloud could be the perfect match. The cloud offers the ability to have all


media available to all staff, but as low-resolution proxies. A journalist can edit their story, mixing locally acquired high- resolution media with cloud- stored low-resolution proxies (while the high-resolution media is uploading in the background) and then push their EDL to the station for finishing. They can even see how other


packages for the same broadcast look, just by downloading the EDL and proxies for that story. AP's ENPS supports this now, with the ability to see programme rundowns and stories to see what others are contributing to the newscast. Most important, with the cloud


at the desktop/laptop level, users interface with the technology infrastructure in an abstract way. Where the content or equipment lives would no longer be a consideration, especially with proxies and their low space/low bandwidth requirements.


Cloud considerations Using the cloud means deciding on a balance between in-house and cloud resources. You need a good understanding of your operational requirements regarding when and where assets are needed. How will you handle


redundant connectivity, especially for the last mile? What happens when (a more likely scenario than ‘if’) you lose connectivity to the cloud? How big is your playout storage buffer? Is it in terms of hours or days? If you're accessing multiple seats of a software application from the cloud, do you have a local version available? But there's only one true question: can you work and stay in business if you lose all cloud connectivity? The answer better be Yes. www.grassvalley.com


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56