[opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES

  • From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
  • To: <opendtv@xxxxxxxxxxxxx>
  • Date: Tue, 4 Mar 2008 10:58:58 -0800

Point taken.  So, the argument from stripping PSIP out of the multiplex --
which the FCC explicitly requires cable to pass on -- is _____?

In terms of bit-budget, My first customer has six virtual channels, each
with 15 hours of titles and descriptions.  Bit budget?  Circa 100 kilobits
per second.

If the argument is that "some" broadcasters don't know what they're doing
(announcing sap audio but not offering it), I'd say that there are worse
cases of that around, and I trust things will get better as broadcasters
focus on making money with DTV.

John Willkie

-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Adam Goldberg
Enviado el: Tuesday, March 04, 2008 7:56 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES

I was getting ready to write "First of all, "every bit" is a bit of
hyperbole.  AFD takes 6 /bytes/ per frame."

But then a buddy of mine called, who is a senior engineering type at a very
large MSO and has a big hand in creating the multiplexes they send to each
head-end.  I asked him about stripping AFD.  His response was:  "That's the
craziest thing I've ever heard".

In fact, he said, he has several channels where SAP was supposed to be
provided but isn't, so it's provisioned but not supplied.  If he were to go
looking to save a few hundred kbps, he'd start unprovisioning the SAPs, not
worrying about 1440bps of AFD.  He then went on to say that they'd like
there to be MORE AFD supplied so they can actually use it.

-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of John Willkie
Sent: Monday, March 03, 2008 6:00 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES

I'm almost willing to make a bet that it will be common for cable systems to
do this: they fight over every bit.  They take out 20%-50% of the video
content, (and fight for the right to do so) and still call it HDTV.

The less it makes sense, the more they are likely to do it.  Why, oh, why,
despite FCC rules, do they strip out PSIP?  So their users can use
lower-quality, lower-utility, hard to use cable EPGs.

John Willkie

-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Adam Goldberg
Enviado el: Monday, March 03, 2008 2:10 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES

> The AFD or pan-scan/bar data mechanism can support carrying the data
through
> to TV sets; AFD is more robust in that regard, but at this moment, cable
> isn't required to pass on AFD, if present. (That should change shortly.)

Cable may not be required to, but in order to remove it they'd have to edit
the picture user data on-the-fly.  IMHO, they're unlikely to do that.

-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of John Willkie
Sent: Monday, March 03, 2008 3:38 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES

Facility:

You can pass (I don't know at this moment if it's a published standard, cd
or fcd at SMPTE) for this type of encoding.  I can't remember if it's in the
VANC or HANC (I think it might be in both.)  I am speaking of a standard,
not a vendor-specific solution.

BXF (SMPTE 2021, a full committee draft at this moment) supports the
functionality Martin mentioned.  (I'm not sure that it goes all the way back
to sales, but it certainly can.)  This article in the most recent issue of
BE covers BXF and PMCP.
http://broadcastengineering.com/storage_networking/building_better_epgs_801/
index.html

Transmission

The AFD or pan-scan/bar data mechanism can support carrying the data through
to TV sets; AFD is more robust in that regard, but at this moment, cable
isn't required to pass on AFD, if present. (That should change shortly.)

John Willkie

-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de John Shutt
Enviado el: Monday, March 03, 2008 12:25 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES

----- Original Message ----- 
From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>

> The problem is in marking the materials to be shown in the "run list" or
> automation process and inserting the data into the video stream.  Can you
> carry the input of this data all the way back to the beginning of the 
> ingest
> process or even sales?

John,

My point exactly, and I'm glad to see the industry also agrees with me. 
What I said is that there is no standard way of identifying material as 
anamorphic 16:9 or 4:3.

Come up with a SMPTE standard to pass along AFD within the VANC data of 
SD-SDI, do so in a way that any company's cross converter can understand and

automatically follow, and then we can start mixing and matching formats 
within the server.

As things stand right now, it is up to a traffic database to keep track of 
such things, and a station automation system to change modes on a cross 
converter.  Too dicey and too limited in usefulness.

There needs to be a standard that hard encodes the AFD into the video that 
survives any and all processing in the production and distribution chain 
from initial acquition to final home viewing, just as closed captioning and 
V-chip information remains preserved.  It can even live inside the CC/V-Chip

data area to make sure it will survive all processing.

But there has to be an agreed upon standard first.  Right now there is no 
standard, just a bunch of different proposals or specialized solutions.

John




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



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


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



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


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



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