« Previous | Main | Next »

HTML5, open standards, and the BBC

Post categories:

Erik Huggers Erik Huggers | 08:25 UK time, Friday, 13 August 2010

Recent commentary on this blog has suggested that our use of Flash on BBC iPlayer and across BBC Online in general, betrays our commitment to open standards. Is this a reasonable assumption? I do not think so.

Open standards have always been part of the BBC's DNA. They are fundamental to driving market innovation and will always be important to the BBC's mission to introduce the benefits of new technology to society. Open standards have the ability to transform our lives for the better.

Our use of Flash is not a case of BBC favouritism, rather it currently happens to be the most efficient way to deliver a high quality experience to the broadest possible audience. Let's also not forget that we already support a very wide range of other formats and codecs to deliver BBC iPlayer and other services to variety of devices.

The fact is that there's still a lot of work to be done on HTML5 before we can integrate it fully into our products. As things stand I have concerns about HTML5's ability to deliver on the vision of a single open browser standard which goes beyond the whole debate around video playback.

Driving open standards is in our DNA

The BBC has a long history of working with standards bodies; both contributing to development and adopting the standards across systems that support our work. It is a tradition we continue to be very proud of and is even reflected in the BBC's Charter that charges our R&D department to promote open standards in its work. Most recently we helped to ratify a new standard for digital terrestrial broadcasting across Europe (DVB-T2).

HTML5 can deliver so much more than a new way of delivering video playback in a browser. Its aims are rooted in the philosophies of Netscape (the browser as the operating system) and even Larry Ellison's (Network Computer concepts) - you take complexity out of the client and deliver it from the cloud. This speaks to a far greater cause than the delivery of video content. The potential democratising power of cloud computing (to make technology and services easily accessible to anyone on the planet) is a noble cause that we support.

For this reason we are committed to the aims of HTML5. In combination with CSS3 and Javascript it promises a step forward for the web. A truly interoperable experience would materially advance the capabilities we can offer to our audiences, by ushering in a new class of rich interactive experiences on the web. The benefits are not one dimensional. As HTML5 promises to allow us to create new online products with the confidence they will work across the web, the savings in our development and operating costs mean we can spend less on reversioning for different browsers and focus on product development. HTML5 can bring the web together in a way that will better allow us to serve our audiences and business partners.

HTML5 is starting to sail off-course

Not too long ago some browser vendors were showcasing proprietary HTML5 implementations; which in my view threaten to undermine the fundamental promise. Recent activity in the HTML5 Working Group and the apparent split between W3C and WhatWG suggests HTML5 might not be on the path we expect, or deliver what I believe our industry requires. Despite grand overtures from Microsoft toward HTML5 support, their new browser is yet to ship and so the jury is out. The tension between individual motivation and collective consensus has brought an end to many noble causes in the past, and here, the pace of progress appears to be slowing on bringing HTML5 to a ratified state. History suggests that multiple competing proprietary standards lead to a winner-takes-all scenario, with one proprietary standard at the top of the stack, which is not where most of us want to be...

Let's keep HTML5 on track

So my request to the W3C, HTML5 Working Group, and major browser vendors, is to continue fervently on the path you began. Understand you are representing the future of the web, as well as businesses like ours with your efforts. HTML5 is more important than any one motivation. Speed is of the essence. Professional integrity is of the essence. We are counting on you to bring one HTML5 to the web and the W3C to help make this happen.

