[mythtv] Re: Ticket #109: DVB/ATSC patch to allow configuring channels via channels.conf

[Daniel Kristjansson]

On Fri, 2005-07-15 at 22:57 -0400, Christiaan Lutzer wrote:
> If you consider a MPTS, you only need to specify the program number
> (PN) to tune to a specific program in the stream.  A good example is
> Comcast Cable.  They are moving to a more dynamic architecture whereby
> set tops tune to digital program by frequency and program number. 
> Assuming a MPTS in the clear, that's all the information you need
> (assuming QAM 256, etc.) to tune to a given program.
How do we know the stream is in the clear? Does comcast use MPEG, DVB or
ATSC tables to specify this, or something else?

> Once you know the PN, you can examine the PMT to glean the audio and
> video pids (as well as any other pids such as data, etc.) that belong
> to the program.  I think within the context of MythTV, the program
Sure.

> It would be redundant, and incorrect to specify the audio/video pids,
> because technically (as far as I know) they are arbitrary with respect
> to the program number.  It's really up to the MSO and their TS gear. 
Well, my assumption was that if the VCT table was borked, we might as
well assume the PAT & PMT are borked as well. I've read this is the
case in the UK, for example. But I guess they could still be MPEG-2
compliant, while not being ATSC compliant. That would make sense if
they were OpenCable compliant. Using the ATSC Major and Minor channels
means that things continue to work when the program numbers change, so
I'd like that as the 'preferred method', but using the program number
should probably be the first fall-back.

> A parallel example would be in the use of DSM-CC to control VOD
> sessions, upon a session setup response, the set top is given a
> frequency and program number to tune to (in a typical HFC plant). 
> Given that program number, the PAT and PMT are inspected for
> audio/video pids.
DSM-CC, is that in ATSC? Anyway, yes this supports the program numbers
being a valid thing to use.

> You'll notice that I only added the service ID parsing for the ATSC
> case.  The original author must have been thinking along the same
> lines, but perhaps he assumed a service ID, as opposed to a specified
> one.
Actually, I believe the original author was probably thinking of 
DVB service id's. Which, when it comes to the PAT, happen to be 
the same thing as a MPEG program numbers.

So how does:
  name, frequency, modulation, atsc channel, [program number]
sound?

If it turns out someone needs pid level control that can be added later.

-- Daniel