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

[David Matthews]

Stuart Auchterlonie wrote:
> On Tue, Oct 10, 2006 at 02:39:08PM +1000, Andrew Dennison wrote:
> 
>>On 10/10/06, Daniel Kristjansson <danielk at cuymedia.net> wrote:
>>
>>>On Mon, 2006-10-09 at 14:21 +0000, MythTV wrote:
>>>
>>>>#2556: Bogus video streams in output PMT
>>>> The invalid streams (0x4ae & 0x40d) are only found
>>>> in the output PMT, not in the recording itself.
>>>
>>>Perhaps something in the DVBRadio & MHEG dummy video support?
>>
> Digging into this a bit more, from [10458] we added
> 
> {{{
> if ((dvbci.component_tag >= 0) && (stream_type == STREAM_TYPE_PRIVATE_DATA))
> {
>     /* Audio and video are sometimes encoded in private streams labelled with a component tag. */
>     if (dvbci.language[0])
>         stream_type = STREAM_TYPE_AUDIO_MPEG2;
>     else
>         stream_type = STREAM_TYPE_VIDEO_MPEG2;
> }
> }}}
> 
> This will effectivly classify any data stream as a Video stream
> if it is in a private data stream and is not an audio stream.
> 
>>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.
> 
> {{{
> if ((dvbci.component_tag == AUDIO_TAG) && (stream_type == STREAM_TYPE_PRIVATE_DATA))
>     stream_type = STREAM_TYPE_AUDIO_MPEG2;
> 
> if ((dvbci.component_tag == VIDEO_TAG) && (stream_type == STREAM_TYPE_PRIVATE_DATA))
>     stream_type = STREAM_TYPE_VIDEO_MPEG2;
> }}}
> 
> as per other checks. I'll look into this when I get home.
> 

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.

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.

David.