[opendtv] Re: OTA and MVPD competition
- From: "Kon Wilms" <kon@xxxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Thu, 7 Feb 2008 17:00:47 -0800
On Feb 7, 2008 3:54 PM, Tom Barry <trbarry@xxxxxxxxxxx> wrote:
> I mean LARGE buffers, on disk if needed. Everything I've done with
> error correction suggests it is much easier (with LDPC) if you can look
> many seconds out in the future. No good for video conferencing or even
> real time broadcasting that way because of the latency but very
> effective for delayed data, making it possible to pad over even
> multi-second dropouts.
If you want to handle multi-second dropouts you need a lot of parity
blocks. And you still have to deliver those blocks to the receiver.
You reach a point where you can't guarantee the delivery of the parity
packets, and the system falls apart.
You basically have a token bucket at the headend and a leaky bucket at
the receiver. Bitrate inbetween can drop to zero at any time for any
duration. And ofcourse a one-way network. This is the unfortunate
situation when it comes to OTA data delivery. And if you're talking
about multi-hop.. well, forget about any end to end streaming. Period.
So, the only solution it would seem, is to lower the bitrate of the
source live stream. And now you're back at the chicken and egg
situation where maybe it is a better idea to just send the actual file
across and not try to stream it.
Sorry but I have watched so many implementations fail over the last 15
or something years precisely because they think they could best this
problem with a big-ass buffer at the endpoint. And it never worked for
any of them without sacrifices.
Picture quality, decode reliability, or low edge resource consumption.
Pick any two. And in some cases, just one.
The solution which makes more sense is to cleverly splice local
content on the STB with live content, thus guaranteeing maximum
opportunistic bandwidth for the duration of the local 'live' cache
playout, and allowing you to deliver that stuff you would otherwise
stream with large buffers in a faster-than-realtime mode.
I've been working on a delivery system for about 4 years now and the
parity mechanism I have found to be most reliable is LDPC or
alternatively software RS (depending on the amount of cpu and ram on
the receiver) using small block groups and parity not exceeding 20%.
For really small stuff like files < 256Mb I have a software
Vandermonde matrix-based en/decoder that works pretty well. The trick
is to trade off one algorithm for another depending on payload size
and delivery bitrate.
> > The best option for OTA is and has always
> > been to stuff a drive in a receiver and opportunistically fill it with
> > as much content as possible, while providing one or two channels of
> > live content that are not 'live' 24/7, are sent in VBR, and are
> > spliced with trickled content played from disk as if it were realtime.
> > The same goes for advertising and repeat broadcasts. Trickle it if
> > timer permits, or else have the receiver record it in the background.
> >
> I'm not really sure we are saying anything different.
Actually we are. You are absolutely guaranteed a buffer dropout, no
matter the size of your receiver buffer, if you use opportunistic
delivery. Unless you start guaranteeing a minimum amount of
deterministic bandwidth. In which case you may as well just be
delivering the content as files and not video streams.
> > We have customers providing a 'virtual' bouquet of up to 100 EPG
> > channels and VOD using only two live encoders and 750-1.5Mbit
> > opportunistic 24/7 trickle delivery using this mechanism.
>
> Cool. I don't remember who you work for, or if you have stated.
Logic Innovations.
> But I assume the biggest problems are not technical, but access to
> content rights. ;-)
Exactly :-). But that's not my problem!
Cheers
Kon
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
