[mythtv] Re: [mythtv-commits] mythtv siparser changes....

[Stuart Auchterlonie]

On Wed, May 04, 2005 at 02:39:02PM -0400, Taylor Jacob wrote:
> Quoting Stuart Auchterlonie <stuarta at squashedfrog.net>:
> > I forgot to mention that there is a legitimate use for this patch.
> > BBC Parliment channel carries 1 video stream and 3 audio streams.
> > The video stream contains three smaller streams comprising of
> > 2x BBC News 24 Interactive and 1x BBC Parliment.
> > The 3 audio streams correspond to each video stream.
> 
> How does the xtraview patch fix this?  Are the audio streams mistyped as
> something else (Sorry it's been a while since I looked at it)..

Short Version: Yes.

Long Version:
Effectively they deliberately mistype the video and audio streams
and then use the mheg application to select the streams that are of
interest. The patch "fixes" this because it is classifying streams
as either audio or video (depending on the id byte it finds), rather 
than having an application say "I want PID x and y." I strongly
suspect the application would do exactly what the patch does. 

BBC Parliment is actually an mheg application that loads the
video out of a private stream, overlays the drawings from the
application (some text, some coloured boxes etc) and selects
the appropriate audio channel from another private stream.

BBC News interactive is similar. You already start off in the
interactive application, which then pulls in the video stream
then depending on which "video" you want it selects the
appropriate audio channel for that "video"

I say "video" because they have a headlines rolling loop and
another loop which the user can select between, when there is
actually only one video stream (as explained before...)

It seems to be a fairly common way of having a channel startup
with an interactive application.

> 
> > At the moment you have to use +/- to change the audio channel.
> 
> And how would you change this?  Play all 3 at once? :)

By finishing the rest of the interactive / mheg stuff. :-)

> 
> > At some point in the future these will work like they do on a
> > set top box, ie. The interactive stuff will all work, but that's
> > a work in progress. (I'm working on it, but it'll take a while..)
> 
> For True interactive services would you not need access to all PIDs in the
> transport stream?  What about rendering the interactive pages?
> 

It gets quite messy. Hmmm, where do I start....

Okay, you need access to SOME of the PIDs in the transport stream.
There are a number of different stream types that we are interested
in for interactive tv. The primary one is 0x0B, which is assigned
to DSM-CC. There are commonly several PIDs on one TS which are of
this type...

DSM-CC translates as the Object Carousel. All MHEG applications are
delivered through DSM-CC as well as get all of their data through it.
The object carousel collects and caches all the bits and pieces
that are transmitted, which includes all MHEG related stuff, 
firmware upgrades for STBs etc... The UK MHEG profile defines what
is mandatory, optional etc....

Anyway, the Object Carousel would need to reside in the backend
and be available to the frontend (This is a **MAJOR** TODO....) while
the MHEG rendering engine would need to be on the frontend.

While we are talking about major TODOs there will be a need for a
mechanism for the frontend to tell the backend which PIDs it wants.
This is because the interactive tv commonly needs to 'select' what
the viewer is interested in looking at.


Aren't you glad you opened that tin of worms.... :-/


Stuart