[opendtv] PSIP Issues
- From: John Willkie <johnwillkie@xxxxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Thu, 16 Feb 2006 19:10:09 +0000 (GMT+00:00)
I've seen many recent "folk tales" posts about problems with Accurian receivers
in the context of watching WRC-TV in Washington, DC.
We've also got an NBC operated (but not fully NBC owned) station in San Diego.
NBC, somewhat differently than the other networks, does their buying and system
provisioning as a group.
Here's what recently happened, going by my review of transport streams of
KNSD-DT in San Diego.
Until VERY recently, KNSD -- and by extension, the rest of the group -- did not
offer dynamic PSIP. They only offered static PSIP, with "Regularly Scheduled
Programming" being the only program.
I find it odd that Bert comlained about the unit locking up on channel 4-2 and
attributing that to PSIP problems (which he alluded to being the station
offering bad PSIP [which I doubt is the case] yet he never mentioned the EPG
functions that are the ONLY real improvement with DTV sets (provided the
stations offer dynamic pogram information.)
A properly implemented DTV receiver does not need PSIP to demodulate and render
media streams. PERIOD. A properly implemented DTV receiver needs PSIP to
fully associate elementary and program streams -- so, for example, you know
that there is a spanish language audio track when you tune into a channel. If
you have set your language preference in your properly implemented receiver to
Spanish, when you tune to a channel that offers a spanish audio track, the
properly implemented receiver will default to that language track, instead of
defaulting to a language track based on numeric criteria.
I seriously doubt that the change of NBC from static to dynamic PSIP could have
cured the problem that Bert noted; he lacks the data points, and he latches
onto the most simple analysis and excuse. I note that the problem has
returned, but I note no data points on whether WRC is having problems with it's
dynamic PSIP generator and has resorted to the static PSIP provided by their
encoder.
I captured a transport stream of KNSD the day after reading here that the
problem with WRC had been solved after a system-wide upgrade. Viola! Dynamic
PSIP for the first time, with actual program listings.
The tool I use to analyze streams is my own: EtherGuide Ferret, a PSIP test and
measurement system that is still in development, but is nearing a commercial
release or two. It will (in a few days) fully analyze MPEG-2 PSI and PSIP and
compare them to the actual elementary streams, noting any differences.
EtherGuide Ferret enables anybody at a TV station AT A GLANCE to see how well
or badly their PSIP generator is behaving.
Before I go on, I should note two facts: I haven't talked to anybody at NBC
about this, but I could have; I have the phone numbers and emal addresses of
the appropriate people, and I've talked to more than a few of them over the
years. I am dealing in actual bits, not what people think about their bits.
Secondly, lthough my analysis isn't complete at this moment, I not noted any
glaring errors in KNSD bit streams.
There is an important fact to keep in mind. AS NOTED IN ATSC A/65, there is
one glaring problem with older Korean receivers vis a vis PSIP. This problem
is caused when a station emits ETT (extended text tables, which come in two
varieties, channel and event). Early versions of A65 were ambiguous as to the
use of the table_id_extension (bytes 4 and 5 in the MPEG-2 private table
structure). Idiot Korean engineers (there are idiot engineers in all
countries; just a few of which make tv sets and STBs) just assumed this field
would always be "zero."
As noted in A/65, when this field is non-zero early Korean receiever go crazy.
The spec was modified to require this field to be zero.
In my recent transport streams, I noted that several local stations here in San
Diego have ETTs where the table_id_extension field is non-zero. This will
cause problems with early, cheap Korean receivers and STBs. And, the problem
will not necessarily come up on the station emitting non-compliant PSIP: it can
come up anywhere, only limited by the way that the stb associates tables with
transport streams.
Why do I attribute this issue to be at stake with Accurian STBs, when they are
not early cheap Korean receivers? That's simple: because I believe them to be
early, cheap Korean receivers, whored out to the U.S. market.
The receiver issues with PSIP were solved in silicon several years ago. The
guy who wrote the silicon solution and have talked, though not recently. He
said he had zero interest in his solution from first tier makers who either
long ago solved their PSIP problems (or in the case of Sony, didn't care that
they have PSIP issues in their expensive boxes); nor was there any interest at
the lowest end of the market. The second and third tier of the maket was his
forte.
Here's what I surmise happened: rather than paying real money for a working
psip solution, the maker of the Accurian boxes did one step worse than Sony;
they liceensed PSIP chip "solutions" that were "good" enough years ago for
Korea, a country with three PSIP generators. (Right now, there are two PSIP
sources in Tijuana; they'll have more than Korea within a year or so.) In
other words, they licensed non-complaint, discredited Korean implementations.
I took the time and trouble to (finally) post this to the OpenDTV list, despite
the low level of most discussions hereabouts. I intend to post a version of
this to my PSIP list, where makers of PSIP equipment (tx and rx) reside,and
where few of my posts there go fully unchallenged. I write this because I like
give-and-take, but it has to lead to somewhere, or it's fruitless and
ultimately destructive. (On this point, Dermot and I are on the same page.)
John Willkie
EtherGuide Systems
----------------------------------------------------------------------
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: