[Bradford] BBC's plan to encrypt HD content management

Brian bradlug at techchico.org.uk
Wed Jun 29 11:46:55 UTC 2011


Hi Steve,

Thanks for that very clear explanation. Coming, initially, from a radio & TV 
background I knew some of those things, though some things are now  clearer. 
Primarily, it wasn't clear to me exactly what the BBC might do. I can now see, 
from what you have detailed, what problems might arise.

So far the BBC have altered the frequency of the multiplex, the fec and, also, 
they have switched to DVB-S2. Anyway, I made all those changes to the transport 
data and rescanned. No results initially until I did a rescan on just that 
transport. Now  BBC HD, BBC1 HD, C4 HD & ITV1 HD are all working.
I've locked out updates to  MythTV so I'm hoping everything will stay on track 
until I update all my computers next year, probably to one of the Ubuntu 12.04 
derivatives that doesn't have Unity.

Brian





________________________________
From: Steve Kerr <steve at cullingworth.net>
To: BradfordLinuxUserGroup <bradford at mailman.lug.org.uk>
Sent: Wed, 29 June, 2011 1:15:01
Subject: Re: [Bradford] BBC's plan to encrypt HD content management

Hi Brian, 

For DVB satellite and cable networks a pre-configured 'home frequency' is 
usually tuned by the receiver (STB, PC etc.). From the DVB-SI found on this 
frequency, specifically the NIT (Network Information Table),  the receiver can 
determine the frequency of all all the other multiplexes in the network. 
Although the same principle could work on terrestrial networks it generally less 
reliable for a number of reasons. As such it is common with DVB-T (terrestrial) 
networks for receivers to do a frequency scan to find all multiplexes on the 
network. For each multiplex that the receiver finds it scans the SDT (Service 
Descriptor Table - part of the DVB-SI) to find what services are available on 
the multiplex. The services found are all grouped together and duplicates 
removed to produce a service list. The problem with this approach is that if a 
multiplex moves in frequency then the services on it disappear from the 
receiver's perspective. A rescan will find them again. This is what you are 
describing.

In order to 'hide' services, broadcasters can do non-standard things like miss 
services out of the SDT or not even broadcast an SDT, instead broadcasting some 
private data that only 'authorised' receivers can decode. Utlimately, if the 
content itself is not encrypted/scrambled, then a suffciently flexible receiver 
can tune to it - it's just how much hassle it is to do it and how much hassle it 
is when things change.

As a matter of interest, on cable and satellite networks that use a NIT, a 
version change of the NIT causes the receiver to re-read the information 
contained in the NIT, so picking up any changes in frequency. Obviously if the 
currently tuned frequency is moved then the NIT update won't be spotted, but the 
user will usually tune to a different service on a multiplex that hasn't moved 
and so pick up the new NIT as it is broadcast on all multiplexes. Alternatively, 
there are standard ways of signalling a change in frequency prior to the change 
happening but these are not commonly used.

Hopefully this is not too baffling - if you've got any more questions on this I 
do plan to come to the meeting tomorrow night.

.Steve



On 28 June 2011 12:06, Brian <bradlug at techchico.org.uk> wrote:

So, Steve, if understand you correctly, the frequency data would not be 
available when a scan takes place? 

>Presumably, however, it would be possible to add such information manually the 
>the database in, for example, MythTV. I am doing this now because BBC HD has 
>changed some information such as 'symbol rate' etc. Now I have to do the rest by 
>hand or rescan.
>One thing I am happy about though is, for the first time, I have been able tot 
>get HD working properly on all the HD channels - bar the BBC which I haven't 
>been able to try yet. I am dreading the introduction of Wayland to Ubuntu which 
>will probably muck everything up.
>
>The EPG is not so important to MythTV because the data can be gleaned from 
>elsewhere, so that is not any real problem for MythTV. I don't publish my 
>grabber  programs because I suspect that certain websites would be deluged with 
>downloads, for EPG purposes, and those same web sites might  block or obfuscate 
>downloads. Having said that the only one I use to any extent is one for 'Travel' 
>which uses their web site so they might not object.
>
>Brian
>
>
>
>
________________________________
 From: Steve Kerr <steve at cullingworth.net>
>To: BradfordLinuxUserGroup <bradford at mailman.lug.org.uk>
>Sent: Tue, 28 June, 2011 1:21:07
>Subject: Re: [Bradford] BBC's plan to encrypt HD content management
>
>
>To quote the article:  "...it is requesting that it be allowed to encrypt the 
>data associated with  TV listings without which set-top boxes are not able to 
>decode the TV  content". 
>
>
>What they are describing there is the encryption (or obfuscation) of the DVB-SI 
>and (possibly) MPEG-PSI. The STB (or other client) uses these data streams to 
>find the content. The SI (System Information) describes where the service (what 
>mere humans call a 'channel' - e.g. BBC1) can be found i.e. what frequency and 
>other parameters to use to tune to the digital multiplex. The PSI (Program 
>Specific Information) within each multiplex describes how to find the component 
>parts of the service within that multiplex, i.e. the Packet IDs for the video, 
>audio and other elementary streams.
>
>The 'listings', or EPG data, is held in the Event Information Table (EIT) which 
>is referenced as a component of the service in the PSI. Some service providers 
>encrypt the EIT data to prevent it being used by unauthorised STBs but this 
>doesn't prevent the STBs from receiving and decoding the services.
>
>Freesat did a similar thing to prevent any standard DVB satellite receiver from 
>picking up the Freesat services. In this case I think they just used a propriety 
>means to describe where the services are (i.e. non-standard SI & PSI). The 
>Freesat services could still be received by my media centre (non-Linux at the 
>time I'm afraid) by doing a scan. The problem came when services were moved - 
>they just disappeared from my media centre's perspective and I had to perform a 
>manual rescan. 
>
>
>.Steve
>
>
>
>On 27 June 2011 20:23, Brian <bradlug at techchico.org.uk> wrote:
>
>The BBC plan to introduce encryption in regard to their HD channels. It  will 
>mean that existing Linux boxes  won't function anymore and that, of  course, 
>will include MythTV *(see below).
>>
>>More information:-
>>http://news.bbc.co.uk/1/hi/technology/8259154.stm
>> 
>>From which comes:-
>>"Critics of the BBC's request say that open source licenses are  incompatible 
>>with the regulations because DRM locks down software so  that it cannot be 
>>altered by the user. "
>>
>>Ofcom:-
>>http://tinyurl.com/66umlcx
>> 
>>
>>There is a PDF on that page and in it is an email address which can be used to 
>>respond to the BBC's plans via Ofcom.
>>
>>Put simply, as I understand it, the BBC can't encrypt the video but can encrypt 
>>the EPG etc. 
>>
>>*If  this is all they intend to do then, as far as MythTV is concerned, it  
>>won't be much of a problem as, presumably, listings can be obtained from  the 
>>Net. I have written 'grabbers' for channels which aren't in the the  standard 
>>EPG so the BBC should not prove any more difficult. However,  with standard 
>>Linux set-top boxes this may prove a problem.
>>
>>Brian
>>
>>_______________________________________________
>>Bradford mailing list
>>Bradford at mailman.lug.org.uk
>>https://mailman.lug.org.uk/mailman/listinfo/bradford
>>
>>
>
>_______________________________________________
>Bradford mailing list
>Bradford at mailman.lug.org.uk
>https://mailman.lug.org.uk/mailman/listinfo/bradford
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/bradford/attachments/20110629/8b52e14e/attachment.htm>


More information about the Bradford mailing list