How do you put a TV station on the Mbone?

Sat Apr 30 00:57:42 UTC 2011

> Subject: RE: How do you put a TV station on the Mbone?
> Date: Fri, 29 Apr 2011 15:15:42 -0700
> From: George Bonser <gbonser at seven.com>
>
> >
> > > Imagine: multicast internet radio! Awesome!
> >
> > That would, indeed, be awesome; when everyone in my office was 
> > listening to the royal wedding, there would be a *much* higher chance 
> > of them all being in sync.
> >
> > Cheers,
> > -- jra
>
> Exactly.  If more people/networks took advantage of multicast, it would 
> greatly reduce the bandwidth requirements, particularly for live events.  
> If there were 50 people listening to a popular radio show or watching a 
> live TV event in your office, for example, there would be only one feed 
> crossing the wire into your office.  And only one feed crossing into your 
> provider's network.
>
> I have *no* idea why applications developers have not been more 
> interested in this, particularly with radio and television stations 
> providing live streams on the net.  It is absolutely a waste of resources 
> to have a separate stream for each listener of a live event.

There's a layer 9 (or is it 10? <wry grin> -- required for legal reasons) 
answer for that.  Radio/television stations are required to pay 'performance'
royalties to the 'authors' and 'performers' of the works they transmit over 
the internet.  Those royalties are based on the _actual_number_ of persons
tuning in to each such work.  No 'averaging', no 'estimating', nothing
based on 'ratings', or other 'sampling techniques -- you have to count
the _actual_number_ of people tuned in.  It gets messy, but you have to
have 'auditable' records of when each person 'tuned in', and when they
'tuned out'.  One _has_ to be able to detect the latter condition under
all possible circumstances.  This means you must use a 'loss of signal'
methodology.  You can't trust the tuned-in listener to _actually_ stop
listening "just because" they said they would.  The people getting the
royalties will claim the tuned-in party lied, and they're due royalties
even after they said they're tuning out.  The people _paying_ the fees
won't accept having to pay for people who 'tuned out' in 'non-standard'
ways.   Ways like a program (or O/S, for that matter) crash, 'backhoe
fade, etc.

One party worries about people -not- tuning out when they said they are.
The other worries about people tuning out -without- saying they are.

The only to keep both sides happy is to use a methodology that is not
subject to either 'failure' mode.  This means a unique 'virtual circuit'
(aka data stream) to each user.