[opendtv] Re: News: Those licenses will soon be worthless...
- From: "John Willkie" <JohnWillkie@xxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Tue, 26 Apr 2005 17:02:56 -0700
I do not have a recent edition of 13818-1, so I don't have the ammunition to
try to refute your assertion.
ATSC previously had a recommendation to harmonize DVB-SI. The most recent
change is to protext ARIB, which uses pids from hex 20 through 2f; if it was
just DVB-SI, they would could be accommodated with avoiding pids between 16
through 31 decimal.
ATSC cares about this, I presume (or have been told), because there are
plenty of pids to play with, and ATSC considers itself to be a global
organization. By reserving those pids, ATSC transport streams can be
rebroadcast as is around the world without breaking DVB or ARIB gear.
This is something of a mantra with ATSC. It's the reason why ATSC maintains
a code point registry; a global document that lists the values for various
elements used in DVB, ATSC, MPEG and ARIB systems.
I'd be real interested in hearing about what problems this causes for DTV
stations. Mostly, what I hear about is encoder manufacturers that
hard-coded the optional program_paradigm into their encoders. This SPECIFIC
issue has created a business opportunity for me, one that I am pursuing with
some of the big names in broadcast equipment.
My understanding is that this in not an issue with Divicom encoders, now a
division of Harmonic. I am told that for their encoders to transmit
program_number 1 on pid 48 is just a matter of telling it to do so. Not
everyone, apparently, did it wrong.
I will concede that cross-system exchange of transport streams is a remote
possibility, and if it needs to be done, the only reason to avoid pid
conflicts is to avoid re-multiplexing the transport stream(s).
John Willkie
----- Original Message -----
From: "Ron Economos" <k6mpg@xxxxxxxxxxx>
To: <opendtv@xxxxxxxxxxxxx>
Sent: Tuesday, April 26, 2005 2:00 PM
Subject: [opendtv] Re: News: Those licenses will soon be worthless...
> MPEG-2 only reserves PID values 0x0 thru 0xf
> and 0x1fff.
> The rule to only use PID values 0x30 and above
> for ATSC, is so that ATSC PID values do not
> conflict with DVB-SI PID values.
>
> My point is, why does ATSC care about DVB?
> What US, Canada, Mexico or South Korea
> DTV station is using DVB-SI in their ATSC
> bitstream?
>
> The rule seems utterly superfluous to me, yet has
> caused lot's of problems for DTV stations.
>
> Ron
>
> John Willkie wrote:
>
> >Ron;
> >
> >Why do you think it's an ATSC issue? The same rules apply to DVB, ARIB,
> >ATSC and any other MPEG private users that may arise in the future. I
note
> >that you jump to blaming ATSC.
> >
> >1) because they have to, per MPEG rules, at least I've been told.
> >2) I don't know what a pink ticket is, because the only thing that is
pink
> >is the duplicate (carbon) copy of the letter placed in the station's
file.
> >However, it's the same color as any other carbon copy placed in the
station
> >file.
> >
> >The answer to 2 is no, not yet. However, it's arguable that the issue
will
> >arise. Stations have to follow ATSC rules, which are enshrined in ATSC
> >specs, and which are embodied in large part in FCC rules. ATSC specs
refer
> >to, or are normative to MPEG specs.
> >
> >Who wants to be the first case?
> >
> >John Willkie
> >
> >----- Original Message -----
> >From: "Ron Economos" <k6mpg@xxxxxxxxxxx>
> >To: <opendtv@xxxxxxxxxxxxx>
> >Sent: Tuesday, April 26, 2005 3:19 AM
> >Subject: [opendtv] Re: News: Those licenses will soon be worthless...
> >
> >
> >
> >
> >>A couple of questions:
> >>1) Why does ATSC even care about PID values, given
> >>that no dual mode (ATSC/DVB) receiver exists or
> >>would ever be built?
> >>
> >>2) If a DTV station were to continue using PID's below
> >>0x30, would they ever receive a citation (pink ticket) from
> >>the FCC?
> >>
> >>Ron
> >>
> >>
> >>John Willkie wrote:
> >>
> >>
> >>
> >>>Okay, the first item was a poke. As to the other items, I think we
will
> >>>have to agree to disagree, because there is no need to belabor our
> >>>
> >>>
> >points:
> >
> >
> >>>time will tell.
> >>>
> >>>However, I object strongly enough to the following to object:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>You should understand this better than anyone. If they can't get
> >>>>something as simple as PSIP right, how the hell are they going to use
> >>>>demographic data to drive customized ads to specific sub markets,
> >>>>much less individuals?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Sure, it can be tough -- with the current divide between encoders and
> >>>multiplexers and PSIP generators to get MPEG-2 PSI and PSIP both right
> >>>
> >>>
> >and
> >
> >
> >>>consistent with each other, and consistent with the elementary streams.
> >>>
> >>>But, it's too early to blame the broadcasters for this problem. I was
> >>>careful at the show to talk to most of, if not all of, the companies in
> >>>
> >>>
> >the
> >
> >
> >>>encoder and transport stream test and measurement field. Since PSI and
> >>>
> >>>
> >PSIP
> >
> >
> >>>is all I know, I spotted all sorts of out-of compliance encoders and
t&m
> >>>gear that were analyzing transport streams that were out of spec with
> >>>
> >>>
> >MPEG-2
> >
> >
> >>>and DVB and ATSC.
> >>>
> >>>I have to be real careful here, and I offer a caveat: I can only
mention
> >>>the name of "bad actors" with whom I have no chance of sale/strategic
> >>>alliance. Sometimes, what prevents a deal is a problem they have with
me,
> >>>other times, what prevents a deal is a problem with them, and in some
> >>>
> >>>
> >cases,
> >
> >
> >>>it's a problem with both.
> >>>
> >>>Encoders:
> >>>Ligos Corporation showed an encoder that permitted, in ATSC mode,
> >>>
> >>>
> >elementary
> >
> >
> >>>streams on any pid from 16 to 8190. The minimum permitted now is 48;
the
> >>>maximum permitted per ATSC is around 1000 (I don't have the spec in
front
> >>>
> >>>
> >of
> >
> >
> >>>me, and I wrote that part some months and years back. The engineer
told
> >>>
> >>>
> >me
> >
> >
> >>>"we wrote to the spec." And, I said "you didn't use the right spec on
> >>>
> >>>
> >the
> >
> >
> >>>upside, and on the downside, the spec changed effective January 1,
2005."
> >>>
> >>>DoReMi's president interrupted me in the middle of a 6 second question.
> >>>He's tied with two others for my a**hole of the show award.
> >>>
> >>>Optibase told me that they would consider my solution to pid remapping
> >>>
> >>>
> >when
> >
> >
> >>>I brought them a customer. (Ain't my job, and it won't happen in this
> >>>lifetime.) Ofem something or another is another tied honoree. I did
get
> >>>them back; I leaned (twice) on their plasma displays. I hope my
> >>>
> >>>
> >handprints
> >
> >
> >>>were there through the show.
> >>>
> >>>t&m
> >>>Every t&m company whose wares I sampled was showing out of compliance
> >>>
> >>>
> >(per
> >
> >
> >>>MPEG-2, or ATSC or DVB) transport streams, usually on the "minimum pid
>=
> >>>
> >>>
> >48
> >
> >
> >>>issue." Not a single one of them flagged this issue. They would try
to
> >>>
> >>>
> >go
> >
> >
> >>>into another emission mode to solve the problem, but it's an MPEG-2
> >>>
> >>>
> >issue,
> >
> >
> >>>not an ATSC, DVB or ARIB one.
> >>>
> >>>It would be imprudent (and potentially costly) for me to identify these
> >>>firms: I'm talking to most if not all about licensing my PSI/PSIP t&m
> >>>system. I will say that I did not look to see f the Videotek monitors
> >>>
> >>>
> >had
> >
> >
> >>>this issue, nor did I visit the Wegener booth. I did talk to the
"usual
> >>>suspects" and found this is a widespread problem.
> >>>
> >>>So;
> >>>
> >>>If the encoders enable you to send out-of-compliance transport streams,
> >>>
> >>>
> >and
> >
> >
> >>>the test and measurement gear doesn't flag out of complaince elementary
> >>>streams and program map table instances, how can one blame
> >>>
> >>>
> >broadcasters --
> >
> >
> >>>many, if not most are now in compliance with the minimum pid issue
often
> >>>through kludges (program_number 1 on pid 48) -- for not detecting the
> >>>problem.
> >>>
> >>>John Willkie
> >>>
> >>>
> >>>
> >>>
>
>
>
>
> ----------------------------------------------------------------------
> 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:
