[mythtv] ATSC question
blooflame at comcast.net
Thu Feb 25 03:51:04 UTC 2010
How does A/57B tie into this, which is where I started from?
From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
On Behalf Of Daniel Kristjansson
Sent: Wednesday, February 24, 2010 12:46 PM
To: Development of mythtv
Subject: Re: [mythtv] ATSC question
On Wed, 2010-02-24 at 12:21 -0500, Devin Heitmueller wrote:
> On Wed, Feb 24, 2010 at 12:06 PM, Dan Wilga
> <mythtv-dev2 at dwilga-linux1.amherst.edu> wrote:
> > Perhaps I misread something, but I thought one of the previous posts
> > that there is a change in the data when a program actually starts, for
> > V-CHIP purposes. I assume that the broadcasters don't automatically say,
> > "just because it's 7:00 PM on Sunday I'm going to send out the V-CHIP
> > for 60 Minutes," whether it's on or not. I assume they only send the
> > when the program actually starts. Otherwise, V-CHIP wouldn't really be
> > what's it's supposed to do.
> It's been a few months since I've looked at the spec, but if I recall,
> the RRT data is associated with data in the program guide, which is
> expected to be used in conjunction with the sychronized realtime clock
> being sent down the wire (another mandatory part of PSIP). I believe
> the receiver is expected to correlate the information.
RRT is part of the PSIP with guide data so that is equally flawed.
The less detailed V-Chip data is present in the EIA-608 closed
caption stream which is encoded inside EIA-708 packets in the
video data of the MPEG-2 stream itself. So even if the RRT's are
incorrect, any V-Chip enabled TV will pick up the V-Chip data from
that and do not need to decode the RRTs. Using this V-Chip data
wouldn't be very useful for extending recordings as this doesn't
necessarily change at the start of a new recordings and there are
also no reliable hashes on this data so it is often corrupted even
in digital broadcasts.
How PSIP is tied in with the broadcasting system is of course
up to the broadcaster but it's my understanding that most do not
marry it to programs themselves via MXF or what have you, but
instead apply it as a post-processes using TMS or Rovi data.
Broadcasters are moving toward the model of tying the metadata
for PSIP to the programs which would allow them to produce their
own PSIP, but at a somewhat glacial pace. I only know of one
PBS broadcaster which actually does that currently (although
I may be a bit out of date on that as I haven't dealt with
PSIP stuff in a while.)
BTW MythTV does not currently decode the RRT. There is a stub
for it and wouldn't be hard to add the decoding, but what to
do with that data is a larger question.
mythtv-dev mailing list
mythtv-dev at mythtv.org
More information about the mythtv-dev