Erik Huggers is Director of BBC Future Media & Technology.


  • Comment number 1.

    The question that the BBC consistently fails to answer:

    If Flash is the application of choice for delivering Iplayer content why make an exception for Apple devices? All the same technical argments remain for Apple devices which mean your approach should be to wait for them to support flash.

    If exceptions can be made for Apple why not for other more popular devices? That is the favouritism you need to answer.

  • Comment number 2.

    "Our use of Flash is not a case of BBC favouritism, rather it currently happens to be the most efficient way to deliver a high quality experience to the broadest possible audience."

    You missed "...while also delivering the appearance of a rudimentary level of content protection which serves to satisfy our licensors.", because if that wasn't a particularly significant factor (even if the BBC seems afraid to talk about it outside of Freedom of Information responses), then there'd be no real issue with the EMP JavaScript substituting in the element where available and serving up H.264 and AAC in MP4 containers to anything capable of playing it, not simply the subset of those user agents shipping with Adobe's implementation of Flash.

    Your comments about HTML5 progress slowing are... odd, to say the least. The latest draft was released yesterday, and none of this is preventing browser developers from implementing its features (which they have been), nor from site authors from using them: HTML5 is designed quite deliberately to be both forwards and backwards-compatible, which is a big part of why it took so long to make it to the stage that it's at now. You can use , the HTML5 DOCTYPE, and lots of other things with precisely zero ill effects in older browsers right now thanks to the way that browsers work and the care taken in specifying these things in HTML5. Other things, such as the new types, are designed to be backwards-compatible, and can easily be feature-detected (allowing JavaScript frameworks to emulate them on older browsers). Beyond this, the specification is reaching completeness, and so progress should slow: it's stabilising. The thread linked to on public-html was the very definition of a "storm in a teacup", and there's little evidence of anything but business-as-usual since.

    I'm honestly not sure what to make of the statement "Not too long ago some browser vendors were showcasing proprietary HTML5 implementations": do you have an example? Something can't be both proprietary and and implementation of HTML5; that's a tautology.

  • Comment number 3.

    @Chris probably because iOS has such a dominant market share of users who actually consume video content on their mobile, an exception has to be made.

    Bare in mind the iPhone represents a platform, iOS. Take into account iPod Touch and iPad, there are millions of users who all consume video on the web in comparison to any other mobile/device platform.

    Flash IS the most efficient way to deliver video (See YouTube post https://apiblog.youtube.com/2010/06/flash-and-html5-tag.html%29 on a desktop browser because all the browsers support flash. Delivery of content to mobile platforms is so fragmented by comparison the only platform that has a wide enough audience to justify an additional delivery mechanism is iOS.

    A standard, open, video encoding format for mobile and decent HTML5 implementation is whats needed to solve this. Google are already making waves with WebM but they still need iOS on board to truly make it work for mobile in my opinion.

  • Comment number 4.


    It's not quite as cut and dry as that, in either case.

    iPlayer streaming to iOS uses HTML5 because a server (via SSL client certificates) can verify that a device is definitely an Apple device, and with non-jailbroken devices, there's no way to do anything with the stream other than watch it. The potential for people to be able to keep copies of fairly low-quality streams (in the face of the widespread availability to largely non-technical users of much higher quality streams) is, apparently, a very real concern. This is why the same mechanism is not used to send MP4-wrapped H.264 and AAC streams to Android devices (see this recent FOI response).

    (It's very clear that iOS support is not market-share-driven: the iPad version of iPlayer, which isn't based on the same front end as the iPhone/iPod touch version, was rolled out on the day the iPad launched. While I'm personally grateful for this, as I own an iPad, it remains difficult to justify on the basis of reach alone, as has often been suggested is the criteria for customisations).

    And yes, while it is true that if you were to pick a single delivery mechanism, Flash is the most cost-effective means of reaching the broadest range of devices, but we know that the BBC hasn't picked a single delivery mechanism: streams are available in formats which many HTML5-savvy clients can play, and the scripting required to switch between Flash and has already been implemented. The scripting behind EMP is quite clever, it's not a difficult determination to make in saying that it wouldn't be a significant amount of effort for the BBC to use (and, indeed, ) in those browsers supporting the codecs it already uses. That is, provided that the content protection concerns described above ceased to exist: and that doesn't look to be happening any time soon, as laughable as they might be when put in context.
    [Unsuitable/Broken URL removed by Moderator]

  • Comment number 5.

    @Mo Indeed interesting stuff didn't think of it from a content protection point of view, my post was solely on viewing the content, not protection, although they go hand in hand - I missed that!

    The iPad version could have been an easy win though. Seeing as making a few adjustments to an iPhone app that already exists could potentially make it an iPad app, even if the initial market share is low, could be worth the effort. My unfortunate lack of iPad means I don't get to enjoy it though!

  • Comment number 6.

    @gavincoop: you're right in that it could have been an easy win. what the BBC actually did was modify the "Big Screen" version of iPlayer and used it hand-in-hand with the "HTML5-savvy" EMP JavaScript they already had.

    This actually leads to quite a horrible UI -- something designed for use from 10' away doesn't lend itself terribly well to close-quarters touchscreen use, but c'est la vie!

  • Comment number 7.

    "Our use of Flash is not a case of BBC favouritism, rather it currently happens to be the most efficient way to deliver a high quality experience to the broadest possible audience."

    It might be efficient, but it isn't an open standard - it is proprietary to Adobe.

    Either you commit to open standards or you don't - the BBC seems to be trying to declare its wholehearted support of open standards whilst not practising what it preaches.

  • Comment number 8.

    How do you expect anyone to take you seriously, when in order to support your argument, you link to inflammatory articles by Shelly Powers and Mr Last Week - two well known trolls who do not contribute positively to the HTMLWG in any way whatsoever, and who have no professional integrity as far as I'm concerned. (There's a reason shy Shelly was banned from posting to the HTML mailing list, and why MLW prefers to hide behind anonymity).

    With regards to the specific arguments raised, it's important to realise that in most cases where the specs have diverged, it's been a result of the HTMLWG making a decision to diverge from the WHATWG. But it's common to see bogus arguments try to pretend it happened the other way around, which is misleading. For instance, the decision to remove Microdata from the HTMLWG spec was made for ridiculous political reasons, rather than solid technical rationale, and so there was no valid reason for the WHATWG to concede on its inclusion.

    But for the most part, aside from minor editorial issues, the HTMLWG spec is a subset of the WHATWG spec, and the split out sections are published separately at the W3C, so the current divergence isn't a show stopper.

    For the most part, HTML5 itself is still on track. It's disingenuous to claim that it's starting to sail off-course. The WHATWG is doing its best to stay on course, despite continued attempts from within the HTMLWG to change it for the worse.

  • Comment number 9.


    I believe you have misunderstood the concept of what an "open" standard is. Flash is certainly not an open standard. It is a freely distributable licensed binary/plugin. An open standard is the source flash is made from as being free and freely licensed for which Adobe Flash is definitely not.

    The fact that the BBC modifies its content to work on the iPhone is clearly not conforming to open standards at all. You have got the argument completely wrong I'm afraid.

    A simply way for everyone to test if the BBC is open, is to browse to it through FireFox that is installed on a modern Linux OS (e.g. Fedora 12/13) and if everything works as is without installing plugins etc. The site can be considered open. If not, for which the BBC fails miserably, it is considered closed.

    Instead of using Flash the BBC should be using Vorbis (.ogg) for streaming audio and media content. Only then can you claim the BBC is moving towards open standards.

  • Comment number 10.

    Oh, come on. BBC policy is strictly opposed to open platforms for video, and we both know that. The BBC will only use HTML5 video if it can either (a) be wrapped in DRM somehow, or (b) linked to a locked-down device like one of Apple's (by requiring a vendor-signed TLS certificate, say).

    The choice of Flash for video is precisely because it is not open.

  • Comment number 11.

    Even if I agree that Flash is the most popular way to deliver video content it does not explain the BBC's actions in February this year when it enabled the verification layer within flash, which closed the door on open source implementations for viewing iPlayer.
    Far from "deliver a high quality experience to the broadest possible audience." - the BBC took a policy decision to block access to iPlayer from any non flash based client so narrowing the audience.
    As a UK resident license payer, I want the ability to choose how I watch my programming - and you took that choice away by disabling many non-profit convergent technologies such as XBMC (which enabled set top box style access using a PC) - was this a threat to your project Canvas?
    Why should it matter how I watch - TV, PC or Linux - the decision is indefensible - I still dont have access from my Nokia X6 - why you may ask - well its not on the "approved" list!

  • Comment number 12.

    You took away our XBMC iPlayer. Quite possibly THE best delivery platform for iPlayer.

    Now rather than obeying all the rules and regulations of iplayer, the plugin has to use unauthorized trickery to get the streams.


  • Comment number 13.

    I thought the comments were correct, HTML5 is along way from being ratified and even then Flash will still be used as it will still be the best option for media of many types. As to Flash not being open, it is far more open that Apples total control over its ios. I expect Flash will be around for many years (whether thats right or wrong we could dispute)and with Flash being 'inbuilt' into future browsers (such as Chrome and others) and the massive increase in Android which of course now supports Flash I think it has a long life.
    Apple do not support Flash of course and that is perhaps why we have so many 'anti' flash comments here from users who have 'i' products.
    Apple may have taken the lead, but sales of Android are growing at a great rate and Apples lead will be overtaken in the next year by the number of Android users who can of course use Flash.
    Apples dominance is already waning, and therefore the talk of the end of Flash is perhaps premature....

  • Comment number 14.

    @nametheguilty just because you commit to open standard's doesn't mean you should use solely open standards. I would imagine the BBC's commitment to open standards is the same as any logical large organization. It will analyze and compare all available methods of delivery and where open standards are comparable or just under par it will take the open standard route. However it doesn't mean everything should be built on open standards or it should not be *accessible* - that's the key word here. If your reading this blog you know what open standards are. The majority of the BBC's audience don't and do not care, all the want is the content, they all have flash so it's logical to deliver the content primarily in Flash to ensure the content is *accessible* to the widest audience, without them having to download xyz browser. If you were entirely open standards at the current state of the internet the video content would not be accessible to a majority of their audience, instead of now which it is probably a minority of niche platforms that cannot access the content.

    @threedaymonk policy is not opposed to open platforms it's opposed to un-restricted content access that allows you to freely distribute copyrighted content without the permission of the owner of that content. Two very different things. Chances are its the copyright owners that force the BBC to deliver content with protection against you stealing their work. Doesn't mean you can't use open standards to deliver the content, which is what the discussion is about.

  • Comment number 15.

    gavincoop: Open platforms by their nature allow redistribution. They cease to be open when you place restrictions on them. The motive may be to prevent redistribution (despite the wide availability of unencrypted content on DVB-T) but the result is a de facto ban on open platforms.

  • Comment number 16.

    With all the BBC's talk of using open standards, why not try using some? Flash is not an open standard, and the few non-adobe flash players that do exist cannot use iPlayer thanks to the verification layer.
    Every platform in use today has good, stable media players that support open standards, there is no need for flash to be used in iPlayer. Just give us an open format stream and let the user decide how to view it.

    So just how much did Adobe pay the BBC?

  • Comment number 17.

    Just to add some context to this discussion (and the point about XMBC made above) see this blog post from March. For an outline of the BBC's approach to piracy see this post from July.

  • Comment number 18.


    If HTML video is not ready, why is it being used to deliver iPlayer big-screen to certain devices (at least one of which also supports Flash)? Given that the HTML video clearly is considered ready by the BBC for certain devices, why not allow other devices which lack Flash to access this existing interface (e.g. generic web-enabled digital TVs; home-built STBs; etc)? Surely some kind of iPlayer access is better for these devices than none at all?

    The arguments from the BBC as to why it can not release a standards-compliant iPlayer for general use have been, to date:

    1. Initially: "Ooh, our external content suppliers demand content protection!". When pressed as to what exactly these suppliers require, the BBC simply refuses to say. When it is pointed out that Flash on general-purpose PCs does *NOT* supply any content protection security; when it is reasonably argued that standard-compliant/open solutions could provide the same security, if not better and with less harmful effects on free market competition, we get new arguments:

    2. "Ooh, but we need control for branding and editorial integrity reasons!", see the recent syndication consultation.

    3. And now, most recently, this "HTML video is not ready!" hatchet job - which appears to be founded on comments from trolls, and appears contradicted by the BBCs' own actions.

    It really is starting to seem that the only conclusion we, outside the BBC, can draw is that the BBC simply wishes to have full control of the platform - and it will use whatever range of excuses to justify this that it can. If this is the case, why not just be forthright and say so "We want full control"? Your syndication consultation submission pretty much says this.

    The BBC has a lot of respect, including from many who have been vocal on iPlayer openness. The BBC will not lose that respect by being clear and open on this subject - it may though damage that trust if it seems to be evasive and employing distractionary arguments that don't stand up to cursory scrutiny. If you were completely frank, you may find some of us are even sympathetic to your desire for content protection, editorial integrity, branding, etc. and are solely concerned about the underlying technical delivery mechanisms being generally open and implementable.

    These goals are not mutually exclusive, despite your fears. The openness/closedness of the software to deliver content and the integrity of the content lie in 2 different dimensions.

  • Comment number 19.

    Paul Jakma: I'd add to that: H.264 video over HTTP on the iPhone also fails to supply any content protection security.

  • Comment number 20.

    Bah, missing, critical word:

    "When it is pointed out that Flash on general-purpose PCs does *NOT* supply any content protection security;

    Should say:

    When it is pointed out that Flash on general-purpose PCs does *NOT* supply any real content protection security;

    For a definition of "real" that's along lines of "great", or perhaps "substantive".

  • Comment number 21.

    threedaymonk: That's a lower res stream though isn't it? The BBC doesn't mind lower-res access in open clients, it seems. E.g. on any half-recent GNOME desktop you've got BBC iPlayer built-in via Totem (development of which I think the BBC supported to an extent) - but annoyingly low res.

  • Comment number 22.

    Paul Jakma: The BBC plugin is still there in Gnome, but it doesn't appear to have any video content in it. It's just radio programmes.

  • Comment number 23.

    Just a quick follow-up:

    At the end of my first comment, I did indeed mean "oxymoron" rather than "tautology". We regret the error.

    In the part where I linked to an FOI response, I've been told that there's a policy of not allowing links to PDF files for some reason. An HTML version of the same document is here.

    Regarding the "proprietary HTML5 implementations" comment, it's been suggested to me that Erik may have meant Apple's "HTML5 Showcase" which only worked on Safari: this is muddling the issues somewhat, as this is largely just a matter of poor site development practices, rather than anything to do with the HTML5 implementation in Safari itself (not to mention that most of those demos weren't actually of HTML5 in any case).

    While it's technically true that HTML5 is a long way from being ratified, this is a testament to the way that the W3C standardisation process works, rather than any practical indicator of usefulness: a W3C standard will only reach Recommendation status when two independent (complete) implementations of it exist, and this is not likely to happen for a while. Indeed, the fact that HTML4 ever reached this status is a hint that sometimes the rules get bent somewhat. So, take this line (and it's one that's oft-repeated elsewhere) with a large pinch of salt.

    On the subject of Flash and content protection: it's demonstrably the case that the content protection provided by RTMP with SWF Verification (and, indeed, RTMPE) is of little consequence: it doesn't make it any more difficult for people to get hold of videos than a referrer check on a video loaded via because the people who aren't savvy enough to use tools to fetch the streams directly can just get the content from elsewhere in any case. Most clueful people know this well, and indeed it's been stated in the past that the measures the BBC puts in place aren't going to do anything practical with the "determined" users -- in other words, it's all about being seen to be doing something, which is enough to satisfy the assorted rightsholders. Unfortunately, the precise terms of the agreements with the third parties are shrouded with commercial confidentiality, so we can never be quite sure what the BBC has agreed to do and not to do (all we do know is that the "general" conditions speak nothing of DRM, and merely of the availability windows which is almost completely orthogonal to this issue).

    As Erik has said: open standards are part of the BBC's DNA and should remain so. They are an integral part of what the BBC is and does, and while individual consumers don't care about the detail of them, they do care that they can walk into any supermarket or branch of Currys and buy a TV which can be used to view BBC programmes, and increasingly there's a need for that to apply to on-demand viewing too.

    At the moment, the BBC has found itself caught in a situation where it can't make use of them in order to satisfy its obligations, and so has to make a 'best effort' in that regard instead. Thus, the BBC uses open standards where it can, and falls back to widely-supported proprietary technology where it has to, even if this is to its own (and the licence-fee payer's) detriment. Realistically, the only way to bring about change in this regard is by ensuring that there is no room for manoeuvre (by way of the Charter and the regulatory framework imposed by the Trust) when it comes to the negotiations with third parties with respect to how programmes can be distributed. And, of course, in ensuring that the BBC doesn't consider the status quo to be an outcome and -- rather than defaulting to defending the position -- is open and honest about its drawbacks and has a view on the future, where picking and choosing supported platforms ceases to be in anybody's interests.

  • Comment number 24.

    @Nick Reynolds
    You are clearly unfamiliar with the XBMC project. It has no links to any methods that would support or encourage piracy. It simply enables the use of a PC and a thin client to bring all your digital media to one place in your living room.

    Placing XBMC in the same context as piracy is unhelpful in my opinion. XBMC no more supports piracy than current windows client does.

    Casual readers here could be forgiven for getting the impression that just because an alternative operating system is used, such as XBMC, that they are engaging in some dark art or piracy - they are not. Its simply that the BBC chose to use technology peddled by Adobe to lock clients to players of the BBC's choice.

    The only outcome of enabling SWF verification was to choke off law abiding projects and license payers from viewing content on convergent technologies. Those wishing to break the law by copying iPlayer content I believe were completely unaffected by this.

    One could argue that the action may have actually turned previous law abiding viewers down those less lawful avenues, rather than reduce piracy, actually increasing it.

  • Comment number 25.

    It is true. HTML5 still has a long way to go before it can be used to its full advantage. It is still far away from being a standardised technology. For example, the codecs for the video element alone is still being argued over, the main contenders being OGG, H264 (a proprietary patent) and WebM. OGG is not a perfect technology and cannot really deliver high quality video without a lot of bandwidth, H264 is a proprietary patent meaning that browsers that incorporate it have to pay a fee to use it, therefore far from an "open standard". OGG is supported in Firefox, Chrome and Opera, H264 is supported in Chrome, Opera and Safari and will be incorporated in the upcoming Internet Explorer 9. The only viable codec is WebM, which is already supported in Opera and Firefox 4 beta and Chrome 6 beta, but will not be supported in Internet Explorer 9. Opera, Firefox and Chrome have pledged to support the WebM codec, but IE9 has not and has opted for the H264 codec instead.

    So as we can see, HTML5 video cannot be a viable alternative to Flash until the codec is standardised and all browsers support it and seeing as Internet Explorer 10 is at least 3 years away, all browsers supporting a standardised codec isn't going to happen for a while unless Microsoft make a last minute decision in incorporating the open source, therefore "open standard" and free to use, WebM codec.

  • Comment number 26.

    td90uk, how can Flash be a better alternative to HTML on platforms which don't have Flash and never will have Flash?

  • Comment number 27.

    @td90uk: there's a gulf between using Flash and using only Flash.

    In a perfect world, the EMP would use in those browsers which support both it and the codecs the BBC is using (mostly H.264 and AAC). That covers almost all of the Mac users, many Linux users, and a huge swathe of mobile users (assuming baseline H.264 and low-complexity AAC, in MP4 containers).

    For the others - it continues to do what it does now. Or, the BBC adds another encoding setup for WebM and serves that as an alternative, and only falls back to Flash in those browsers which support neither WebM nor H.264+AAC via the element.

    The barrier here is not technical. It never has been. The mechanics of implementing this (even with the extra work of building the WebM encoding chain) aren't particularly taxing, and big chunks of the work have been done already (indeed, as far as I'm aware, those responsible within the BBC are rightly quite proud of the flexibility the corporation has in this regard!)

    The barrier here is purely one of contractual obligations, and so arguing about whether HTML5 is suitable for iPlayer video and or audio or not is worthless: were it not for the contractual issues, it could be rolled out in fairly short order, but those issues are even more difficult to solve (and far more important) than attempting to settle on a single codec (the BBC uses multiple codecs and containers right now, without any real hassle).

  • Comment number 28.

    The BBC does not have stupid users. Who, exactly, does Erik Huggers think he's going to fool with this claptrap?

    Once upon a time, the BBC did follow open standards. Then corporate interests overrode the Beeb's mandate. Now you can only watch certain things in specific parts of the world, you can't watch much of anything offline (which is just great on a slow connection, believe me). If there's anything open left on the BBC, it's just as a token.

    I'm in the US. Once upon a time, I was so impressed with the BBC's commitment to its readers, I sent contributions to Bush House. Not anymore.

  • Comment number 29.

    Apple is implementing portions of the standard, some of them as "webkit" extensions. So is Firefox and so is Google and though little is released, so is Microsoft.

    If we waited for the standard to actually be completed and ratified before anyone implemented anything, HTML5 wouldn't be available until five years from now, if that.

    Finally, the HTML5 specification is a theoretical set of features. When Apple and others implement them, they and their users will undoubtedly find that some things work best as described, and that other things that seemed to be good ideas might have better solutions.

    From my perspective, Apple is only guilty of advancing the time when HTML5 is available to everyone.

  • Comment number 30.

    You say -

    'to deliver a high quality experience to the broadest possible audience'

    Sorry, that is not my experience. More often than not, my browser freezes
    when a page has a video content. Sometimes, it is resolved after 2 or 3
    minutes waiting, but often not. The experience is such a pain that I try
    to avoid such pages. Unfortunately, there is often no warning. It stinks.

  • Comment number 31.

    If the BBC wants more open standards, why don't they release their programmes on a new, more open player than DVD/Blu-ray? If they can set the standards for DVB-T2 and Freeview HD, why can't they create & specify something better (and much cheaper to release on - ie. lacking the licensing fees etc., and more open) than Blu-ray?

  • Comment number 32.

    I am a web developer and don't really get this consistant call for Open Standards. Frankly I don't care if code is propietary or not as long as it works and I am happy to licence it if it does. I also write applications (using Flex mainly) and sell them - that's what I do and it's how I earn the money to feed my kids. I earn money out of making software and I fully respect anyone else for doing so also.

    My only aim is to develop solutions that work on as many platforms as possible to reach the highest percentage of users. Recently we had to start stating in our terms and conditions that we do not support iPhone or iPad as we use Flash quite a lot - HTML5 is unlikely to allow us to do the same things as we do in Flash (although we will adopt it once it has reached a significant userbase level).

    So in conclusion, Flash is here now, Flash works, most people have Flash installed - lets use it. If something better comes along that is widely adopted then things may change.

  • Comment number 33.

    Flash is dead long live HTML5! In 2 years time If your still using flash you'll have a hard time keeping the pirates out!

  • Comment number 34.

    #1 Re:Spot on!

    And, why is that when a new technology is being tested it is done with the computers of very good configuration instead of most common or mediocre configuration that avg end user uses. This is where flash fails, it uses way more resources compared to other technologies, and that can only be observed often on a nomal config computer. Same is the case with Chrome guys, they test the browser for goddamn xy mbps (where x,y =/= 0) net speed connection not some kbps connection, which is the common case when you take world population into consideration. Same case can be applied to flash technology too imo, effectiveness of flash video streaming very much depends on how speed your network connection is. I'm with Steve Jobs on this. Come on HTML5.

  • Comment number 35.

    Just to cut out all the techno babble, most people want iPlayer to work on what they have or would like easily identified equipment (phones/OSs/ digi boxes/ consoles, techno stuff etc) that can run it.
    They want the capability of utilising iPlayer, easily spotable at time of purchase, not restricted to one manufacturer or OP software giant they find out about later.

    I will use my own personal example a windows HTC HD2 smartphone that just manages to play a home wifi connected stream. Yet should eat up iPlayer for breakfast, be it live , sideloaded or on demand.

    Anyone would think there's only a certain fruit in the mobile garden. Same for the news, App doesn't = Apple.
    Redress the balance of your service please.

  • Comment number 36.

    I have a question regarding iPlayer's curious handling of Android. Apparently, with Android 2.2, it is possible to browse to the iPlayer website and stream video (but using Flash). However, for iOS, the video is delivered as H.264 + AAC, but wrapped in a QuickTime .MOV container rather than a standard MP4 container.

    The question is - why? Why not simply wrap the video in an MP4 container? This way, both iOS and Android can natively play back the stream (Android can't open the QuickTime format), and Flash doesn't figure in the process. Additionally, since Flash isn't a prerequisite, Android 2.1 and below will also be able to play the video.

    On top of that, they threatened the developer of the excellent beebPlayer app for some odd reason. If you don't build it, someone else will!

  • Comment number 37.

    @threedaymonk: The totem BBC iPlayer plugin is still working fine for me in Fedora 13. Really ultra-cruddy 176x96 @ 12fps resolution though - don't know why the BBC bothered working with Canonical on this, given GNOME is designed for decent resolution display, it's completely useless and never going to displace Bittorrent and/or get_iplayer.

  • Comment number 38.


    From a recent FOI request:

    "We confirm that the BBC does not currently provide streams to Android devices as standard MP4 containers by HTTP streams due to content protection considerations. The BBC hopes to be able to launch an Android application for the BBC iPlayer later this year."

  • Comment number 39.

    This comment was removed because the moderators found it broke the house rules. Explain.

  • Comment number 40.

    I think the BBC is being disingenuous to say that HTML 5 is not ready today.

    It is.

    Look at the Apple HTML5 reference website:

    All modern browsers support HTML 5, like Safari, Chrome and IE9 (soon).

    Rather than moving the agenda forward, the BBC would prefer the standoff of the status-quo.

    This is a case where ideology is hold the web back for consumers.

    Back in the 90's consumers and Enterprises voted with their feet and opted for Windows.

    Today consumers have voted for Apple consumer devices.

  • Comment number 41.

    @40: HTML is still in working draft state. An interview with HTML 5 Editor Ian Hickson can be found at https://blogs.techrepublic.com.com/programming-and-development/?p=718 which includes a proposed timeline.

  • Comment number 42.

    Flash is widely used right now so it seems to be the easiest entry point for video content delivery. Furthermore, flash is also supported on a variety of mobile devices so there could be better support for flash than HTML5 video objects (for now atleast).

    However, the BBC should definitely be looking into providing content via HTML5 standards where possible, i.e. following the example of Youtube which would display videos without flash when the visiting user was using a HTML5 compatible browser.

  • Comment number 43.

    I agree with Dave, if the delivery method is not well-documented, unemcumbered by patents or other legal impediments, then it can be considered "open" in any way.

    Ogg is patent-free, but mp3 is not, for example.

    If someone can't access the "standard" (without paying for it) and implement a solution that can be distributed to anyone without problem, then it's 'open'. Otherwise, it's not. The distribution side is important, we can't expect everyone to build their own software.

  • Comment number 44.


    The problem with Flash is that it is massively inefficient with regards to memory footprint and processor loading. This is acceptable on desktop computers, where memory and power are not an issue, but on battery powered devices with limited resources it is really a non starter.

    The real problem with Flash, however, is that it is a propitiatory format, owned and controlled by a single company (Adobe). If Adobe do not create an iPlayer compatible Flash client for your device, then there is nothing you, or anyone else, can do about it.

    If the BBC stuck to its pledge of using an open standard, any open standard, for content delivery, then it wouldn't matter if there wasn't a particular client for a particular device because it would be straightforward for someone (anyone) to create one.

    Of course, we all know the real reason for the use of Flash. DRM. Prevention of Copyright violation. Considering that the BBC has to broadcast everything to air, using unencrypted MPEG2 streams which are easily recorded and transcoded, this is merely attempting the shut the stable door after the horse has bolted.

    DRM is a failed concept, anyway. It just, plain, doesn't work, and far from preventing "piracy", actively encourages it. If someone cannot obtain the content they want themselves they will often turn to someone else to do it for them. That "someone else" is usually a "professional" pirate or prolific file sharer.

    In other words DRM just makes more work for the very people it is designed to stop.

  • Comment number 45.

    Flash will live long no matter what everyone thinks. It is much more mature platform that html5 and it is usually hated by all those who fear it.

    Also because EMP has been out there for a long time you think it is just a video player. There is much more complexity over the hood that you could possibly imagine. HTML5 is nowhere near to handle all those features. Also a lot of effort went into making it such a great experience that redoing it in html5 does make any sense, simply because IE6 is still out there (as well as IE7 and IE8) and html5 wouldn't work anyways!

    It's like asking BBC to build a car using only a hammer and nails, expecting it to be running on uranium and not caring where to get uranium from.

    Youtube is experimenting with html5 as well. But if you dig deep enough you are going to find out that is will only use it if the device does not YET support flash. It won't even try loading html5 player if flash is available and will be the mainstream delivery method.

  • Comment number 46.


    Of course, the flip side of your argument is the sheer overkill of the BBC requiring users to install a full application runtime environment (Flash 10) merely to watch videos.

    Continuing you car analogy, its like the Government demanding that your car has Air Conditioning, cruise control, CD player, sat nav and sunroof before its even allowed on the road.

  • Comment number 47.

    @Eponymous Cowherd

    The flipside of my argument is the fact that Flash Player 10 penetration currently stands at 97.9% in Europe and doesn't go below 96% anywhere in the world. Taking your approach further you might say why does it only work on Windows, MAc and Linux and not on your graphical calculator.

    You really misunderstood my car analogy. You have to have a car to drive on roads. That's a fact. But that is not enough, because it needs to be road safe, etc.

    If you want to watch iplayer you need Flash, because that's how video is commonly delivered on the web. That is a fact as well.

    Hiding the complexity of the player behind user interface doesn't make the whole player to be simple and easily developed. From what I have seen so far is different companies pumping huge amounts of money to show off what you could potentially do in html5 (assuming obviously you download their browser with all their suggested implementation of the standard).
    Looking at penetration rate it is more likely someone has Flash instead of "their" browser installed, therefore you loose already.

  • Comment number 48.

    Let's face it, the BBC decision to rely on Flash is driven by DRM and licenced content. That is why the BBC is not using open source codecs and distribution mechanisms. That is why the BBC is locking out homebuilt video players like XMBC. And that is why the BBC is involved in the Project Canvas consortium to make it even harder for UK citizens to watch TV content without paying fees to somebody, whether Sky or BT or some other Project Canvas licensee.

    This whole thing is not a technical issue, it is not an issue of providing a high quality experience to the largest possible audience. This is 100% a political issue in which the hidden media players behind the BBC, Sky and other TV companies, are trying to create a CLOSED ecosystem in the UK where revenue will flow from the viewer into the pockets of the hidden media companies.

    There is only one way out of this and it is through political action to stop Project Canvas, and to stop the BBC from televising any DRM licenced content whatsoever. It means that the BBC will likely have to stop showing any American TV content because licencing it restricts it from iPlayer or requires DRM on iPlayer. But this is the route that we have to go down. The licence fee payers deserve to get an open television system in which content is freely available to view through whatever means they choose whether that is XMBC or MythTV or a box from Sky or BT.

    Spend less time in the blogosphere and more time on educating MPs and OFCOM about this issue. When the lightbulb finally goes on, Project Canvas will be dead, and the BBC's license conditions will be changed. Right now, media interests have effectively taken over the BBC and OFCOM and are playing a game of brinksmanship in order to steer UK TV into a closed ecosystem.

    Meanwhile in other countries, people are free to view their TV how they want. There aren't any quality problems and nobody suggests that it is hard to view Internet TV on a TV set. In fact even in the UK you can go to Maplins and get a nice wireless kit that connects an HDMI PC or laptop to your TV. Put the laptop on a side table beside the couch or armchair, and view your TV freely when you want and how you want.

  • Comment number 49.

    This comment was removed because the moderators found it broke the house rules. Explain.

  • Comment number 50.

    Michael - You are off topic. This post is not about Project Canvas or DRM. It's about HTML5. Stay on topic please.

  • Comment number 51.

    Actually, Nick, the post was about Open Standards and Michael's comment was about exactly that, why closed standards are harmful, and why (despite what you claim) the BBC is using anything but open standards.

  • Comment number 52.

    Whatever the technical arguments it is anti competative to require the user to use a particular mode of receiving content distibutors' output in a qasi monopolitic market. Flash has 90%+ penetration because the user is forced to use it. If they are offered attractive recieving devices which don't use it then the content distributors have to bend. The rest of us just 'flash'.

  • Comment number 53.

    One other point against Flash is its poor record regarding security flaws. These can take ages to fix because it is closed source. It is telling also that a 64-bit version of the flash plugin for Firefox (on Linux at least) is not available: any well-crafted code should compile without issues on either 64-bit or 32-bit systems. If it doesn't, then there is something wrong with the code.

    Flash is also remarkably resource-demanding. I get an un-watchable 2 or 3 frames per second when I try to view iPlayer low-res content on my netbook, yet I can view the same resolution non-flash video at a comfortable (but still not ideal) 16 frames per second on the same machine.

  • Comment number 54.

    For the benefit of those argue based on market-share, two important points you have overlooked from earlier in the discussion:

    1. There are many devices which do not support Flash, and never will.

    2. As a consequence of certain devices in class 1, made by vendors the BBC favours, the BBC *already* has developed and deployed a HTML solution.

    These points together render all arguments based on whether Flash is better/worse than HTML, or market share utterly irrelevant. Some other points worth bearing in mind:

    * Despite the HTML technology existing and being available for /some/ devices, the BBC goes out of its way to try to block access to HTML iPlayer. That is, the BBC is expending not inconsiderable effort to *reduce* the availability of iPlayer - somewhat contrary to a face-value reading of its charter.

    * My understanding is that the BBC uses the HTML iPlayer for at least one device which *supports* Flash (Sony PS3), in preference to the Flash version. This undermines all arguments that HTML offers an inferior end-user experience to Flash. Indeed, if this is correct, it re-inforces the argument that Flash has performance problems, as that likely is why the HTML interface is used over the Flash one.

    * Regarding favoured vendors, the BBC repeatedly claims that it bases its decisions on which products to support with the HTML interface on objective things like market-reach. This claim however seems to fly in the face of evidence, given that the BBC had support for iPad *before* it was released, yet could not support the millions of Android phones already out there.

    So exactly why does the BBC choose to spend effort on blocking the HTML interface to devices which could benefit greatly from it? It seems that if we try provide the obvious answer to this that Nick will tell us we're off-topic:


  • Comment number 55.

    The BBC's approach to DRM is outlined in this blog post. I'd like this thread to stay on the topic of HTML5 and open standards, not drift into general discussions on the pros and cons of DRM or the BBC's approach to it.


  • Comment number 56.

    So we can't here discuss the fact the BBC dislikes open standard based interfaces, at least for general use, because the BBC feels it loses control with such interfaces? We can't discuss the fact that the BBC is deluding itself in that regard, as the closed solutions offer no more protection than the open ones?

    Note that these questions are about open standards.

  • Comment number 57.


    The topic of this blog post is HTML5 and open standards. The points you make are general points which have been made before and we still have blog posts open to discuss them. This post is not a general message board/discussion area for DRM or the BBC's approach to it. Thanks.

  • Comment number 58.


    The BBC has the following concerns (at least) about the general use of the HTML interface:

    1. Branding
    2. Editorial control
    3. Content protection.

    So, specifically in the context of HTML iPlayer, to what extent are these issues valid and where there are issues, how can they be addressed? Can we discuss that here?

  • Comment number 59.


    none of these are mentioned in the blog post. Content protection can be discussed here.

  • Comment number 60.

    You cannot discuss the relative benefits of Open (HTML5) and Propitiatory (Flash in this context) standards without discussing content protection / DRM. The issue is that content protection systems rely on "security by obscurity" and, hence, are only ever able to be implemented with any degree of effectiveness in fully closed systems.

    Saying you can discuss open/closed standards, but must not mention DRM is like starting a discussion on the 1940's, but saying you must not mention the War

    (I did once, but I think I got away with it.....)

  • Comment number 61.

    Nick -- The BBC has specifically confirmed that it will not use open standards for the delivery of video content because of content protection concerns. A big part of the perceived benefits to HTML5 is a means to embed video using those open standards, without the aid of third-party plugins.

    Comments explaining this (because it inexplicably isn't spelled out in the blog post, again) are quite obviously entirely relevant.

  • Comment number 62.


    Let us remind ourselves of what Erik's post says:

    "The fact is that there's still a lot of work to be done on HTML5 before we can integrate it fully into our products. As things stand I have concerns about HTML5's ability to deliver on the vision of a single open browser standard which goes beyond the whole debate around video playback."

    So this blog post explicitly is about the short-comings in HTML video, as the BBC perceives them. Erik doesn't really expand much on the details, other than to point at some blogs complaining about the standardisation process, as an example. However, we know, from a number of discussions and indeed consultation submissions, that the issues on that short-list I gave are also among the BBCs' issues with HTML video for general usage. Presumably the work-to-be-done referred to by Erik includes a desire to address those issues.

    Yet we are not to discuss them? ;)
  • Comment number 63.

    You'll notice that despite my interventions I haven't actually removed any of your posts yet. I'm trying to set boundaries and keep the discussion on topic so it doean't drift.

  • Comment number 64.

    I had noticed. ;) Cheers.

    It would I think be interesting to discuss whether it is possible (and if so how) to sufficiently address the BBCs' issues, such as the 3 I gave, within an "open" HTML iPlayer. I have my opinion, just wondering what others think...

  • Comment number 65.

    Oh, for "sufficiently address": All the BBCs' existing solutions have big holes. The Flash RTMPE backend interfaces still are accessible to various tools, the SSL-authenticated devices which are allowed access to the HTML interface are often trivially "jailbreakable" allowing the content to be copied and/or the SSL client cert to be extracted.

    So, any solutions to the problem of the BBC perceiving the HTML interface to not give sufficient control similarly should not be required to be completely watertight/infallible. It should be sufficient to just put off most non-technical people. Right?

  • Comment number 66.

    OS linux fedora 13, browser firefox.
    Try to view any content on BBC iplayer. Prompt = You need to install Flash to play Chuggington: Puffer Pete's Big Show.

    Boo Hoo can't watch Chugginton!

    Download the Flash player now.

    Response Sod off BBC no way!

    Last Word - come on Erik be honest.
    Which part of adobe (C) (P) flash player is an open standard? It really is quite simple really (hint none).

  • Comment number 67.

    How have 'open standards' always been part of the BBC's ethos? Most of last century 'open standards' had no meaning in relation to what the BBC did. Were there open standards in radios or TVs or what? Nonsense!
    Moral: Never trust anyone who talks about a company's DNA.

  • Comment number 68.

    Flash player represent many security issues, I just don't know why many websites still using it while the HTML 5 is there, I've made a commitment to never install it on my windows 7 machine.

  • Comment number 69.

    I am using a White MacBook Running OS X 10.6.5 and Flash crashes all the time in Safari Version 5.0.3 (6533.19.4) and Chrome 7.0.517.44.

    I have enabled the HTML version of YouTube, as the same thing used to happen frequently, and I get little problems now.

    Its as simple as that. HTML for video works fine right now and you should just get on with it. Check out the example here from Apple:


  • Comment number 70.

    I truly hate the experience I have with the BBC News website concerning video delivery through Flash. Every time I click to play a video it takes about 60 seconds to load the feed, every time! Not only this but when I visit the BBC website for the first few videos I click they always crash! Always. But I only know this after the 60 second buffer!

    Where as the BBC's iPlayer (which is flash based) loads instantly! Why is that??! Further The Guardian loads instantly and of course YouTube works very well when in HTML5 mode.

    I got so fed up with this daily ritual of disappointment that I decided to make a video about it and although I only use Safari, the problems are the same in Chrome and Firefox. I run Snow Leopard (10.6.5) and the latest versions of the browsers I have, still the same problem on each.


  • Comment number 71.

    Finally! Dont get me wrong I like flash, but not with my macs! I will finally get good video on my iphone from bbc news. Every time I click to play a video it takes about 60 seconds to load the feed, every time! Not only this but when I visit the BBC website for the first few videos .

    [Unsuitable/Broken URL removed by Moderator]

  • Comment number 72.

    Flash will live long no matter what everyone thinks. It is much more mature platform that html5 and it is usually hated by all those who fear it.

    Also because EMP has been out there for a long time you think it is just a video player. There is much more complexity over the hood that you could possibly imagine. HTML5 is nowhere near to handle all those features. Also a lot of effort went into making it such a great experience that redoing it in html5 does make any sense, simply because IE6 is still out there (as well as IE7 and IE8) and html5 wouldn't work anyways!

    It's like asking BBC to build a car using only a hammer and nails, expecting it to be running on uranium and not caring where to get uranium from.

    Youtube is experimenting with html5 as well. But if you dig deep enough you are going to find out that is will only use it if the device does not YET support flash. It won't even try loading html5 player if flash is available and will be the mainstream delivery method.
    [Unsuitable/Broken URL removed by Moderator]


More from this blog...

BBC © 2014 The BBC is not responsible for the content of external sites. Read more.

This page is best viewed in an up-to-date web browser with style sheets (CSS) enabled. While you will be able to view the content of this page in your current browser, you will not be able to get the full visual experience. Please consider upgrading your browser software or enabling style sheets (CSS) if you are able to do so.