[mythtv] SI/PSIP Parser

Taylor Jacob rtjacob at earthlink.net
Wed Sep 22 11:59:06 EDT 2004


You might want to grab something to drink before you start reading my rambling long post.. :)

> ]I am in the process of moving my code into the new class.. The data
> ]will be passed in via a signal called ParseTable(uint8_t* buffer, int
> ]size);
> I'm a little concerned about using a signal. The only Qt feature I've
> used are container classes which have STL equivalents. The thought
> behind this is portability. I'd like the parser to be portable to other
> projects. A signal can be kludgy to implement without moc.

The signal is used only as a way of passing data into the parser.. I am trying to build the
SIParser as a black box as much as I can.. A signal just seems to be the best way to connect it
into both ATSC and DVB without making them be created under Recorder or Channel and not have to
change much code..

The class should be portable to other C++ projects, although I have used some QObjects like
QDateTime for date conversion that would need to be changed.  I also have used QSrings all over
the place since they can easily handle unicode (which is used with ATSC).  I have also used some
QValueLists but they could be changed to linked lists or something if you wanted to escape QT. 
Instead of using a signal to connect ParseTable in another project you would just call the
function ParseTable and create the class where the TS is being read.. If you don't like the
QDateTimes they can always be changed once its thrown into CVS and is working.. I just prefered
the QDateTime since i think it will be easier to do DB inserts of the data.. The more I think
about it trying to impliment the code without QObjects would be quite a mess for ATSC since they
use unicode for some things.  Implimenting it without signals and slots is trivial though.  You
would also have to replace functions like "InsertEventIntoDatabase()" to be handled differently by
your project.

> ]You will need to add slots to recorder called AddPid, DelPid that will
> ]control what pids you process.. This way once the MGT determines what
> ]PIDs have the EIT on them the recorder can know to grab these and send
> ]them off via the slot.

> I've implemented this by adding and deleting pids from a QMap which I
> lookup inside tspacketprocessor::Process(); These are stored in
> MPEGStreamData and are accessed with
> void AddListeningPID(unsigned int pid) { pid_listening[pid] = true; }
> void RemoveListeningPID(unsigned int pid) { pid_listening.erase(pid); }
> So I think this basically does this without making them signals, which I
> like.

The thing is the parser needs to control what PIDs it is processing.. This is the only way I can
think of that will work for both DVB and ATSC.. To port the AddPID/DelPID function would be
changed to just add another PID to your QMap (which is all that needs to be done for HDTVRecorder
anyway).  This is only needed by having the class outside of recorder/channel.

<snip>

> I like this. Right now I assemble the PES packets and process them, but
> then basically drop them on the floor. It would be good to pass them to
> a separate 'parser' class that handles them in another thread. All I
> suggest here is that this get a pointer and it reads the packet and
> copies it for processing in the other thread only if it needs to update
> the database.

The Parser class has objects to track what tables have been seen and not seen this is done with
the table_id_ext, table_id, and section number, so this is handled in the SI Parser class.. When
the SIParser has everything its looking for from a certain table it calls the DelPID signal so
that recorder/channel doesn't grab the tables anymore..  Unless you missed a certain table you
were looking for the recorder would most likely only parse each table once since they usually are
sent in order..  You need the tracker for if you miss a table (bad crc etc).

> The ScanXX functions should probably be in another class that uses
> HDTVRecorder and SIParser as tools. It could even be run withing the
> main application when nothing is recording to get updated tables.

Unfortunatly to build a Tracker object that will know what services its expecting in the EIT it
will need to parse the SDT (for DVB) or the TVCT/CVCT table (for ATSC).  For ATSC you also need to
know the PIDs that EIT-X are present on which requires examinig the MGT table.  This means the
FetchGuide method will have to have access to these tables and therefore they ought just be left
on 1 parsing class instead of having 2 classes that are so dependent on each other.  It has taken
me a long time to understand how to tell exactly when you are don pulling guide for DVB and what
is expected and from looking at the ATSC specs guide tracking is about the same..  So I can't see
any logic in seperating them (as much as it sounds like a good idea).

This brings up one thing I noticed last night. In DVB the EIT tables are in teh range of
0x4E-0x60, for different time increments.  For ATSC they all use the same table_id so guide
fetching for ATSC will either require that the PID the data originated from be passed along, or
each EIT-x table is processed one at a time.  I think we could get away with the 1 EIT at a time
since it looks like it will only take 20-30 seconds to get one complete EIT table parse and shove
it in the DB.  If this seems to be to slow this issue will have to be resolved.

> This sounds ugly. I would rather have HDTVRecorder create this class
> when it needs it. And have the "Scan" class start it when it needs it,
> etc. This requires less modification to the existing stuff, and also
> makes using it with multiple recorders easier (no need to keep track of
> multiple streams, just one per SIParser class).

If the class is in tv_rec and is only connected when recorder is open the I don't understand what
massive changes will need to be made.

If you have recorder create the class then its easy to do things that will break DVB usage of the
class that are easier.  Also see below Issacs thoughts..

The multiple recorders thing is slightly a pain, but can be handled by making 1 card responsible
for the tables on 1 videosource.  I.E. If you have 2 PCHDTV cards using the same videosource you
could just make the higher numbered card be responsible for pulling tables.  This could also be a
setting in the DB.

I am mostly thinking about this from the DVB angle where myth always keeps the card open, but you
will need access to the TS for ATSC to use the can program when myth is not recording.. It also
puts the table parsing class away from the Channel class which is responsible for tuning, and the
recording class which is responsible for Recording.. I had some discussions with Issac on IRC a
few months back about where to stick the classes and he didnt like them going in Channel or
Recorder and I can understand that..

The SIParser class would be sleeping most of the time, so it not like its going to parse tables
randomly and all the time.  It would probbably wake from time to time to check to see if its been
long enough since the last GuideFetch and maybe start fetching guide data again, but thats all i
can think of.

> Using Huffman encoded guide data would be nice. I got as far as putting
> the tables in a usable form, but never wanted to deal with debugging
> that beast.

I have some c code I got from some dvb forums that isn't pretty but it seems to work just fine on
DVB Huffman guide.  If it doesnt work for ATSC then the debugging will be a pain I am sure.  I am
not looking forward to cleaning it up either.

Did I answer all of your questions/thoughts?

Taylor



More information about the mythtv-dev mailing list