Yeah, but maybe Ubuntu patched back in the RTMP SWF verification into flvstreamer? Otherwise, how else could get_iplayer on Ubuntu be getting access to the 'flashvhigh' iPlayer content?
BBC is required to be transparent and even-handed The BBC and BBCW executives are supposedly at arms length, yes. When it comes to bidding for production and other services - BBC subsidiaries are not meant to be preferred.
However, when it comes to licensing BBC content for commercial exploitation, my impression was that BBC Worldwide gets first dibs.
Finally, BBC Worldwide is also subject to the public interest goals of the BBC charter.
Because there are computers besides PCs. In addition to general purpose ones, I might want to start a build business building internet enabled set-top boxes.
I might choose to make it free software, for some reason. In which case the BBCs decision to build on flash is a problem.
Or I might be happy to use Flash. But if Adobe don't support the STB architecture I want to use, then I need to pay Adobe to do a port. Also, Adobe could charge me a royalty fee (it's very hard to find definitive information on how Adobe licence Flash to embedded systems vendors).
Basically, choosing to build the next generation of TV on top of a proprietary, single vendor technology is anti-competitive and not in the public interest. My understanding is that the BBC is not usually allowed to do such things, when it comes to broadcast technologies at least.
I can access the 640x360 stuff with flvstreamer installed, but not the 832x468 flashvhigh stuff. That needs the pseudo-DRM bits from rtmpdump methinks. You sure flashvhigh works?
The BBC is using various bits of free software as part of the iPlayer backend. I.e. they're happy to use code from free software developers while at the same time shutting some of those developers out.
What I wonder is whether there's any kind of way free software licences could require equal access to public services, when organisations use free software licences. A "you use our code, you don't discriminate against us" kind of clause. I've no idea if this could be worded in a legally meaningful way though... I'd definitely upgrade my code to such a licence.
(Before any says "not free", think again - free software licences do exist that restrict individual usage rights for the greater good, e.g. AGPL).
What if the content producers that really demanding DRM are pretty much all subsidiaries of the BBC? E.g. BBC Worldwide? BBC executives have pretty much said that BBCW is a major motivator for DRM (see my other post below).
Yes, BBCW exist to provide value to the public by making money from non-UK-broadcast activities. Yes, the BBCW and BBC executive are supposed to be separate and at arms length - however the BBC executive do have a direct financial interest in the BBCW, as BBCW activities generate revenue for the BBC. BBC executives have called that revenue "significant" (see blog I linked to).
Are you sure there is no difference between the BBC saying "External rights-holders require us to implement DRM" and "We're implementing DRM for BBCW"?
Yeah, flvstreamer is a fork of rtmpdump with the SWF verification stuff removed. My understanding is that flvstreamer shouldn't be sufficient - unless someone patched that to add back in the DRM-support bits?
Are these get_iplayer and flvstreamer packages shipped in Canonical hosted repositories? What patches are applied in the packages?
interesting. does "strace -e open -f get_iplayer --get 859 |& grep rtmp" say anything? has it been built with patches to enable SWF verification support in some way?
It definitely appears broken on Fedora, where get_iplayer does not support SWF verification enabled RTMP streams.
How does applying DRM to UK residents help? The bulk of non-residents can't access iPlayer anyway (geo-IP) and so if they're watching BBC material online they're not using the DRMed BBC stuff anyway.
The BBC make available low-res streams. Totem supports these. My understanding is the higher-res streams now require rtmpdump installed to access, which is a tool that's hard for distros to ship due to anti-circumvention laws. E.g. Adobe have tried to use the DMCA to take down rtmpdump.
I.e. my understanding is that the BBCs' move only frustrates those who must shy away from all legal risk. It doesn't really stop anyone - DRM never does.
I believe, in addition to the usual blind-spot media execs seem to have about DRM, that there's an element of getting control over the client viewing platform. E.g. the BBC are developing a set-top-box for internet TV (Project Canvas).
Also, bear in mind that when the BBC says "Rights holders require us to implement DRM" that the BBC potentially is being obfuscatory, because the rights holders it's talking about may in fact be companies the BBC owns in part or in full. I.e. the BBC might be trying to hide "We want DRM". E.g. see this post from Anthony Rose giving BBC Worldwide as the prime example of the DRM-requiring rights holders.
Finally, this is from a comment I left on the linuxcentre blog:
BBC Trust is running a consultation on the BBC strategic review. One of the key questions is regarding platform neutrality. It is very important that people fill in that survey and let the Trust know how important open ly specified access is. In particular the following is important for platform neutrality:
* BBC Ondemand should *not* be built on proprietary, single-vendor technologies, such as Adobe Flash. * BBC Ondemand should be built on multi-vendor, open, non-discriminatory standards, such as HTML5 video. * The BBC should *not* be in the business of dictating which ondemand client implementations may access iPlayer and which may not.
These things are important both for free software, but also more generally for a healthy market. It is not in the public interest for the BBC to become the king-maker of client device implementations. Please take the time to let the Trust know your views on platform neutrality and how the current situation is bad for the greater public interest.
I've talked about this with Chinese people - outside China, and they gave me the strong impression of acceptance too. Further, it wasn't just that they want stability as such. That's not quite right - they want progress.
China is of course a country with wide-spread famine in living memory, abject poverty too. The impression given to me is that democracy simply is not a priority, not even amongst young Chinese who studied in the west. Continuing to elevate China to prosperity is what they view as the number priority. Essentially, people seem more or less happy with the government at the moment, the economic progress at least. They don't see it worth risking this with political upheaval.
That's the impression I got from a very small sample anyway.
No, the codec and the delivery technology are 2 different, orthogonal things. Regardless of the codec situation, there is an opportunity to at least "free" the delivery tech used on the web, by making HTML5 video widely available.
Decoupling different parts of the problem from each other allows it to be attacked in parallel, and it allows progress to be made in one area even when there is little progress in another area. Conversely, shackling together sub-problems just gives you a much larger problem, and makes it much more likely you'll fail as you have to overcome all the problems at once.
HTML5 even with H.264, is much much better than the situation today where Flash is used to deliver video. Essentially there are *2* independent dimensions to this battle:
A) The codec B) The delivery technology
With Flash, you've got unfree, proprietary technology for both dimensions. With HTML5 you fix at least one of these dimensions, regardless of the codec.
These are mostly separate battles and it's a huge, *huge*, **huge** mistake for any free software and/or open web advocates to delay or hinder HTML5 implementation because of the codecs. And that includes nobbling your HTML5 implementation by not making it easy to support H.264 (e.g. not using an underlying video playing system that at least supports codec plugins). All this does is perpetuate Flash, and hence further entrench H.264 - which is often used as the codec for flash-delivered video.
Get HTML5 out now, and make sure it can avail of as many, if not all, of the video codecs your users' systems support. Any delay on principles relating to codecs is a massive own goal.
As a matter of fact, the very first port of Linux was to DEC AXP / Alpha, and a 64bit port. Jon 'Maddog' Hall apparently arranged for a machine to be given to Linus. This would have been in the earlier part of the 90s.
Over what time span did the autism diagnosis rates jump? And a cite?
Diagnoses exist today for disorders which weren't even recognised less than 30 years ago, e.g. Aspergers, high-function autism, etc. 30/20 years ago autism would only be diagnosed for individuals who were having fairly severe problems interacting with the rest of the world, today we recognise there are individuals who are pretty functional but not quite as capable socially, etc.
I.e. the reason the rates jumped is because the definition of the condition has expanded to cover a wider range of symptoms... You can't directly compare autism diagnosis rates from a significant number of years ago with rates today cause they're not measuring the same thing anymore. (Is my understanding of what the likely explanation is).
Slashdot Mirror
Yeah, but maybe Ubuntu patched back in the RTMP SWF verification into flvstreamer? Otherwise, how else could get_iplayer on Ubuntu be getting access to the 'flashvhigh' iPlayer content?
BBC is required to be transparent and even-handed The BBC and BBCW executives are supposedly at arms length, yes. When it comes to bidding for production and other services - BBC subsidiaries are not meant to be preferred.
However, when it comes to licensing BBC content for commercial exploitation, my impression was that BBC Worldwide gets first dibs.
Finally, BBC Worldwide is also subject to the public interest goals of the BBC charter.
Because there are computers besides PCs. In addition to general purpose ones, I might want to start a build business building internet enabled set-top boxes.
I might choose to make it free software, for some reason. In which case the BBCs decision to build on flash is a problem.
Or I might be happy to use Flash. But if Adobe don't support the STB architecture I want to use, then I need to pay Adobe to do a port. Also, Adobe could charge me a royalty fee (it's very hard to find definitive information on how Adobe licence Flash to embedded systems vendors).
Basically, choosing to build the next generation of TV on top of a proprietary, single vendor technology is anti-competitive and not in the public interest. My understanding is that the BBC is not usually allowed to do such things, when it comes to broadcast technologies at least.
How can that be true, when get_iplayer and XBMC already were subject to the geo-IP checks, carried out by BBC.
DRM does not enforce geo-IP checks. Please explain this extraordinary theory.
I can access the 640x360 stuff with flvstreamer installed, but not the 832x468 flashvhigh stuff. That needs the pseudo-DRM bits from rtmpdump methinks. You sure flashvhigh works?
Actually, we do have "guns".
The BBC is using various bits of free software as part of the iPlayer backend. I.e. they're happy to use code from free software developers while at the same time shutting some of those developers out.
What I wonder is whether there's any kind of way free software licences could require equal access to public services, when organisations use free software licences. A "you use our code, you don't discriminate against us" kind of clause. I've no idea if this could be worded in a legally meaningful way though... I'd definitely upgrade my code to such a licence.
(Before any says "not free", think again - free software licences do exist that restrict individual usage rights for the greater good, e.g. AGPL).
What if the content producers that really demanding DRM are pretty much all subsidiaries of the BBC? E.g. BBC Worldwide? BBC executives have pretty much said that BBCW is a major motivator for DRM (see my other post below).
Yes, BBCW exist to provide value to the public by making money from non-UK-broadcast activities. Yes, the BBCW and BBC executive are supposed to be separate and at arms length - however the BBC executive do have a direct financial interest in the BBCW, as BBCW activities generate revenue for the BBC. BBC executives have called that revenue "significant" (see blog I linked to).
Are you sure there is no difference between the BBC saying "External rights-holders require us to implement DRM" and "We're implementing DRM for BBCW"?
Yeah, flvstreamer is a fork of rtmpdump with the SWF verification stuff removed. My understanding is that flvstreamer shouldn't be sufficient - unless someone patched that to add back in the DRM-support bits?
Are these get_iplayer and flvstreamer packages shipped in Canonical hosted repositories? What patches are applied in the packages?
interesting. does "strace -e open -f get_iplayer --get 859 |& grep rtmp" say anything? has it been built with patches to enable SWF verification support in some way?
It definitely appears broken on Fedora, where get_iplayer does not support SWF verification enabled RTMP streams.
No one is arguing that the BBC not apply their geo-IP checks, as they were doing with XBMC and get_iplayer clients all along.
How does applying DRM to UK residents help? The bulk of non-residents can't access iPlayer anyway (geo-IP) and so if they're watching BBC material online they're not using the DRMed BBC stuff anyway.
As per the other /. story on H.264 v Ogg Theora, I'm of the opinion that the codec issue should not be conflated with the delivery platform issue.
Also, note "such as HTML5" does not exclude any other specifications, including any the BBC might openly specify itself.
The high-level usage restrictions the BBC had as policy have not changed.
The BBC *have* changed the format of the service. It now uses SWF verification. If you don't believe me, believe the BBC.
Oh, rtmpdump implements "SWF verification", a silly little Flash DRM support scheme, which is what the BBC have enabled on iPlayer recently.
Do you have rtmpdump installed by any chance?
The BBC make available low-res streams. Totem supports these. My understanding is the higher-res streams now require rtmpdump installed to access, which is a tool that's hard for distros to ship due to anti-circumvention laws. E.g. Adobe have tried to use the DMCA to take down rtmpdump.
I.e. my understanding is that the BBCs' move only frustrates those who must shy away from all legal risk. It doesn't really stop anyone - DRM never does.
I believe, in addition to the usual blind-spot media execs seem to have about DRM, that there's an element of getting control over the client viewing platform. E.g. the BBC are developing a set-top-box for internet TV (Project Canvas).
There's a long discussion on this on a BBC blog.
Also, bear in mind that when the BBC says "Rights holders require us to implement DRM" that the BBC potentially is being obfuscatory, because the rights holders it's talking about may in fact be companies the BBC owns in part or in full. I.e. the BBC might be trying to hide "We want DRM". E.g. see this post from Anthony Rose giving BBC Worldwide as the prime example of the DRM-requiring rights holders.
Finally, this is from a comment I left on the linuxcentre blog:
BBC Trust is running a consultation on the BBC strategic review. One of the key questions is regarding platform neutrality. It is very important that people fill in that survey and let the Trust know how important open ly specified access is. In particular the following is important for platform neutrality:
* BBC Ondemand should *not* be built on proprietary, single-vendor technologies, such as Adobe Flash.
* BBC Ondemand should be built on multi-vendor, open, non-discriminatory standards, such as HTML5 video.
* The BBC should *not* be in the business of dictating which ondemand client implementations may access iPlayer and which may not.
These things are important both for free software, but also more generally for a healthy market. It is not in the public interest for the BBC to become the king-maker of client device implementations. Please take the time to let the Trust know your views on platform neutrality and how the current situation is bad for the greater public interest.
With HTML5 you fix at least one of these dimensions, regardless of the codec
Should really be:
With HTML5 you fix at least one of these dimensions, and you make it easier to tackle problems in the other.
I've talked about this with Chinese people - outside China, and they gave me the strong impression of acceptance too. Further, it wasn't just that they want stability as such. That's not quite right - they want progress.
China is of course a country with wide-spread famine in living memory, abject poverty too. The impression given to me is that democracy simply is not a priority, not even amongst young Chinese who studied in the west. Continuing to elevate China to prosperity is what they view as the number priority. Essentially, people seem more or less happy with the government at the moment, the economic progress at least. They don't see it worth risking this with political upheaval.
That's the impression I got from a very small sample anyway.
No, the codec and the delivery technology are 2 different, orthogonal things. Regardless of the codec situation, there is an opportunity to at least "free" the delivery tech used on the web, by making HTML5 video widely available.
Decoupling different parts of the problem from each other allows it to be attacked in parallel, and it allows progress to be made in one area even when there is little progress in another area. Conversely, shackling together sub-problems just gives you a much larger problem, and makes it much more likely you'll fail as you have to overcome all the problems at once.
See my other post too.
+1 to this.
HTML5 even with H.264, is much much better than the situation today where Flash is used to deliver video. Essentially there are *2* independent dimensions to this battle:
A) The codec
B) The delivery technology
With Flash, you've got unfree, proprietary technology for both dimensions. With HTML5 you fix at least one of these dimensions, regardless of the codec.
These are mostly separate battles and it's a huge, *huge*, **huge** mistake for any free software and/or open web advocates to delay or hinder HTML5 implementation because of the codecs. And that includes nobbling your HTML5 implementation by not making it easy to support H.264 (e.g. not using an underlying video playing system that at least supports codec plugins). All this does is perpetuate Flash, and hence further entrench H.264 - which is often used as the codec for flash-delivered video.
Get HTML5 out now, and make sure it can avail of as many, if not all, of the video codecs your users' systems support. Any delay on principles relating to codecs is a massive own goal.
Nice Intel glasses you've got there... ;)
As a matter of fact, the very first port of Linux was to DEC AXP / Alpha, and a 64bit port. Jon 'Maddog' Hall apparently arranged for a machine to be given to Linus. This would have been in the earlier part of the 90s.
I think you've missed the point. Sun still made security patches generally available, Oracle have made those $$-only as well now.
Over what time span did the autism diagnosis rates jump? And a cite?
Diagnoses exist today for disorders which weren't even recognised less than 30 years ago, e.g. Aspergers, high-function autism, etc. 30/20 years ago autism would only be diagnosed for individuals who were having fairly severe problems interacting with the rest of the world, today we recognise there are individuals who are pretty functional but not quite as capable socially, etc.
I.e. the reason the rates jumped is because the definition of the condition has expanded to cover a wider range of symptoms... You can't directly compare autism diagnosis rates from a significant number of years ago with rates today cause they're not measuring the same thing anymore. (Is my understanding of what the likely explanation is).