[mythtv] DSM-CC object carousel parser and storage patch for 0.18.1

[Stuart Auchterlonie]

On Fri, Sep 30, 2005 at 09:08:48PM -0400, Daniel Kristjansson wrote:
> On Sat, 2005-10-01 at 00:00 +0100, Stuart Auchterlonie wrote:
> > On Fri, Sep 23, 2005 at 11:39:09AM +0300, John Papaioannou wrote:
> > There are two method we could use to implement live tv.
> > 
> > 1. Decode the DSMCC on the backend, and then pass bits and pieces
> > through to the frontend for interpretation and display. This would
> > require the frontend to then talk to the backend to request data
> > out of the Object Carousel Cache. (This is how John's done it)
> > 
> > 2. Pass the whole stream through to the frontend and do the decoding
> > and caching at the frontend. This could be implemented as an avcodec
> > much like the subtitles are done at the moment.
> >
> > My favoured approach would be to implement #2. It should be cleaner
> > and easier to maintain in the long run.
> > Comments everyone?
> 
> Passing the whole stream to the frontend would be much cleaner,
> recorder wise. It also allow you to record one of the programs
> and do the interactive stuff later, right?

Have looked at this. If you let the DSMCC streams get recorded then
the size of the recordings blows out by an average of 30%. Not good.

The very nature of interactive TV doesn't really lend itself to "later".
Things like multiscreen news are "now", plus data pages with stuff like
the weather.

> 
> > We can still use all the parsing and caching stuff John's written,
> > we will just have to tie it all together in a different way.
> Yes, my main reason for wanting to integrate this sooner rather
> than later is that I don't want the code to become impossible
> to merge. But then once merged I would like to move it to 
> DVBStreamData & dvbtables. The xStreamData/xtables stuff was
> written with frontend decoding in mind.

I've been chasing those DVBStreamData changes for a while :-)

I already have patches that allow the passing of DSMCC streams
through to the frontend only when liveTV is being watched.
(That's where the stream ident patch came from :-)

If you want I can make a task in trac and put them in there.

> 
> Making #2 work with avlib would probably be a major PITA. But if
> you are up for it, it would be insanely cool. :)

It's going to be more like at the point where we go looking for a
codec (in avformatdecoder AFAIR), we go AHAH! DSMCC stream, hand it
off to our own lib to decode it. This lib is what we use John's
stuff for. All the glue stuff has to be redone anyway, and the lib
is pretty self contained.

So it's really a pseudo avcodec :-)

> 
> Also the xtables "parsers" are all C++ and avlib is all C. Since you
> would basically just be requesting certain streams I don't think it
> would be a huge headache, but I might be wrong. The "parsers" is in
> quotes because these are really just wrappers around the raw tables.
> They do the absolute minimum amount of parsing needed for quick
> extraction of data from the tables.

With the DSMCC streams we just want to identify them and then chuck
the whole stream at a decoder lib. The streams can and often are
co-dependent, so we feed all DSMCC streams into a single decoder
instance for it to build up a complete Object Carousel.


Stuart