Re: [backstage] iPlayer in Wii

2008-04-12 Thread Brian Butterworth
On 12/04/2008, Michael <[EMAIL PROTECTED]> wrote:
>
> On Saturday 12 April 2008 05:57:49 Brian Butterworth wrote:
> > If it were all doing using HTTP it would be easily cached, of course, as
> > you can do this with a proxy server, either a configured-in one as used
> on
> > corporate and educational networks, or as a transparent proxy.
>
> Ignores the fact that most caches will not cache objects over a certain
> size.
> (The maximum usually based on average object size, which is dominated by
> small images and HTML). Also it depends on the purpose the cache is there
> for - speed or bandwidth savings, and even then you still need a maximum,
> it's
> just where you set it which will vary.


Every proxy server I have set-up allows you to configure this!  There is no
reason whatsoever that large files cannot be cached, and even
part-retrieved.

If this is really a problem, then you could set up a server for each ISP
with the files copied on their network with the Iplayer software being
redirected to the fastest file when available.

So, if you watch a programme on a BT (Phorm! boo, hiss) ISP line, you get
the stream from iplayer.btinternet.com, on talktalk from
iplayer.talktalk.com etc.

If we are talking of saving the ISPs the billions of pounds they claim it
cannot be beyond the wit of us programmes can it?


