'The Cloud' Gets Less Fluffy, Part 1

I was at the NAB exhibition, April 2014, when a senior person from a large US broadcaster came onto the Vidcheck booth and enquired if we had "a cloud solution". I then replied, "What do you mean by a cloud solution?" The person then replied, "I don't know, what do you mean by a cloud solution?"

This has been the situation for the past few years when someone has mentioned "the cloud" – no one has really understood what is meant by it nor even what they are asking for, writes Thomas Dove, CEO, Vidcheck.

However, in the last 6 to 12 months the mists have cleared fairly well – at least in the area of automated QC – so that it is now reasonably apparent what is needed and wanted by those in the broadcast industry. Moreover, many of the elements of the cloud solutions are either available already or will be available prior to NAB next year.

So what is meant by 'the cloud'? Our interpretation is that this covers two principal areas: scalability of processing, which could be on remote or local computers; and scalability of cost of processing to suit the processing volume/requirements.

Pay-as-you-go
The requirement for scalability of cost varies greatly depending upon the organisation. A post-production house for example may only need to process a few hours of media a week or in a month, and the cost of doing the QC on this media is directly attributable to the client project. Therefore the post-production house requires a small-scale solution, which can run on an occasional basis, likely on existing in-house hardware for convenience.

The QC is on a pay-as-you-go ('PAYG') basis where the QC cost is based upon the minutes of media being QC'd, as this matches previous methods of charging for QC. This is available right now from Vidcheck: a 'unit' = one minute of play time, with 10 units for the first minute, so the cost is easily understandable (see screen shot of Vidchecker OnDemand PAYG).

Scaling up (and down) in a local 'cloud'
A large post-production house or small broadcaster may deal with many hours of media in a week, often with a 'typical baseline level' of QC processing requirement.

This is fine: this sort of organisation can purchase or rent the QC processing facilities to meet this baseline requirement. However, there are often peaks of work, where the processing requirement rises dramatically for a short period of time, e.g. where a whole TV series needs to be processed quickly. However it is not economic to buy additional PC hardware and software to cover this maximum workload. This is where 'a local cloud' comes in – to deal with those peaks of work which happen from time to time, where the existing PCs are dynamically repurposed to suit the processing requirements at any time, whether it might be video rendering, ingest, transcode or QC.

A large post-production house or small broadcaster may already have racks of PCs which could be temporarily reassigned to do the QC processing at these peak times. The issue then is how the QC processing software is then spread onto these additional processing 'nodes'. This also of course applies with larger broadcasters, content distributors and other organisations.

The attraction of this setup – where the processing capability scales to meet the requirement – is that it means that the PCs that an organisation already has are being fully utilised and that there is no need to buy additional capacity.

This auto-scaling capability, where additional QC processing nodes are brought into the network automatically, is currently being trialled by Vidcheck: see graphic 1 for an example of local scalability with Vidcheck's products.

It is possible to combine the scaling of processing capability with PAYG cost accounting to optimise both aspects of QC processing costs.

Make it someone else's problem – a remote cloud
What many might consider to be 'the genuine cloud' involves doing the processing completely remotely (off site), on remote computers. This could be using one of the well-known services from Amazon, Microsoft, IBM, BT or others, or just using standard remotely hosted computers. Vidcheck has been using a number of these services for test purposes for around two years now, so is very familiar with setting up new 'machine instances' (processing nodes) on these services.

For many, this may be a very attractive idea as firstly it removes the significant overhead of owning all these computers, with the costs of cost buying these, power, providing rack space, aircon, applying patches and updates, etc.

A larger cost saving however is the fact that with this arrangement is that a user would only pay for precisely the processing power that is needed at any time. If the day-to-day requirements mean that only a single hex core PC is needed then that is all that needs to be rented; then only pay for the additional five 24-core PCs when the peak of work comes along. And, when the cost of processing power reduces every 6-12 months it is easy to take advantage of that to either increase speed or reduce costs, with no need to rip out PCs and buy new ones. See graphic 2 for an example of scalability with Vidcheck's products.

However, there are some questions which need consideration with the fully remote approach.

Continued in Part Two here.

This article is also available to read at BFV online.

(JP)