[mythtv] [mythtv-commits] Ticket #2556: Bogus video streams in output PMT

[Stuart Auchterlonie]

On Tue, Oct 10, 2006 at 01:01:50PM +0100, David Matthews wrote:
> Stuart Auchterlonie wrote:
> > 
> >>From research I did when looking into DSMCC, I found that in the
> > private streams there were consistent component tags to tell me
> > what they really were. I can't remember the specific values at
> > the moment but will look it up when I get home. The above check
> > really should be written as.
> > 
> 
> It's certainly possible that this is what's causing the problem but the
> above won't work.  The reason for this code is to enable an MHEG
> application to select a different audio or video stream from that given
> in the PMT.  For example, sometimes there are different commentaries
> available on a sports match.  In a few cases, I think BBC Parliament is
> an example, there is no stream labelled as "video" in the PMT so without
> this there would be no video.
> 

I've had a look at bbc parliment's PMT to refresh my memory.

Audio streams that are available to the MHEG are identified by
stream type 0x6 (private) + 1st descriptor tag = 0xa (ISO639 lang desc)
This is in addition to any streams with an audio stream type.

The Video stream isn't specified as such, but it is the only stream
which meets the following condition
stream type = 0x6, 1st descriptor = 0x52 (stream id desc)

All the streams have a stream id descriptor, it's just that the
video streams in private sections are the only one with it listed
first.

It is this condition I was planning to attempt to identify.


> The MHEG application selects a stream by its component tag and calls
> SetAudioByComponentTag or SetVideoByComponentTag to do this.  The reason
> for using component tags is that PIDs could change as a result of
> remultiplexing so it isn't a good idea to have a PID in an MHEG app.  As
> far as I know there is no standard numbering for the tags.  They are
> just arbitrary values.  The streams, though, are marked as private data
> in the PMT.  The complicated part is to present the information to
> avformatdecoder so that SetAudioByComponentTag and
> SetVideoByComponentTag will work.  The only way I could see to do this
> was to try to predict which could be audio and which video within
> mpegts.c and then include them in the available streams.  It would
> certainly be better to drive this from the other end and only treat a
> stream as, say, audio, once SetAudioByComponentTag was called.  I just
> couldn't see how to do that.
> 
> If this is the source of the problem it could be that the problem is the
> selection of the default video and audio streams is wrong.
> 

The alternative is to leave the streams identified as private data
and then pick up the streams as needed.


Stuart