There are algorithms that will take into account object size and popularity
> (combination of LFU & GDS approaches), but they're still mainly targetted
> at
> object size distributions below the 90-95th percentile.
>
> You can use whitelisting, but the maintainence overhead of such a
> whitelist
> can become quite spectacular, and can depend on the purpose behind
> caching in their network ((peceived) speed saving or bandwidth saving[1]).
> Thus, whitelisting or changing the maximum object size can massively
> impacts the effectiveness of the cache infrastructure as a whole.
>
>   [1] These two do not always correlate, since one is based on
> percentiles,
>the other is absolute figures.
>
> (I worked for the best part 5 years looking at this sort of stuff in great
> detail in both theoretical and (a wide variety of) operational
> environments,
> so I'm summarising :-)
>
> Also, none of this is any use for streaming over RTMP. (and HTTP streaming
> has major issues, not least the fact that you can't index sensibly by time
> without impacting (or working around) patents)
>
> NB. I'm all in favour of making websites cacheable where
> possible/reasonable
> since it's a really, really, good idea, but it's just worth remembering
> we're
> looking at outlying values regarding a non-HTTP protocol.
>
>
> Michael.
> -
> 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/
>



-- 
Please email me back if you need any more help.

Brian Butterworth
http://www.ukfree.tv


Re: [backstage] Is Freesat going to be HD only?

2008-04-12 Thread Brian Butterworth
On 13/04/2008, James Cridland <[EMAIL PROTECTED]> wrote:
>
> Further to all the discussion in this thread about HD, it would occur to
> me that what would be really cool is to see an 'Also in HD' overlay on an SD
> channel when the programme is being simulcast in HD. Hitting that colour
> (hey, use blue) and it'll pop over to the BBC HD channel. Neat.


This would be acceptable, but it would be annoying if the same thing did not
happen automatically when using a PVR.  IMHO.


I don't think Sky allow you to switch TV channels using MHEG, which is a
> shame, so I guess I'll never get to see that on my box...


Hate to be picky, but Sky use OpenTV, not MHEG.


J
>



-- 
Please email me back if you need any more help.

Brian Butterworth
http://www.ukfree.tv


Re: [backstage] 502 error

2008-04-12 Thread James Cridland
On Thu, Apr 10, 2008 at 9:24 AM, Andrew Bowden <[EMAIL PROTECTED]>
wrote:

> >   Hi guys,
> >   does anyone else get a 502 error when trying to post to Justin
> Web's
> > blog:
> >
> http://www.bbc.co.uk/blogs/thereporters/justinwebb/2008/04/letting_it_al
> l_out.html#commentsanchor
>
> There's a known issue with the BBC blog comments where this
> unfortunately happens sometimes.
>
> There's more about it here - including what is being done to solve the
> problem
> http://www.bbc.co.uk/blogs/bbcinternet/2008/02/leaving_comments_on_bbc_b
> logs.html
>

Without breaking too many confidences, as a man who posts to BBC blogs
occasionally, I saw an exciting looking email recently with details in the
next few weeks of a short period of "don't post anything while we work on
things", after which we'll see a new commenting system.

So, that's good.

j


Re: [backstage] Is Freesat going to be HD only?

2008-04-12 Thread James Cridland
Further to all the discussion in this thread about HD, it would occur to me
that what would be really cool is to see an 'Also in HD' overlay on an SD
channel when the programme is being simulcast in HD. Hitting that colour
(hey, use blue) and it'll pop over to the BBC HD channel. Neat.

I don't think Sky allow you to switch TV channels using MHEG, which is a
shame, so I guess I'll never get to see that on my box...

J


Re: [backstage] DAB rollout...

2008-04-12 Thread James Cridland
On Wed, Apr 9, 2008 at 3:47 AM, Christopher Woods <[EMAIL PROTECTED]>
wrote:

Not trying to 'call you out' or anything, but I note in a January article on
> Grauniad (http://www.guardian.co.uk/media/2008/jan/23/digitaltvradio.radio)
> that,
>
> *The number of digital radios is up nearly 50% on the 4.4m sold by the
> fourth quarter of 2006.*
>
> So which figure is the correct one for 2006 sales - 4.4m or 5.5m? (just
> curious). If I'm missing something, please point it out to me.
>

Just as I hoped that the "1 set sold" figure was clearly rubbish, so my
figures weren't researched. You're entirely correct to question them. Had I
bothered to research them, then my answer would have quoted the DRDB's
figures from a press release on 22 January 2008:

*More than 550,000 DAB radios were sold in December alone, up 22% on
December 2006. Best sellers were portable kitchen radios, MP3/DAB personals,
DAB hi-fi systems and, with a particularly strong result, DAB clock radios.
At one point in December, John Lewis reported selling six DAB digital radios
a minute (compared to five iPods a minute).  The DRDB (Digital Radio
Development Bureau) says figures from GfK put cumulative sales of DAB sets
at 6.45 million at the end of 2007, up from 4.4 million in 2006. This is in
line with the DRDB's forecast figure of two million set sales in 2007.*

So, there you go... perhaps the point is rather better, with a two million
jump.

Hazlitt's comments back in February were interesting too...
>
> "Hazlitt thinks the latter. "DAB is not an economically viable platform
> for us. Other radio operators may think differently and that is entirely
> their prerogative," she said today.
> "What we look at is consumers and they are saying it is not a big platform
> of choice for them. It does not provide an experience that is sufficiently
> better quality than what they have on FM."
>
> The first para is the claim is that the high transmission costs are
currently making DAB unviable for commercial broadcasters. Many DAB stations
are earning a profit - including, I understand, Planet Rock and the Jazz -
but nowhere near the kind of profit margins that commercial radio's used to.
Fru needed to add to the profit-to-earnings ratio that Fru's shareholders
expected at the time to stave off a takeover. Removing the DAB stations
assisted her in this. Note that none have actually closed as yet. Note, too,
that no other radio group has joined Fru in her talking-down of DAB; and
note that nobody has claimed that FM is dead now she's selling three XFMs.

Secondly, her claim on quality is absolutely correct. It's why DAB is sold
on choice, not quality.


The parents still don't have a digital radio, exactly because they know that
> the spec will change at some point in the future.
>

Well, I hope the parents didn't buy a Sky analogue receiver (useless after
ten years), an analogue mobile phone (now useless), a Rabbit phone, an early
OnDigital box, or an original PlayStation. Technology changes. I know it's
unusual for a radio, but it's kind of the way technology works these days.


>  What worries me is that digital radio is almost still in a state of flux;
> in the space of three years, an industry-changing redefinition of the DAB
> standard is released and it causes all sorts of headaches and potential
> problems for manufacturers and broadcasters.
>

On the contrary - digital radio is in no "state of flux" here in the UK. No
broadcasters in the UK have any plans to change to AAC+. The additional
codec is an addition, not a mandated replacement.

Note, too, that AAC+ does not mean better sound quality; it means more
efficient compression. It means commercial radio can significantly cut their
transmission costs; not significantly increase audio quality - don't forget,
you pay by the bitrate on commercial multiplexes. AAC+ will not immediately
mean better quality audio.

-- 
http://james.cridland.net/ | http://www.mediauk.com/

Media UK is a Not At All Bad Ltd production.
http://notatallbad.ltd.uk/legal_info/


Re: [backstage] iPlayer in Wii

2008-04-12 Thread Michael
On Saturday 12 April 2008 05:57:49 Brian Butterworth wrote:
> If it were all doing using HTTP it would be easily cached, of course, as
> you can do this with a proxy server, either a configured-in one as used on
> corporate and educational networks, or as a transparent proxy.

Ignores the fact that most caches will not cache objects over a certain size. 
(The maximum usually based on average object size, which is dominated by
small images and HTML). Also it depends on the purpose the cache is there
for - speed or bandwidth savings, and even then you still need a maximum, it's
just where you set it which will vary.

There are algorithms that will take into account object size and popularity 
(combination of LFU & GDS approaches), but they're still mainly targetted at 
object size distributions below the 90-95th percentile.

You can use whitelisting, but the maintainence overhead of such a whitelist
can become quite spectacular, and can depend on the purpose behind
caching in their network ((peceived) speed saving or bandwidth saving[1]).
Thus, whitelisting or changing the maximum object size can massively
impacts the effectiveness of the cache infrastructure as a whole.

   [1] These two do not always correlate, since one is based on percentiles,
the other is absolute figures.

(I worked for the best part 5 years looking at this sort of stuff in great 
detail in both theoretical and (a wide variety of) operational environments, 
so I'm summarising :-)

Also, none of this is any use for streaming over RTMP. (and HTTP streaming
has major issues, not least the fact that you can't index sensibly by time
without impacting (or working around) patents)

NB. I'm all in favour of making websites cacheable where possible/reasonable 
since it's a really, really, good idea, but it's just worth remembering we're 
looking at outlying values regarding a non-HTTP protocol.


Michael.
-
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] iPlayer in Wii

2008-04-12 Thread Peter Bowyer
On 11/04/2008, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-04-09 at 16:13 +0100, Peter Bowyer wrote:
>  > On 09/04/2008, David McBride <[EMAIL PROTECTED]> wrote:
>  > > Dave Crossland wrote:
>  > >
>  > > > The BBC-vs-ISP bandwidth issue could be resolved by the BBC dropping
>  > > > DRM so that the ISPs can cache the data.
>  > >
>  > > The ISPs who are anticipating financial hardship are more concerned with 
> the
>  > > cost of bandwidth between their network and home ADSL users, and _not_ 
> between
>  > > their network and the outside world.
>  > >
>  > > This is because they are charged a metered rate by BT for all the 
> traffic they
>  > > relay over BT's ADSL network.
>  > >
>  > > Thus adding data caches to their network wouldn't solve their immediate 
> problem.
>  >
>  > Indeed. But BTW could do it for the benefit of all of its resellers.
>
>
> It doesn't work like that. You have a pipe which runs all the way
>  through BT's network to your ISP. Even if the content in question were
>  somehow cached on a machine in your local exchange, that doesn't really
>  help because it doesn't see your IP traffic at all. Traffic from that
>  cache to you would go all the way out to your ISP and then back down
>  your pipe.

Yeah, I know how it works - 5 years in broadband OSS/BSS.

I agree that the current L2TP architecture wouldn't support it, but
there's nothing stopping  BTW making it so if there was a business
case for it. In fact, since IPStream is a regulated product, the
industry could put forward a statement of requirements and have them
consider it. That would scale way better than each iddly-piddly
IPStream reseller doing the caching themselves.

Peter
-- 
Peter Bowyer
Email: [EMAIL PROTECTED]
Follow me on Twitter: twitter.com/peeebeee
-
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/