[mythtv] DVBCam Class

[Kenneth Aafløy]

On Tuesday 21 September 2004 02:44, Taylor Jacob wrote:
> > You might be best to try and contact Kenneth Aafloy who wrote the
> > original code (and also has a CAM).  I guess he doesn't read the list
> > much. 

Nah, have been absent for a while.

> I sent him an email about 2 months ago on this subject and have yet to hear
> from him, so I am just assuming he is out of the picture now..

Answered you on IRC, but I guess you are just hanging around all day and not 
recording the logs..

> > I would be interested in seeing a little more about what you are doing
> > here, but not much time
>
> right now (and no cam either).

What?

> In general:
>
> COMPLETE: New PAT/PMT(maybe CAT) parsing class that is responsible for
> pulling those tables upon setting the Frontend (not a lock).  This can
> verify the service exists on teh transport if desired and also do auto-pid
> tuning..  I have heard some complaints about speed but so far it doesnt
> seem to slow anything down as 1/3 of the time i get the PMT before the
> frontend reports a lock..

Nice..

> TESTING NOW: New tuning scheme that allows tuning to a specific transport
> (not sending PIDS to recorder).. This will have a table of transports that
> is used to tune to instead of each channel having duplicate information in
> the dvb_channel table.. This also eliminates the need for dvb_channel.

I'm not sure why the hell you want to remove the caching of pids in a channel,
but hiding it in the channel table could be a benefit (a channel private field 
with some encoding).

> COMPLETE: A DVB-S card will have multiple inputs depending on what type of
> DiSEqC switch its connected to.. This eliminates the need for the dvb_sat
> table which completely breaks any type of relational database design..

Never thought of it this way, nice.

> TESTING NOW: DVB Scanning class that queries the SDT tables and populates
> the channels into channel and also grabs the PIDS and shoves them into
> dvb_pids.  I have this done for DVB-S and testing is going on by John
> Pullan for DVB-T.

Would this be run in idle time to update all my channels, if so, nice :)

> TODO: A guide grabbing class that will querey the NIT and SDT tables ot
> determine where (and if) any guide is present.. Start dumping guide data
> and shoving it into program.. I have the parsers and tracking objects done
> (tracking object checks what has been seen before and what is to be
> expected still).

The Event information is from what I have seen very thin, but if you could 
come up with an algorithm to match running status (if it exists) with the 
current schedule, great!

> I need to do some testing on this, but I am pretty sure that the Guide
> Tracker will have to be able to handle ATSC over DVB (I think this is used
> in Australia, and is used by PBS here int eh states on their feed bird
> AMC3).  This class will be general enouigh that a crc checked table can be
> passed into it and the class will figure out what to do from there an do
> the DB insert so it can be used byt he ATSC people as well..

Dunno what you are talking about here, please elaborate.

> ----- Once this is complete I will post a patch (The ATSC Guide stuff will
> wait).  I cannot really release a patch without people being able to
> populate guide (which is where it is now) since the zap2it ID in the
> channel table gets populated with NetworkID.ServiceID..
>
> FUTURE PLANS:
> I then plan on eliminating the transform.c code (or at least commenting it
> out) and creating a common MPEGTS recoder class that the HDTV recorder will
> use as well as the DVB recorder.. I have moved some of the key functions
> (FindKeyFrames being one) over to the dvbrecorder for testing and it works
> great..
>
> You will get a SLIGHT tuning improvement using the combine MPEG TS recorder
> code since it will start writong to the RingBuffer upon getting a GOP frame
> where as the curret transport waits to get a GOP, and also a complete
> segment (MPEG TS Contuinity counters worth of data) and then writes.. This
> is probbably negleglble but its still something..

That delay was put there for a reason, namely that CAMs will often start 
decoding the audio first and after a delay the video, both of these streams 
would sometimes be corrupt at the start, so this code was put there to limit 
this problem. I guess you could base this on whether or not the current 
channel is encrypted or not :)

Kenneth