[opendtv] Re: September Download Column

  • From: Tom Barry <trbarry@xxxxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Tue, 03 Oct 2006 20:16:47 -0400



Craig Birkmaier wrote: (in that article)
---<quote>---
While many people use the term IPTV to describe the entire emerging landscape of television delivered via IP networks, others insist that IPTV refers only to the “walled garden” services now offered by the telcos that are competing against the well-entrenched cable and DBS systems.


There is a very good technical reason for this distinction. The ability to maintain the same level of image and service quality as cable and DBS is not easily achieved using traditional broadband services and the public Internet.

With the Internet, some of the packets may be lost as they are routed from the source (a server) to the destination, where the content is reassembled and presented. These lost packets are typically retransmitted to the destination. And all IP packets may not arrive in the same sequence as they were sent.

For most files (even downloaded IP media files), this is not a major concern. When the media is being streamed and viewed in real time, however, lost packets pose a problem, causing momentary loss of signal or picture/sound impairments.
---</quote>---


It's the "real time" part that seems to me to be the problem. Folks are used 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 video over the Internet.

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 be 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.

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 best 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.

So, what really is "real time"? How low latency does it have to be in order to compete with TV as we know it?

(assume memory buffers are free these days)

- Tom





BE has just revamped their website design. Burried somewhere in there is my monthly column...

This one is certain to set Bert off...again!

http://broadcastengineering.com/mag/broadcasting_iptv_buzz/

Regards
Craig


---------------------------------------------------------------------- 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.




-- Tom Barry trbarry@xxxxxxxxxxx Find my resume and video filters at www.trbarry.com



----------------------------------------------------------------------
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: