Bogus video streams in output PMT

[Stuart Auchterlonie]

Broadcasts from certain transmitters in the UK of Channel 4 are triggering myth to place bogus video streams in the output PMT. This later causes myth to barf on these recordings.

Some analysis of the sample recording provided.

ffmpeg:

Input #0, mpegts, from 'ChannelFourBug.mpg':
  Duration: 00:00:03.7, start: 41021.819689, bitrate: 3453 kb/s
  Stream #0.0[0x230], 25.00 fps(r): Video: mpeg2video, yuv420p, 704x576, 10000
+kb/s
  Stream #0.1[0x231](eng): Audio: mp2, 48000 Hz, stereo, 192 kb/s
  Stream #0.2[0x232](eng): Audio: mp2, 48000 Hz, mono, 64 kb/s
  Stream #0.3[0x233](eng): Subtitle: dvbsub
  Stream #0.4[0x4ae], 90000.00 fps(r): Video: mpeg2video
  Stream #0.5[0x40a], 90000.00 fps(r): Video: mpeg2video

dvbsnoop:

dvbsnoop -if ChannelFourBug.mpg -nph -pd 7 -s ts | grep ^PID | sort | uniq -c
      5 PID: 0 (0x0000)  [= Programm Association Table]
      7 PID: 2000 (0x07d0)  [= NIT, PMT or Elementary PID, etc.]
   1805 PID: 2201 (0x0899)  [= NIT, PMT or Elementary PID, etc.]
     11 PID: 2203 (0x089b)  [= NIT, PMT or Elementary PID, etc.]
    105 PID: 2307 (0x0903)  [= NIT, PMT or Elementary PID, etc.]
      5 PID: 300 (0x012c)  [= NIT, PMT or Elementary PID, etc.]
   6139 PID: 560 (0x0230)  [= NIT, PMT or Elementary PID, etc.]
    425 PID: 561 (0x0231)  [= NIT, PMT or Elementary PID, etc.]
    149 PID: 562 (0x0232)  [= NIT, PMT or Elementary PID, etc.]
      1 PID: 563 (0x0233)  [= NIT, PMT or Elementary PID, etc.]

PID 0x0 = PAT
PID 0x7d0, 0x899, 0x89b = DSMCC
PID 0x903 = PCR
PID 0x12c = PMT
PID 0x230 = Video
PID 0x231, 0x232 = Audio
PID 0x233 = Data (subtitles)

Analysis of the output PMT yields the following streams

• PID 0x230 Video
• PID 0x231 Audio
• PID 0x232 Audio
• PID 0x233 Data (subtitle)
• PID 0x4ae Bogus (marked as type 0x2, video)
• PID 0x7d0 DSMCC
• PID 0x40d Bogus (marked as type 0x2, video)
• PID 0x899 DSMCC
• PID 0x89b DSMCC

The invalid streams (0x4ae & 0x40d) are only found in the output PMT, not in the recording itself.

[Stuart Auchterlonie]

(In [11510]) Refs #2556. Tightens the criteria for a private stream to be declared as a video stream.

Now a private stream is considered to be a video stream only if the first descriptor is the component tag (0x52)

The component tag isn't actually an indicator of a video stream, as it's present on all of the streams. Normally it is the last descriptor on a stream, with the other descriptors identifying the actual content.

The streams we are now declaring as video stream have the component descriptor as the first, and generally only descriptor.

Previously any stream marked as a private stream (type 0x6) would be marked as a video stream if it could not be identified as anything else.

This should allow people having trouble with Channel 4 on various muxes to be able make recordings without bogus streams.

[Stuart Auchterlonie]

Neil Murphey's patch to select the video stream by highest component tag

[Stuart Auchterlonie]

From the log Neil sent me, it seems that there are 2 streams of type 0x128 listed in the PMT, which mythtv interprets as OpenCable? Video streams.

 Stream #0 pid(0x230) type(video-mpeg2  0x2)
  Maximum Bitrate Descriptor (0xe) length(3)
  Video Descriptor (0x2) length(3)
  Unknown(6) Descriptor (0x6) length(1)
  Stream Identifier Descriptor (0x52) length(1)
 Stream #1 pid(0x231) type(audio-mp2-layer[1,2,3]  0x4)
  Maximum Bitrate Descriptor (0xe) length(3)
  Audio Descriptor (0x3) length(1)
  ISO-639 Language: code(eng) canonical(eng) eng(English)
  Stream Identifier Descriptor (0x52) length(1)
 Stream #2 pid(0x232) type(audio-mp2-layer[1,2,3]  0x4)
  Maximum Bitrate Descriptor (0xe) length(3)   Audio Descriptor (0x3) length(1)
  ISO-639 Language: code(eng) canonical(eng) eng(English)
  Stream Identifier Descriptor (0x52) length(1)
 Stream #3 pid(0x233) type(private-data  0x6)
  Maximum Bitrate Descriptor (0xe) length(3)
  Subtitling Descriptor (0x59) length(8)
 Stream #4 pid(0x4ae) type(video-opencable  0x128)
 Stream #5 pid(0x7d0) type(dsmcc-b std data  0x11)
  Maximum Bitrate Descriptor (0xe) length(3)
  Unknown(19) Descriptor (0x13) length(5)
  Data Broadcast Identifier Descriptor (0x66) length(6)
  Stream Identifier Descriptor (0x52) length(1)
 Stream #6 pid(0x40a) type(video-opencable  0x128)
 Stream #7 pid(0x899) type(dsmcc-b std data  0x11)
  Maximum Bitrate Descriptor (0xe) length(3)
  Stream Identifier Descriptor (0x52) length(1)
 Stream #8 pid(0x89b) type(dsmcc-b std data  0x11)
  Maximum Bitrate Descriptor (0xe) length(3)
  Stream Identifier Descriptor (0x52) length(1)

[Stuart Auchterlonie]

(In [11549]) Refs #2556. Select the first video stream found in the PMT. This allows allows the people with weird broadcasts to function, without inhibiting the functionality of Interactve TV (MHEG)

[Stuart Auchterlonie]

(In [11550]) Refs #2556. Select the first video stream found in the PMT. This allows allows the people with weird broadcasts to function, without inhibiting the functionality of Interactve TV (MHEG)

Backported from head.

[Stuart Auchterlonie]

With these fixes the problem the user is seeing has been worked around.

The underlying issue of the correct handling of OpenCable? streams will be look at under #2584