Re: [backstage] Freeview HD Content Management
Mo McRoberts m...@nevali.net wrote at 19:35 on 2010-01-22: On 22-Jan-2010, at 18:55, Steffan Davies wrote: Oh, definitely. I wasn't saying that would be a good implementation, just that it might permit appliance makers to comply without having to reinvent the wheel entirely (which typically leads to square or triangular wheels). But, it fundamentally alters the relationship between (content producers, distributors, broadcasters), standards bodies and manufacturers. Couldn't agree more - the idea is daft and my suggestion was purely a implementation suggestion in the light of that daftery. Quite HD is so intrinsically different from standard DVB-T that it needs to be encumbered in this way is beyond me. S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] Freeview HD Content Management
Ian Stirling backstage...@mauve.plus.com wrote at 17:42 on 2010-01-22: a) ignore the licensing terms of the open source DVB stacks; b) reverse-engineer the decoding tables; c) obtain the tables from the BBC but breach the non-disclosure terms; or d) release a box which doesn't support FVHD There is a third alternative. B) obtain the decoded tables from a third party in a country where this decryption is not illegal. Or use the usual open source DVB stack, read the raw EPG stream into a closed source userspace blob and de-huff it there with licensed tables? The LinuxTv stack appears to be under GPLv2, so no GPLv3 keys with the source worries. S S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] Freeview HD Content Management
Mo McRoberts m...@nevali.net wrote at 18:15 on 2010-01-22: There’s also a secondary concern here, in that the terms under which the blob is distributed do not just pertain to what you do to the blob itself, but what you let the user do to both your device (i.e., no modifications) and to the content which has been received (HDCP-only-outputs, for example). Not only do both of these have cost implications, but restrict innovation in the CE space where it relates to FVHD receivers. It is, as they say, a can of worms. Oh, definitely. I wasn't saying that would be a good implementation, just that it might permit appliance makers to comply without having to reinvent the wheel entirely (which typically leads to square or triangular wheels). S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] [Fwd: [ubuntu-uk] bbc listen again anomaly]
Andy stude.l...@googlemail.com wrote at 17:43 on 2009-05-28: 2009/5/28 Andy stude.l...@googlemail.com: FF claims it know about Real Player as a plugin, however I don't have 'hxplay' or 'realplay' in the system path. Is the BBC player looking for the specific binaries instead of a plugin? Still not sure why the Beeb require on Real Player though. If it helps you can look through the source of the iplayer page, find the .ram url and play it in totem media player. Far from ideal, but it works. And it doesn't require proprietary realplayer. IIRC the mozilla-mplayer package, combined with w32codecs from medibuntu allowed the old Real-based Listen Again stuff to work nicely for me, without having to import the full steaming pile of Realnetworks onto my machine. S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] Make the primary operating system used in state schools free and open source
Matt Barber m...@progressive.org.uk wrote at 13:10 on 2009-02-11: What about all the jobs that people have when they develop software that is paid for and licensed? If the switch to free software were to suddenly happen, would these people find themselves out of work? This isn't a stab at anybody, it's just an observation that I'd like to put in there. And I'm genuinely interested in the response from enthusiasts to the idea. Well, quite a number of people are employed to work on OS and GPL software, both writing enhancements and fixing bugs. Certainly the growth in use of OS doesn't seem to have lead to hordes of unemployed developers. Indeed, most of the developers I know work using OS tools to write commercial software (webapps mostly) that runs on OS platforms and this has been a huge growth area in the last decade. Some are paid to write to write code which is subsequently opened. I'd be much more worried about sales, marketing, licensing and compliance people TBH. If your job is keeping track of licenses to avoid having your organisation beaten up by BSA/FAST and those licenses suddenly become fewer in number (I don't think anyone is suggesting no use of commercial software) then there's a reduction in the amount of work needed. Whether this is repaid by the removal of a bureaucratic brake on Getting Stuff Done* is up for debate. I think it is, but as a Linux/BSD guy I would, I suppose. *When I used to work in Windows/Mac shops, keeping track of licenses was a huge time-sink. Long hours spent reciting long alphanumerics back and forth to call centres are weren't really what I'd been hired for. S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] If you had a ton of content to freely distribute
Dave Crossland d...@lab6.com wrote at 16:50 on 2009-01-20: 2009/1/20 Ian Forrester ian.forres...@bbc.co.uk: The reason why we would like to Tar the files together is because of things like subtitles, artwork, cuts of music, other metadata pieces, etc. We're not just talking a collection of video files. What does Tar add to the ability to organise files in a set into a hierarchy, that a directory tree in the Torrent doesn't? Except stopping people from downloading only the files that they want from that set? It limits the number of file descriptors the torrent client has to deal with. I know this has been a problem for some torrent clients in the past but I'm not sure if it still afflicts current clients. It'll certainly end up being a solved problem as domestic connectiosn gets faster and torrent sizes grow, but I suspect this problem brought about the common (if really, really irritating) habit of packaging torrents in archive formats. S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] erik huggers on open standards
Tim Dobson [EMAIL PROTECTED] wrote at 17:28 on 2008-08-13: Simon Thompson wrote: Tim Dobson wrote: that's the A-View, the AW-300 and the AW-150 subnotebooks All of which use Aday super486 CPUs. So these will be x86 compatible Eek. My lack of knowledge relating to CPU architecture and x86 compatibility stuff seems to have let me down. Though looking at the system requirements list, Adobe suggest a minimum of a PII-450[1] while the Aware machines are 486-compatibles at 300MHz max[2]. Out of interest, does anyone know which version of the x86 instruction set the Adobe flash plugin is compiled for? If it uses MMX, for instance, a 486 won't cut it no matter how quick it is. S [1] http://www.adobe.com/products/flashplayer/productinfo/systemreqs/ [2] http://en.wikipedia.org/wiki/Aware_Electronics - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] Google launches second life killer?
Peter Bowyer [EMAIL PROTECTED] wrote at 16:47 on 2008-07-10: 2008/7/10 Ian Forrester [EMAIL PROTECTED]: http://www.lively.com/html/landing.html I got to say this came out of the blue for me... It's Windows-only. Not that I think that's inherently bad (I'm sure someone will come along shortly and say it is, though), but it does mean I can't use it :-( It fails at an early stage in WINE too, in case anyone was thinking of trying that. S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] My Very Basic Prototype - News Algorithmic Sorter
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote at 08:22 on 2008-06-24: BBC News Algorithmic Sorter an attempt to try and work out what the British public are finding important. The main BBC News website offers a glimpse of what’s popular, but as with all things that’s limited to the audience of the BBC. While this gives a somewhat true to form view of what people are interested in, I wanted to expand it, and thus came up with the BNAS site. The main site isn’t that impressive as the main focus was on the backend. The script uses several external APIs from blogging communities, search engines and social networking sites to work out what people are talking about. Then using the last 50 Data from the BBC it compiles a list in order of the interest the British public has on the subject. Location: http://mugamail.com/bbc/ A lovely piece of work - straight into the bookmarks. S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] proxy support in BBC iplayer download client
Graham Donaldson [EMAIL PROTECTED] wrote at 10:47 on 2008-06-06: Matt Barber wrote: Can't you send all traffic through port 80/443 anyway, using the proxy transparently to filter traffic. You could then allow the Kontiki traffic in the proxy ruleset? The proxies don't operate in transparent mode. I'm aware of some cache appliances for schools that do, like Bloxx for example, but most don't. [snip] Even so it's less than ideal - proxy use in school's and corporate environments is defacto, and yet so many modern apps seem to be completely unaware of them. It's been awhile since I last played with transparent proxying, but IIRC the proxy itself doesn't have to know that it's being given intercepted traffic rather than being connected to directly by clients and the router configuration needed to set up the redirection of 80 and 443 to the proxy is only a couple of lines. This being the case it's probably easier to fix your network configs than every application a user might wish to run. That said, the lack of configuration available to Kontiki users is a pain in the neck. I know several people who've uninstalled it because its non-adjustable upload was crippling their asymmetric cable/ADSL connections by delaying ACKs. S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] proxy support in BBC iplayer download client
Graham Donaldson [EMAIL PROTECTED] wrote at 11:37 on 2008-06-06: That's not my impression last time I looked at transparent proxying. The guides for setting up transparent proxies I have seen involve using SQUID in a reverse proxy mode, and then using say iptables to redirect the traffic from 80 to our proxy port. Besides, this is all moot, as you can't transparent proxy HTTPS. I've just tested it out - for recent versions all you need to do is add the transparent keyword to squid's config. Other than that it's just a matter of redirecting the packets using whatever firewall/router you have in place. You're right about HTTPS, of course, though a filtering proxy loses a lot of advantages with HTTPS, since it can only go by hostname rather than examining content, at which point you could probably achieve a similar result at the IP or DNS level. Once again, school's use cache appliances supported by a particular vendor. If their product doesn't support transparent proxying, then it doesn't support transparent proxying. Fair, though that sort of inflexibility is one reason why I've come to dislike the appliance model of computing. Probably pretty much unavoidable in a school environment though, I suppose. I wouldn't call it fixing our config, I'd call it fixing someone elses's mistake, because application writers, who have large audiences using proxy servers, can't be bothered, or are too inept to support them. Sorry - I didn't mean to imply that your config was broken, just that it's probably easier to change a/some central points on your network(s) rather than lobbying all of the many application vendors you might encounter to add the feature to their apps, desirable though it obviously is. A friend of mine came up with a nice approach to this sort of problem a while back which involved using an image-aware packet sniffer* at the network gateway and displaying the results on a large plasma screen in reception. Probably not appropriate in a school environment though ;-) * http://www.ex-parrot.com/~chris/driftnet/ - fun! S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] proxy support in BBC iplayer download client
Graham Donaldson [EMAIL PROTECTED] wrote at 15:44 on 2008-06-06: Steffan Davies wrote: Graham Donaldson [EMAIL PROTECTED] wrote at 11:37 on 2008-06-06: I've just tested it out - for recent versions all you need to do is add the transparent keyword to squid's config. Other than that it's just a matter of redirecting the packets using whatever firewall/router you have in place. It would require the developer to re-engineer their cache solution. Seems excessive. To work with every current or future application whose developer isn't able or willing to implement proxy support? Seems quite a nice tick-list feature to me, though I suppose it depends how technical an audience you're marketing to. Engineer a whole new way of doing filtering based on DNS? You'll forgive me if I pass on that. You have (or your vendor has) already engineered one based on URLs - the DNS case is actually probably simpler. The ongoing difficulty lies in getting your list of things-to-block and keeping it up to date, which you've already done. Again not a bad additional feature, it seems to me. Fair, though that sort of inflexibility is one reason why I've come to dislike the appliance model of computing. Probably pretty much unavoidable in a school environment though, I suppose. It's pretty much unavoidable in any environment that is interested in running properly managed, stable IT services. Changing the entire way you proxy and filter an environment because some application developers are lazy/inept is poor IT management policy. I think we may be talking at cross purposes here, unless you mean to say that it's impossible to run properly managed, stable services without buying lots of pre-configured boxes. Some of the most irritating problems I've worked on as a sysadmin have been with such devices when their design assumptions don't quite match reality. (Much, in fact, as the Kontiki platform's design assumptions don't match a school/corporate network topology). Your second point I absolutely agree with in principle but in practice as you've mentioned lots of apps will break in a proxied environment. I don't expect that situation to improve much overnight, for exactly the reasons of developer laziness/ineptitude you cite. Problem is, if you don't make a fuss, developers get away scott free, whilst administrators have to work on more hacks for their networks. More hacks almost always equals wasted time, money and less stability. iPlayer must have a significant audience in schools, the defacto standard for access is HTTP proxy; not direct, and not transparent proxy. Again, I quite agree. In the case of the iPlayer it'd certainly be nice to see proxy support, though I'd imagine fixing some of the problems it causes for typical NATed home users will be more of a priority. A friend of mine came up with a nice approach to this sort of problem a while back which involved using an image-aware packet sniffer* at the network gateway and displaying the results on a large plasma screen in reception. Probably not appropriate in a school environment though ;-) Given some of the stuff the kids search for, let's say it would interesting. The mists are clearing, and dimly I see a Daily Mail front page forming... S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
