[mythtv] SI/PSIP Parser

[Daniel Thor Kristjansson]

On Tue, 21 Sep 2004, Taylor Jacob wrote:

]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.


]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.


]In the recorder loop you will need to check for any of the added pids,
]and if its one of them pass the data into a TS2PES class I wrote for
]organizing the data into a section table, and when this gets a complete
]table send the signal to the siparser which will process it..  I will
]probbably make all the processing threaded so it wont slow down the
]dvbrecorder. This isnt such a big deal for DVB but the heavy lifting
]should be done in a thread anyway..

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 SIParser class will have some generic methods called
]ScanServices(), ScanTransports(), FetchGuide() which will determine if
]its an ATSC or DVB source (this can be force of course) and will call
]the right functions.. The ScanServices for ATSC could just parse the

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.


]The SIParser class will be created in tv_rec.cpp and will be connected
]to what slots it needs to communicate.. I guess the hdtvrecorder.cpp
]will either need to be left running all the time just not writing to
]the ringbuffer, or make another class that just handles the pid control
]so you can do guide scanning while not recording..

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 this doesnt make sense give me a few days and I will send you what
]ive got and you can take a look.. I also have some huffmann code that I
]will be adding into the guide parser stuff so you should be able to use
]huffmann encoded guide data (dont know if anyone uses it or not).. I
]can probbably test some of the ATSC parsing with PBS, but their guide
]only says "PBS SD Event" with a length of 3 hours, so it won't be a
]real robust test.

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.


]Hopefully I haven't stepped on anything you have done too badly but the
]more I looked into the ATSC tables it seemed stupid to not put them
]together, and since ATSC over DVB exists it really should be combined..

I agree, I think the problem so far has been that no one person has both
around here.

-- Daniel