Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
The Media Media Software Linux

BBC Brings DRM-Free Content To Linux Users 131

eldavojohn writes "The BBC is planning to release some of its programmes to users of GNU & Linux. You won't see Doctor Who or Dragons' Den on there anytime soon, but they have been working with Canonical & Collabora on getting this out there for Totem users. The developer blog mentions that the sheer number of options in the open source world actually makes this difficult to accomplish."
This discussion has been archived. No new comments can be posted.

BBC Brings DRM-Free Content To Linux Users

Comments Filter:
  • by gnutoo ( 1154137 ) * on Friday October 31, 2008 @12:10PM (#25585851) Journal

    Multiplicity of platform is not a problem for free software, so I'm confused. Every distro is able to use xorg, for example, and people who want to help out go there not to a distribution. If BBC releases free software, everyone else will be able to use it. It's nice of them to dive deeper, but if the backend work to totem is free, I expect it to turn up in my favorite distribution soon. They seem to understand this:

    The whole stack is free software - from URIplay through to Totem, the media player. Some codecs will involve a download, and in some territories (mainly outside the UK) may be restricted, but the underlying framework is free and open.

    The question then, is why they worked with a specific distro rather than upstream. The Totem plugin says it uses Dirac, that's cool.

    • Re: (Score:3, Insightful)

      TFA said that other distros will be worked on. They chose to start with Ubuntu as it appears to be the most popular desktop(Joe user) distro.

      This news is a pleasant surprise and I hope more media outlets catch on, but the article makes it clear that it does take a lot of work to make it happen:

      Lots of this work involved changes to the underlying infrastructure of Gstreamer, as well as developing the plugin for Totem.

      That sounds unfortunate, because most people perceive something as ubiquitous as streaming media to be a given, so the complexity of making it Just Work(tm) sounds intimidating. It's bad for Linux desktop adopt

      • Re: (Score:3, Interesting)

        by osu-neko ( 2604 )

        TFA said that other distros will be worked on. They chose to start with Ubuntu as it appears to be the most popular desktop(Joe user) distro.

        Joe the User supports Microsoft, even though his current computer and the computer he's thinking of buying would benefit more from Ubuntu. :p

      • I would have thought Xandros was the most popular desktop distro as it ships with the Eee, and most other netbooks. The HP one has SuSE. I haven't seen any with Ubuntu.

        I am typing this on Ubuntu here, but Slashdotters who install their own OS are very much in the minority.

        • by awrowe ( 1110817 )
          Have a look at the elonex webbook - ubuntu from the get go, although they are now shipping a windows xp version (which is a bit of a shame).
        • I haven't seen any with Ubuntu.

          I am typing this on Ubuntu here, but Slashdotters who install their own OS are very much in the minority.

          Uhh, Dell? [dell.com]
          Oh, and they now have Ubuntu (and FreeDOS) right there in the side bar!

    • Re: (Score:3, Interesting)

      by Ed Avis ( 5917 )

      The thing is, when people are faced with more than two choices, they tend to panic and dither and get put off. It's surely a bug in the way the human mind is designed, but given that the original maintainer seems to have gone quiet for a while, I don't think a patch will be forthcoming. So we have to work around the bug. One way to do that is to reduce the number of choices that have to be made, or at least, as the Python folk say, 'There should be one obvious way to do it'. Even if what you end up with

      • Re: (Score:3, Informative)

        by ShieldW0lf ( 601553 )
        The thing is, when people are faced with more than two choices, they tend to panic and dither and get put off.

        Tell me about it. Should I use the BBC, or should I just stick to getting my fix of British culture off bittorrent sites...

        Yeah, too confusing. I'm going to stick to torrents. No one ever told me that they had to erect barriers around me in the name of other peoples 'interests' on a torrent site.
        • Re: (Score:2, Funny)

          by TheABomb ( 180342 )
          Or you could pay good money for a cable or satellite provider to deliver BBC America directly to your telly, and then only have to wait anywhere from four months (Doctor Who) to nine years (Spaced) to see them. Gotta be faster and easier than either BitTorrent or the Beeb just using Flash, right?
    • I know it isn't free (GPL) software, but I really don't so much get why they didn't just use Flash, or even Moonlight for that matter...
      • They are using flash video at the moment. I guess this is for the download option, which currently is DRM infected wma.

  • by viridari ( 1138635 ) on Friday October 31, 2008 @12:15PM (#25585933)

    The developer blog mentions that the sheer number of options in the open source world actually makes this difficult to accomplish.

    h.264 video, AAC/AC3 audio tracks, in an MPEG4 container. It'll play on almost anything modern.

    Announce new content via RSS feeds.

    Distribute it via BitTorrent and allow the consumers to foot the bandwidth bill for distribution.

    Until it is this simple and straightforward, you're doing it wrong, BBC.

    • by abigsmurf ( 919188 ) on Friday October 31, 2008 @12:22PM (#25586033)
      .h264 is an incredibly CPU intensive codec. It would increase the cost of players and make it harder for most mobile phones to cope. Bittorrent is awful for streaming (although I believe there is work on a p2p streaming protocol) and could you imagine bittorrent on someone using a 3G data connection(either a phone or laptop)? It would cost them a fortune.
      • by sam0737 ( 648914 )

        It's might still be CPU intensive today. But not next year.

        Moore law works on CPU, and I am confident that 1080p will still stand for at least one decade. (DVD quality already did, right?)

        • by camperdave ( 969942 ) on Friday October 31, 2008 @02:11PM (#25587705) Journal
          A year from now my 800MHz pentium will still process as if it were an 800MHz pentium, regardless of Moore and his oft-quoted "Law". So the codec will be just as CPU intensive then as now.
          • Ah, see, there's your problem. Most users of streaming video aren't still stuck on an 900 MHz pentium, and they would actually like to trade some of their spare CPU cycles for better video quality. That may suck for you, but you're in a minority. Hell, my computer is like four years old and underspecced, and it can still play most H.264 videos without an issue.
            • No, they're not stuck on a 900MHz pentium, but a lot of them are stuck on a 400MHz Arm chip.

              • ...and a 320x240 display most likely. And smaller storage space than a full computer. Not to mention it's not a good place to run BitTorrent. Those people should probably use a different version of the media. I'm sure they could distribute a 'mobile' version, or someone else could do it if provide the full resolution H.264 video.

          • The decoders' performance often improves over time.

        • by tepples ( 727027 )

          It's might still be CPU intensive today. But not next year.

          But if you have 84 million of today's devices in the field, you can't easily replace them all next year. Heck, some devices barely manage to decode 256x192 pixel DivX at 12 fps because they have a 67 MHz CPU.

          • Those devices should probably not be trying to view a higher-definition video stream, H.264 or no. In contrast, most ordinary (non-embedded) computers for the past few years have been able to play H.264 pretty easily at near-DVD quality. Mine can, and it's creaky and aging.
        • >"It's might still be CPU intensive today. But not next year." Why do people still come out with this shit? Software should be written properly. If you write a bad algorithm then you should correct it rather than wait for CPU power / Memory / whatever to become cheap enough. Anything else is lazyness.
          • Software should be written properly. If you write a bad algorithm then you should correct it rather than wait for CPU power / Memory / whatever to become cheap enough. Anything else is lazyness.

            We're talking about video here... One of a handful of normal user applications that is still completely CPU (and bus-speed) bound. H.264 decoders are already almost as optimized as they can get, and no skilled programmer is going to step in and make any significant headway there.

            I generally agree with you... softw

      • by viridari ( 1138635 ) on Friday October 31, 2008 @12:29PM (#25586167)

        h.264 is handled quite nicely by nearly every Apple product, many new cell phones, modern flavors of Windows and Linux, modern PC's without any additional hardware offloading. Television providers around the world are bracing to switch over to h.264 streaming and I believe some are already there. This is, effectively, the prevailing standard for broadcast quality high definition digital video.

        Sure, BBC can provide a streaming option for those who prefer it. But I'd wager quite a few will opt for downloading the whole show and watching it stutter-free, which also gives them the option to keep it or discard it when done.

        • Some devices, such as the Linux-friendly Popcorn Hour [kolbu.com] perform well for h264 because they have built-in hardware decoders for that purpose.
        • h.264 is handled quite nicely by nearly every Apple product, many new cell phones, modern flavors of Windows and Linux, modern PC's without any additional hardware offloading.

          Most hardware devices (iPod/iPhone included) impose numerous serious restrictions on which H.264 features can be used.

          It's common that you have to disable B-frames, disable CABAC, set a low IDC, etc., for compatibility with the above devices.

          At that point, you've eliminated practically ALL the benefits of H.264 over older video codecs

      • by Winckle ( 870180 )

        this isn't about streaming, I think the GP refers to the download version. The streaming version uses flash.

      • H.264 isn't too much more CPU intensive than MPEG-4, but it's far more memory intensive. That's what makes it tough for phones.

        • Comment removed based on user account deletion
        • H.264 isn't too much more CPU intensive than MPEG-4, but it's far more memory intensive. That's what makes it tough for phones.

          I don't know where you got that information from, but it's utterly untrue. On a very fundamental level, H.264/AVC is vastly more computationally intensive than MPEG-4 ASP/Divx.

          See half-pel, in-loop deblocking, CABAC, arithmetic coding, 16 B-frames, multiple reference frames, etc. Numerous iterative processes that are highly computationally intensive, none of which are used with MP

          • 16 B-Frames and multiple reference frames are memory intensive, not CPU intensive. That was my main point.

            During decode, there's no additional CPU work to reference against a 2nd (or 3rd) frame, but it does take a lot more memory.

            Aritmatic coding/CABAC I think is only used in the main profiles, most H.264 content the BBC would be sending would be baseline profile.

            • During decode, there's no additional CPU work to reference against a 2nd (or 3rd) frame, but it does take a lot more memory.

              Yes, it does take additional "CPU work".

              Aritmatic coding/CABAC I think is only used in the main profiles, most H.264 content the BBC would be sending would be baseline profile.

              By the same token, you could say that the BBC would be restricting the video to 1 or 2 references frames, and a single B-frame (much like Quicktime does). Even then, you'll still have to deal with qpel.

              And after

              • I do agree these restrictions (which are very common) do reduce H.264 to not much better than Xvid-era CODECs.

                However, I again state it doesn't take additional CPU work to reference against a different frame. You just have multiple frames in memory and make your changes against a different buffer. No individual macroblock depends on more than one reference frame, so you don't have to do any extra work, just keep two (or more) different references in memory to work against.

                Of course, this is all on decode. O

      • H.264 is designed to scale from handheld devices to beyond HD. It has all sorts of tuneable options that trade CPU usage for bitstream size or quality. Make each episode available in three options - high, moderate, and low quality. If you're on a mobile phone with a 3G connection you pick low quality. If you're watching on your HDTV on a good Internet connection, with a fast CPU, pick high. Otherwise pick medium.
    • by Neil ( 7455 ) on Friday October 31, 2008 @12:31PM (#25586215) Homepage

      They are doing it wrong.

      The problem is that they are trying to control the "user experience", as always. The blog doesn't actually say anything about the codecs or transport streams used. It is all about the Totem plugin that lets one browse the list of programmes on offer.

      Dear BBC: Use open formats. Make it easy to get at the files or streams. You will not need to worry about the diversity found in various Linux distributions and different desktop environments - the development communities associated with the various desktops and media players will write all the user interface tools for you!

    • Well, they're trying to use Dirac...

      BitTorrent is likely a bad idea...

      But either way, I agree, I don't see the problem. I've been streaming video for years on Linux.

    • h.264 video, AAC/AC3 audio tracks, in an MPEG4 container. It'll play on almost anything modern

      That will draw major criticism from the "free software" people (as opposed to the "open source" people), as most of those technologies are patented.

    • by Tweenk ( 1274968 )

      Better: Dirac video, OGG audio, Matroska container. Every piece of your proposition is patented.

    • by trawg ( 308495 )

      h.264 video, AAC/AC3 audio tracks, in an MPEG4 container. It'll play on almost anything modern.

      h264 isn't 'open'. It's a proprietary, patented system that requires licensing fees. This is why it's not supported out of the box in Ubuntu (or at least, why it wasn't - I assume it's still not supported in 8.10 ,but haven't checked).

      The BBC has Dirac though; I wish they'd start using it!@#

  • Little new? (Score:1, Flamebait)

    by abigsmurf ( 919188 )
    Seems to be almost entirely radio programs.

    However they've offered DRM free streams and podcasts for years now, are they just intergrating these into iplayer?

    Someone needs to invest in an open source DRM mechanism. You have people like the BBC who have good intentions regarding the availability of content but the lack of any DRM at all means their hands are tied when it comes to Linux.

    If some of the more talented OSS devs got off their high horse, they'd realise that if they were the first to create a

    • by Xtifr ( 1323 )

      a true secure DRM

      This is what we in the trade call "an oxymoron [reference.com]. :)

      The best you can really do is obscure things as much as possible and hope that slows people down. The obvious problem there is that providing the source code doesn't help to obscure things. And if you don't provide source, about the only Linux vendor who's going to work with you is SCO, whose OpenLinux Server is not exactly flying off the shelves these days. :)

      Something like TPM can help, but even there, the leading provider of TPM-based systesm (IBM) admi

      • Re: (Score:1, Flamebait)

        by abigsmurf ( 919188 )
        There are plenty of encryption mechanisms out there where people know exactly how they work yet are unable to break them without insane amounts of computational power.

        A private key system with a truly random engine behind key generation could potentially be as tough to crack as a closed source one.

        • Re:Little new? (Score:5, Insightful)

          by Xtifr ( 1323 ) on Friday October 31, 2008 @01:56PM (#25587513) Homepage

          Encryption, yes, but with DRM, the goal is to provide decrypted data without letting the person in physical control of the machine know how to decrypt it. I can easily provide you with encrypted audio/video files and no key, but that won't be very useful to you since you won't be able to play them. If I want to allow you to listen to/view the files, I have to provide you with the key, so you can decrypt the data. But then it's no longer encrypted (by definition). My only real option at that point is to try to hide the decryption mechanism so you don't know how to apply the key to the data (and may not even know exactly where the key is), and the decryption will only happen behind the scenes, as it were. But if you have the source to the decryption tool, I haven't done a very good job of hiding the decryption mechanism.

          The entire problem with DRM is that it's trying to prevent access by the same people that it's trying to grant access to. If you can't see the inherent contradiction there, I don't know how I can make it any more clear.

          The most secure key system in the world doesn't help you if you need to give the decryption key to the same people that you're trying to encrypt the data against.

          • But then there are also plenty of one way encryption mechanisms which mean you NEVER have access to your own data, most commonly used in passwords. In a large portion of systems with fairly secure login systems it's impossible to retrieve a password.

            This is an example of someone's own data being deliberately made inaccessible to them by rights management. It may seem trivial but if you go by the pure OSS principles being thrown around a lot here, 1 way encryption is immoral and should never be used in GPL

            • No way anybody would say that 1-way encryption (AKA hash) is immoral. But DRM is not about that, DRM is about granting access to YOU read the data, while denying access for YOU to read it. Giving access to nobody is quite easy, giving access to some specific person is a solved problem, but giving access to the same person you want to deny access can't be solved.

              In related news, on Soviet Russia DRM gives YOU access to the data while it denies YOU access to it! Hey, I never tought I'd ever repeat that meme :

        • Re:Little new? (Score:4, Insightful)

          by JesseMcDonald ( 536341 ) on Friday October 31, 2008 @02:03PM (#25587599) Homepage

          The problem with DRM isn't the strength of the encryption, it's the fact that some component of the user's (presumably hostile) hardware must possess both the key and the data in order to display the DRMed content. There's no need to break any encryption when you already have the key.

          A closed-source system at least has the option of obscuring the key and decrypted content inside a binary program with a draconian anti-reverse-engineering EULA (and even that doesn't work in practice). Truly open-source DRM software could be trivially modified to just dump the decrypted data to a file.

          Ultimately, DRM can't possibly work unless the content provider has full control over the data path, from decryption all the way through the viewer's senses. Such control is plainly incompatible with the open-source mindset. In order to remain effective, some part of any DRM system much always remain closed to inspection and modification by the owner of the device it's running on.

        • by Draek ( 916851 )

          Yeah, but the difference is, in those encryption mechanisms it's assumed that the attacker and the recipient aren't the same person.

          Simply put, DRM is cryptographically stupid, and no amount of OSS devs will ever be able to change that.

    • Re:Little new? (Score:5, Insightful)

      by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Friday October 31, 2008 @01:10PM (#25586887) Journal

      Someone needs to invest in an open source DRM mechanism.

      Open source is fundamentally incompatible with DRM.

      Either you have security-through-obscurity (in which case, I can just look at the source code), or you have at least some of the DRM implemented in hardware -- in which case, it's severely crippled your computer and your ability to run arbitrary software, including modified versions of the original "open source" code.

      Which pretty much kills the point of open source. Look at Tivo for an example.

      Not that it's stopped other people from trying...

      if they were the first to create a true secure DRM format,

      That is impossible. DRM, by its very nature, cannot be secured. The more "secure" you get, the closer you get to having a console or a set-top box, instead of a computer -- and it's still not secure, just that much more of a pain to crack.

      they would be free to shape it in a way that is best for consumers whilst still being good for content producers.

      "Best for consumers" means being able to do whatever you want with it, except pirate it. One of the things I want to be able to do with my media is use it on entirely open systems. This is a reasonable request, I think, and it is not itself piracy. However, an entirely open system would by definition make piracy possible.

      And "best for content producers" generally means "not pissing off your customers".

      So, the best for both parties is to abandon DRM. The content producers haven't realized this yet, and you aren't helping the situation by pretending that DRM can work.

      • "So, the best for both parties is to abandon DRM."

        Yes, but it is not better for the DRM provider, and this one is the party with the hightest publicitary* spendings

        * Publicitary spending is composed by golf sessions, strip clubs and old plain bribery.

    • What is really needed is not so much "open source DRM" but rather (1) standard protocol for transferring digital rights from one person to another, and (2) an "intellectual property registry" to record who has which rights. Think OpenID, plus a list of content you've purchased.

      Having "bought a licence" for some music or a movie, you should always be able to listen to it or watch it. But that's not guaranteed when the publisher is the one running the IP registry: we've seen several recent examples of publish

    • by Stormwatch ( 703920 ) <(rodrigogirao) (at) (hotmail.com)> on Friday October 31, 2008 @01:16PM (#25586981) Homepage

      Someone needs to invest in an open source DRM mechanism.

      That's like asking the Red Cross to build a torture device.

      • The Red Cross frequently use tools that inflict incredibly amounts of pain on people and can also be used for torture.

        A scalpel has good uses and it has sinister uses. Don't blame the tools for their misuse.

    • Re:Little new? (Score:4, Insightful)

      by ratboy666 ( 104074 ) <fred_weigel@[ ]mail.com ['hot' in gap]> on Friday October 31, 2008 @01:35PM (#25587221) Journal

      Quoting:

      "Someone needs to invest in an open source DRM mechanism. You have people like the BBC who have good intentions regarding the availability of content but the lack of any DRM at all means their hands are tied when it comes to Linux.

      If some of the more talented OSS devs got off their high horse, they'd realise that if they were the first to create a true secure DRM format, they would be free to shape it in a way that is best for consumers whilst still being good for content producers. Being first would mean the chances of adoption were much greater."

      And now the answer:

      Holy shit! I cannot believe I actually read that.... We develop an OPEN platform, in all senses of the word OPEN. Indeed, the ONLY rule is that it cannot be closed. When someone finds a away around this, vast parts are re-licensed to prevent it.

      The ONLY purpose of "DRM" is to close off the media. It does not make sense to use "OSS devs" and "create a true secure DRM format" in the same sentence.

      Now, its NOT the kernel: the linux kernel remains under an older GPL -- the desktop being targeted is GNOME. Think about that for a millisecond. Now you should be laughing; if not, I'll let you in on the joke here -- the entire stack between the kernel and the X server is controlled by the GNU.

      Now, you could go with KDE (QT) and Trolltech -- but I don't think you are going to get a (much) better reception.

      Go ahead, try... it's purely political. (those "OSS devs" aren't getting off that high horse).

      • So, what's your view on open source encryption software like TrueCrypt then? Encryption is just another form of DRM.
        • Re: (Score:3, Insightful)

          by deraj123 ( 1225722 )

          It's actually fairly different. A more accurate statement is that DRM is just another form of encryption - one where the decrypting algorithm/tool is a black box. As soon as you figure out how to implement a black box in open source, an open source DRM will be possible.

          Also, the GP missed the point a bit as well. It's more than political, there's a logical barrier.

    • Maybe they could solve the Halting Problem, too.

      A free/open source DRM mechanism is impossible by its very nature.

      Consider a DRMed song. Assume it's in encrypted form, so I can't just look at the data.

      In order to play it, I have to have something that will decrypt it, or it can't get to my speakers. Therefore, it will exist in plaintext format somewhere in the software while it is running.

      Now, since this DRM software is open source, I can get me a copy of the source, and I can change it so that i

  • Wha? (Score:5, Insightful)

    by JustinOpinion ( 1246824 ) on Friday October 31, 2008 @12:23PM (#25586067)

    The developer blog mentions that the sheer number of options in the open source world actually makes this difficult to accomplish.

    I call BS.

    The diversity of options is only a problem if you try to specifically target a particular configuration. Doing so is dumb--In fact I can't think of any good reason to do so. (Hint: DRM is not a good reason.)

    For instance, if you just have a link to a standard media file (e.g. mpeg) that the user can download, then you're done. The user can then use whatever browser they want, with whatever media player they want, and whatever operating system they want. The diversity of options is then the user's problem, not the distributors.

    Invariably these "there are too many options to support" complaints arise because people have ulterior motives in wanting to target the OS/software/format more specifically (DRM, lockin, user tracking, advertising, promoting a particular OS/software/format, etc.).

    (Note that I don't want the negative tone of my post to take anything away from the announcement. It is surely a good thing that they are working to make their shows available to us Linux users. That's great! But if they are truly going with a non-DRM solution, then why the heck don't they just skip the middleman and let everyone just download a simple file?)

    • The bloke whose blog it is is the "Portfolio Manager, Rapid Application Development". He's not going to go very far if he just says "there's lots of free stuff that does this already" and then buggers off down the pub.

      He has to make it look like he's doing something, and make sure that the buzzword quotient is high enough (hence, I suspect, namechecking Canonical - not widely known as content suppliers).

      A "link to a standard media file" may be ideal for you, but to a user who doesn't know that there are al

    • Advertising is hardly an ulterior motive, at least when it comes to television networks.

  • difficult? HUH? (Score:3, Insightful)

    by Lumpy ( 12016 ) on Friday October 31, 2008 @12:25PM (#25586089) Homepage

    Um pick a open and common streaming format and to hell with wasting time writing a client. They click on the episode name and let it stream.

    Come on, this is so easy a webprogramming 101 student can do it.

  • by Toffins ( 1069136 ) on Friday October 31, 2008 @12:32PM (#25586235)
    The reason the BBC gave for why it could make its programs available on iplayer for 7 days only was that they didn't own the copyright on the content of the programs, and a period of 7 days was all they could negotiate from the copyright owners.

    I can see how that would apply especially to any programs the BBC uses which were produced using subcontractors who usually put their copyright notices (not the BBC's) at the end of their shows. However, the BBC puts its own BBC copyright notice at the end of all of its current affairs programs such as "Panorama" and "Newsnight".

    Doesn't that imply the BBC owns the copyright to the programs? If so, why doesn't it release all of them on iplayer for longer than 7 days? Programs like Newsnight and Panorama which have a lot of analysis and detailed investigative journalism can remain of interest even long after they are first broadcast. There is a demand for watching those programs much beyond 7 days. So, why the 7 days limit on these programs?

    • The BBC may own the copyright to the programmes but that doesn't mean they have the right to make them available in any format. A few bars of music or a few seconds of sports coverage in a news or current affairs programme will bring the rights-holding industries and their lawyers into play. It's easier (and cheaper) just to have a uniform 7 day limit rather than pay copyright lawyers to vet the 400 hours per week of iPlayer content.
    • Perhaps the BBC sells the rights to some of their shows to other TV channels and media outlets abroad.

      If this is the case I'm not sure these companies would be so keen to pay for the rights to play the content if the BBC was also giving it away free and without any DRM.

      If the BBC keeps a 7 day limit on all programs, it's simple for people to remember and it also means they may still be able to license it.

      Personally though I hope the media companies end up giving up on DRM.

    • ... So, why the 7 days limit on these programs?

      Because when you've got a hammer in your hand, everything looks like a nail.

      They already go through the "what can be made available for longer" process for radio - quite a few radio programs (including most of the main news and current affairs ones) are available as podcasts. Where there are differences it's usually where e.g. The Now Show has licensed a bit of music as the payoff for a joke, and whoever owns the dibs on that doesn't want it freely available as an MP3. It wouldn't be rocket science to do

    • Re: (Score:1, Informative)

      by Anonymous Coward

      There is a demand for watching those programs much beyond 7 days. So, why the 7 days limit on these programs [sic]?

      It's a condition of the approval granted by the BBC Trust after conducting a (legally mandated) public value test. (Although series stacking is permitted within a limit of 15%.)

      • You explain some of the bureaucratic, edict-from-on-high-driven processes involving the BBC Trust that led to the 7-day limit, but of course it's still a secretive process conducted behind closed doors, with a strong bias - no surprise given the disturbing conflicts of interest of some BBC Trust members - for the interests of rightsholders, commercial confidentiality, and the exclusion of members of the public (I mean what would they know - no experience of commercial broadcasting, unclean, noisy, ask awkwa
  • This is a bogus issue. Just choose a STANDARD FORMAT that is openly documented and unencumbered by patents (such as OGG [wikipedia.org] with Vorbis [wikipedia.org] and Theora [wikipedia.org]). Since this is a non-DRM project, this will work. Then let the application developers make sure their products work right.

    This whole idea of standards is so that data can be produced by any of a wide range of programs, and then accepted by any of a wide range or programs. Instead of targeting their product to a specific player, they need to target it to a specif

  • Must we use Totem? (Score:2, Interesting)

    by Enderandrew ( 866215 )

    Nice first step, but I just don't like using GTK apps if I can help it, because they look out of place. The only GTK app I really make an exception for is Firefox, and thankfully that is getting a QT4 port from Nokia.

    Is there any chance someone could develop a Firefox extension, or a plugin for Kaffeine, Amarok, etc?

  • BBC World Service (Score:4, Informative)

    by photomonkey ( 987563 ) on Friday October 31, 2008 @02:40PM (#25588105)

    Would it be too much to ask to get BBC World Service in something other than WMP/Real format?

    Right now, Vermont Public Radio has a transcoder that takes the Real and rebroadcasts it in streaming MP3, but even after donating to them, I still feel bad that the burden is on them to re-encode the stream.

    I'd transcode the stream myself but, a) don't want to go to the trouble and b) suspect it's against their TOS anyway.

    I'm sure the Beeb poured a ton of money into the Real platform years ago (to the extent that they may still be locked-in), but I'd really love to see such an important service be more accessible.

    • (insert rant about Realplayer here), but it's better-supported by transcoders than some platforms.

      I'd transcode the stream myself but, a) don't want to go to the trouble and b) suspect it's against their TOS anyway

      I'd be surprised if they're that bothered. The BBC World Service is designed to be heard outside the UK - that's why it's made available to pretty much anyone who wants to retransmit it. It's supposed to be the "voice of the UK government" in a "aren't we all nice and democratic and allow public criticism" kind of way.

      I think that it's unlikely that Mark Thompson* is going to fly over to Vermont to stop you r

    • by wrook ( 134116 )

      BBC World Service podcasts are available here:

      http://www.bbc.co.uk/radio/podcasts/directory/station/worldservice/ [bbc.co.uk]

      I looked at a couple of them (including the World News) and they were all MP3.

      I'm not sure if that's what you're looking for, but at least it's a start.

  • http://www.getmiro.com/ [getmiro.com]

    It has almost all the qualities that a broadcaster could want.... except DRM.

    It is open source.
    It runs on Windows, *nix and Macs
    It uses Bitorrent to distribute content
    It use RSS feeds to provide episodes.
    It supports multiple codecs.

    Seems like that would be a pretty simple way to provide content for ALL platforms. It meets almost all needs except instant streaming and DRM.

    And if you must have DRM figure out a way to layer it on top of a working system, rather than re-inventing yet anot

  • the sheer number of options in the open source world actually makes this difficult to accomplish

    That's precisely why open standards and open protocols exist. Unlike the microsoft world, wherein a protocol/standard is tied to a single vendor, you wont be locking your customers whatever you choose. So stop bothering about the number of options available to your customers.

  • DRM-Free? (Score:2, Informative)

    by DrPoodle ( 1079435 )
    We already have that...it's called the iplayer downloader [po-ru.com]...
    • Just masquerade as an iPhone, and you get a nice high-quality .MOV file. You can download it and store it as long as you like, and play it using standard free software.

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Working...