1-OUR VIEW
We can safely state that in the foreseeable future premium commercial channels of major broadcasters are going to be played out from on-site facilities as they are now. Some details of the engineering are yet to be determined but in general we can say that playout will involve routing/switching/mixing/superimposing uncompressed or lightly compressed (“mezzanine compression”) flows either originated outside, in studios or by decoding files (e.g. XDcam, etc…). In this regard, it is a good approximation to say that the current model is valid in moving to 2110 from HSDI and the means to connect devices, rooms and facilities and changing the current hardware based video servers for software only devices working inside private clouds physically located in the on-site facilities.
Where we foresee a big change is in the new horizon opened by the possibility of originating channels in the cloud. The pros of this technology are that a new channel can be started virtually in no time at all and without involving manpower or changes in the facility. But the cons are what will determine how these channels must operate. Bandwidth in the cloud is very expensive so creating a circuit of 2110 uncompressed -or even lightly compressed- flows is unaffordable. These channels in the cloud must have heavily compressed outputs that are connected directly with a conventional means of distribution or a CDN. Compression has always been the key when coupling IT and video. It is a critical process that can reduce the quality or force the broadcaster to use large amounts of bandwidth. The selection of the encoder is the most important decision that a broadcast engineer can take. The software encoders have been taking ground from the hardware-based encoders so now a number of broadcast quality manufacturers offer virtual encoders. The problem is that the processing capacity required by software encoders is enormous and in the cloud processing power is as expensive as the bandwidth. This money linked questions are the real cons of cloud based playout based in the classic model of downstream compression.
There is a more efficient but counterintuitive way of playing out from the cloud. The concept is to upload to the cloud the files already encoded in the playout format (typically H264 inside TS to be streamed in RTP). It is very easy to create an automatic workflow that puts graphics and effects while transcoding from the broadcast file formats (e.g. Xdcam, AVCintra, ProRes, etc..) to the ones used for distribution, before uploading to the cloud. If the workflow is properly planned, some files can be encoded with graphics just minutes before emission creating the illusion of live graphics.
One of the suggested uses of the cloud based playout is disaster recovery. This is a bright idea as long as we do not intend to be producing with it a mirror signal 24/7. The correct scheme for disaster recovery based on the cloud is to plan it as the lifeboat of a cruise liner, to be deployed when the need arises. So, the cloud based playout must be the third option after a conventional disaster recovery. Since it is not operational all the time we do no need neither to invest capex nor to waste opex. To continue with the example of the lifeboat on a cruise liner, the deployment must be planned to be swift and in this regard, it must be clear how the signal is going to be sent to the distribution networks (perhaps with a small CDN, or a packetizer with multicast option, or etc..).
Another buzzword in recent shows and customer meetings is that of “virtualization”. It is used liberally to refer to two different configurations. Firstly, it is used as a synonym of playout in the cloud, a subject on which we have already commented. Secondly and more properly is used to refer to software only video servers or virtual machines that are installed over platform virtualisation architectures such as VMware, Oracle and many other competitors in the market today. In this configuration, the software of the video server works in a so called “instance” that emulates the native Windows environment. This kind of system can be reasonable when using virtual storage and/or when the hardware platform is excessive for being used exclusively by the video server software. However, the juxtaposition of layers and the inherent intricacy of the setup makes the systematization of the diagnosis of problems difficult. In general, it must be said that all the software only video servers can work in cloud as described above or in proper virtual environment.
To finish this general approach, based on experience of previous changes of technology, there will be a long transition and there will be, for a long-time a hybrid and transitional environment in which playout in SDI and 2110 will co-exist with the added complexity that this mixture creates.
2-VECTOR 3 IP CURRENT SUPPORT
-Already existingmodels VectorBo LT and VectorBox XL incorporate optional 2110 (or 2026) outputs. So now each of the models will have three flavours, “SDI Only” with four outputs of HDSDI, “IP only” with four outputs of 2110 (or 2026) and “Hybrid” with two HDSDI and two 2110.
–New model VectorBox 264 is a software-only video server that can be installed either in a computer with no dedicated hardware, in a computer with VMware or similar or in the cloud. It outputs a certain number of streams compressed in H264 inside TS and packetized as RTP. The control client can be in the cloud or on-site.
–Pre-rendered VectorBox to playout from the cloud in H264 in TS packetized as RTP while the compression is done on-site to minimize bandwidth and CPU need from the cloud.
