What really broke the BBC's cycling coverage
Was it Twitter that broke the BBC's cycling coverage? Or was it something rather closer to home?
It is, of course, not true. And you'd be surprised what might be to blame.
For a start, as I was clear to point out on Media UK's discussion area, it's not the BBC's cycling coverage. It's the coverage of Olympic Broadcasting Services ("OBS"). While the BBC provided the commentary, also derided by some, it wasn't the BBC's coverage, so the headline and description here is not accurate. But that's not, really, the point.
The main point is that Twitter did not, and could not, have 'jammed' transmissions of race information.
It wasn't TwitterMark Adams is IOC Communications Director. He's quoted as saying: "From my understanding, One network was oversubscribed, and OBS are trying to spread the load to other providers. We don't want to stop people engaging in this by social media but perhaps they might consider only sending urgent updates."
Sending a tweet uses a ridiculously small amount of bandwidth. Want to know how much? This much.
Actually, there's a bit of OAuth authentication before that, which is a little harder to show you, but in total it's probably around 400 bytes; or about three text messages' worth. It's tiny. The response from Twitter acknowledging this is 872 bytes; or about six text messages' worth. In total, that's less than 1.2kB. That's tiny. Assuming you send one tweet every minute, you'll send 72kB's worth of data in an hour. Additionally, Twitter compresses this data using gzip, which could save significant bandwidth on top.
(It's actually considerably more complicated than this: there's HTTP headers and other things to add to this tally. But you get my point).
To be clear about this: simply sending a tweet will not cause any appreciable network load. There is no reason, whatsoever, to "consider only sending urgent updates". Your phone probably uses that amount of bandwidth an hour just checking whether you have any email to download.
So, what is taking the bandwidth?Well, I'm no "IOC Communications Director". But, if I were a betting man, I would put a fiver on something a little closer to home.
The BBC's Olympics app has been a great success. The BBC themselves are crowing about the first few days of their Olympics app, including a tweet that reads, in part:
For watching the bits of the Olympic road race happening where you aren't, I heartily recommend the BBC Olympic app
...so highly likely that at least a few of the spectators were streaming live video to their mobile phones.
Assuming the app uses 64kbps as its lowest video bitrate (as recommended by Apple), it would use 72kB of data in just eight seconds.
Send one tweet every minute for an hour? Or watch eight seconds of streaming video?
Could it be that the BBC's cycling coverage was "ruined" by... the BBC's Olympic app?
James Cridland is the Managing Director of Media UK, and a radio futurologist: a consultant, writer and public speaker who concentrates on the effect that new platforms and technology are having on the radio business.
E-mail James Cridland | Visit James Cridland's website
It doesn’t take a genius though does it James, to stick a major sporting event in 2012, with thousands of spectators owning smartphones standing around waiting for it to come past them, and figure out that maybe, just maybe, the public mobile phone networks are not going to be the thing to reply on for your timing data.
Blaming one well-used app is not really fair, whether it’s twitter or the BBC. The fact is that people waiting for the action are going to be standing around messing with something on their phones regardless.
Maybe they needed ringfenced mobile channels, maybe they needed to find another technology to use, but really, this is a shabby tech fail for OBS and LOCOG.
Cheers, Paul. Being honest, I would consider it significantly less fair to blame a bandwidth-lite app like Twitter than a bandwidth hog like streaming video.
But, of course, I do agree with you; the telemetry should have been carried on the same protected networks as the video, rather than using a domestic mobile phone network.
It’s a well understood phenomena- for the torch relay it was recognised that a ‘rolling bubble of contention’ would accompany the activity and that in areas where there would be a lot of the public a 3G signal could not be relied upon for broadcast critical data. The response of the relay was to utilise alternative channels for carrying critical signals in areas of high contention, but there are options.
In this case the data (timing and location data from GPS) need not have been broadcast critical, or alternative ways of getting the information back could have been found. The former option (tweaking the editorial proposition to avoid reliance upon a flakey element) would seem to be the most obvious option, but as has already been mentioned the editorial around the road race had some issues anyway.
The second option would have been to utilise a non-public bit of spectrum to get info from the bikes to the broadcasters, or alternatively to use other techniques to gather this data. Such techniques do exist- in essence, any where that you have a video stream and a timing signal you can do a sufficiently precise derivation of the location and timings of participants with a bit of computation. The timing info was in the picture all the time, and that data (the picture) is on well protected spectrum and treated very carefully.
It’s worth noting that tens of thousands of cycling fans regularly crowd the mountains of the Alps and Pyrannees – remote areas with minimal mobile phone coverage. And yet France TV and the race organisers, ASO, never have any problem getting some quite complicated telemetry about bike locations from across those mountains. The accuracy is outstanding.
Strangely, rather than OBS outsource the road racing coverage to France TV, they give it to the Dutch to carry out.
I’m pretty sure that there’s a way of reserving bandwidth to get that fairly minimal data back to base. Let’s face it, the bike is pretty much sharing its coordinates and an identifier as to the rider – even less data than a Tweet. I can’t help but note that the Tour de France does have a mobile partner…