Opened 15 years ago
Closed 15 years ago
#2556 closed defect (fixed)
Bogus video streams in output PMT
Reported by: | Stuart Auchterlonie | Owned by: | Stuart Auchterlonie |
---|---|---|---|
Priority: | minor | Milestone: | 0.21 |
Component: | dvb | Version: | 0.20 |
Severity: | medium | Keywords: | PMT dvb |
Cc: | Ticket locked: | no |
Description
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.
Attachments (1)
Change History (6)
comment:1 Changed 15 years ago by
Changed 15 years ago by
Attachment: | ticket2556-neil-murphy-stream-select.diff added |
---|
Neil Murphey's patch to select the video stream by highest component tag
comment:2 Changed 15 years ago by
Status: | new → assigned |
---|
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)
comment:3 Changed 15 years ago by
comment:4 Changed 15 years ago by
comment:5 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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
(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.