I’m receiving a lot of correspondence on how to broadcast live events on the web.

I did my first live event back in the mid 90s and, surprisingly, things haven’t changed that much.

Watching the Olympics on the BBC reminds me of sand filled days on remote beaches off the African coast attempting to get live pictures from the PWA World Windsurfing Tour out live over the internet.

However you handle a live webcast the components are the same:

Pictures – you will need on or more cameras; the better the quality, the better the output, so HD is always preferable even for webcasting. Lightweight is the way to go to save on excess duty on airplanes if you’re going abroad, or hire locally (unless, of course, you’re filming windsurfing in 30 knot winds – then heavyweight equipment becomes a plus!). If you’re using multiple cameras I’d always suggest a pro dedicated mixing desk such as Sony’s Anycast. Cables are a pain, and the emerging wireless solutions are worth looking at if the budget allows.

Presenter – watching the red button coverage of the Olympics with the commentary appearing and disappearing is disconcerting – having someone to interpret the pictures and ask questions is a long held TV tradition; in an ideal world if you’re running commentary having two people improves the banter. The problem with this is that you then need monitors for them to watch the video output and special mics for noisy situations. Alternatively you can cheat by having them watch and commentate from a studio – or even your office.

Connectivity – ah, the biggest issue of all is making sure that you’re able to get pictures from the location.. ah, I could tell you some stories about how we managed to get pictures live…. The best, but most expensive way, is to send a broadcast signal, but this involves getting a satellite dish and technician on location, booking a satellite, having a downlink with an encoder, etc.. (There are service providers who can do all of this for you). An alternative, which I always favour if possible, is to encode on site. You will need a reliable upstream link of 1Mbps for this and an encoder with a dedicated encoding card such as those from Viewcast. I’ve used everything from microwaves to hacked together lengths of CAT5 to get an image from the mixing desk to the encoder and to a point where there’s sensible bandwidth – and always make sure that you have Plan B for when some muppet decides to service the local telephone exchange just as you’re about to go live.

Network – a typical Internet TV service only makes modest calls on a network – a single server can easily cope with 200 simultaneous connections, and with each person watching 15 mins, this would equate to (200 x 4 x 24) nearly 20,000 viewers a day; but if all of those viewers arrive at the same time you’ll need 100 servers; that’s when content delivery networks (CDNs) come into play. On top of this, you will need someone managing and optimising the network, providing support in the same way that TV playout facilities do.

Technicians – more than anything you’ll need a bunch of talented, committed people who are resourceful and adaptable; remember, if anything can go wrong, it will go wrong and the first major lesson I learnt in TV was that there are no excuses.

Read more:
Going Live

With the software largely complete and in the process of being tested, it’s time to turn attention to optimising the hardware on which it runs. By necessity, Project V is very complex in its requirements with a range of servers undertaking specific tasks. The aim was to replicate these across the Europe and the US, but we’re encountering serious problems with the Savvis network in the US and have been forced to reconfigure and move servers to the UK.

The problem could be threefold: 1) the connection has been deliberately throttled; 2) a router somewhere isn’t properly configured or working optimally; 3) there’s poor peering between the networks we’re using.

It may seem sensible to have all of your servers in the same data centre on the same connection, but this doesn’t always make sense; setting up a network is often more an art than a science and I’ve been lucky enough to work with some great network managers down the years and have learnt tons about the dos and don’ts.

The problem with networks and servers is that you can easily spend a fortune of hardware and software – Microsoft’s SQL Server is especially prohibitively expensive (resulting in many systems using MySQL instead). And once you’ve spent that money you’ll need some professionals to look after it. So, Project V is totally outsourced. The problem is that some of the processes we’re implementing aren’t supportable by the hosting partners. It’s a classic problem in internet management – a function falling between the gaps in the project.

Read more:
Project V – Slow Connections

The old 80:20 rule really applies to software development (the last 20% takes 80% of the overall timescale of the project). The last leg seems to be the longest, and this is proving to be the case for Project V. As ever this is a combination of developers under-estimating and clients (that’s me) over-specifying (oh, and changing their minds. I really should know better..).

The trouble with software development is that the metalanguage around it suggests that it is a science. In reality, it is an art. An iterative process where craft is at a premium. At the same time, producing code is an industrial process involving different roles and responsibilities. An industry where an idea takes ten seconds and realising it takes ten months. And also an industry where your product is never complete, there are always revisions to make.

So, during our long, hot summer, things are moving slowly to their conclusion. I am sanguine about the prospects for the Project since the actual product is becoming better and smoother every day, ideas are being refined and it will not only be the most cost effective, but also potentially the best, product on the market when it is fully released.

Excerpted from:
Project V – The Last Leg

The disparity between the regulations that broadcasters in the UK, such as ITV, and Google trade under are truly ludicrous. You either regulate video content or you don’t. YouTube’s self regulation is laughable, but that’s the nature of unmoderated content. Now it seems that the legislators are waking up to this.

This is a long standing issue – are ISPs responsible for the websites on their service, or are publishers responsible for what their authors write?

Personally, I believe that there’s a simple measure for this. Any party benefiting commercially from the provision of content (not services) should be regulated. YouTube should be brought under Television Without Frontiers regulations.

And this isn’t an issue isolated to the UK; there is an increasingly long list of countries where YouTube has been banned. But there is a dark side to this. I reckon that the only reason more countries haven’t blocked YouTube is that its influence is not yet significant, but this may change and there is a danger of political censorship overtaking moral censorship.

Excerpted from:
Unlevel Playing Field

Following on from my last post a former colleague has pointed out Ply Media who seems to have some neat overlay tools which work cross platform (thanks, Pete).

Excerpted from:
Plying