[opendtv] Re: September Download Column
- From: "Albert Manfredi" <bert22306@xxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Tue, 03 Oct 2006 20:51:48 -0400
Tom Barry wrote:
It's the "real time" part that seems to me to be the problem. Folks are
to channel surfing on TV with sub-second delay in changing channels. But
this is a big problem if you want to use efficient error correction for
over the Internet.
To a smaller degree, that's also a problem with DTT. Channel switching is
slower and, at least with demods that don't use the training sequence, it
can be even slower if the equalizer has to think.
As far as I can tell, normal Internet broadband does not really have that
horrendous an error rate if you could just measure it over a long period of
time. If only the errors were randomly distributed then they could easily
corrected with reasonable overhead.
The problem is that, at least on my Comcast line and other research I have
access to, the line will drop almost zero packets for awhile and then lose
most all of them for some period of time. This too can be easily corrected
but only if you are willing to put up with a fairly long buffering delay.
Even with buffer delays on the order of 10 seconds, this can and does still
happen, over the Internet. Some router somewhere between here and who knows
where gets temporarily clobbered with congestion, or maybe it drops off line
entirely and the route has to be recomputed. Craig did mention this. You
don't have a dedicated circuit.
I watch streaming TV from Europe almost daily. The (image and audio) quality
is low, and buffer starvation is not uncommon. The low quality could in
principle solve itself as ISP nets and the major backbones grow faster.
Still, if telcos expect to compete aginst digital cable and HD DBS in the
next few years, they obviously have to offer something a lot better than
Internet TV, seems to me.
And none of even begins to cover copyright issues.
For instance, assume we were maybe willing to allocate maybe 10% of all
blocks as redundant error correcting blocks. And assume we wanted to be
able to pad over drop-outs lasting up to a full 2 seconds. I believe in
case this means we would have to buffer more than 20 seconds of video
just to cover the errors, not counting other processing. But nobody wants
20+ seconds delay on watching TV because of our current expectations.
Another oiption: use SCTP (RFC 3286) and create redundant streams. Problem
is, this is only good for unicast and creates even more traffic. On the
other hand, given enough sources of TV content, perhaps people won't all go
for the same programs, and unicast would scale well enough.
It is hard to beat true broadcast sometimes, methinks.
Search?Your way, your world, right now!
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: