Opened 3 years ago

Last modified 3 years ago

#4221 new defect

Teletext streams from DVB-S recording (mis)identified as MP3 audio with 0 channels / unknown stream

Reported by: olifre Owned by:
Priority: normal Component: undetermined
Version: 2.5.2 Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

When trying to decode a DVB-S recording with teletext streams in it, these streams are mistaken as e.g.

  • Stream #0:1[0x68], 127, 1/90000: Audio: mp3, 0 channels, s16p
  • Stream #0:5[0x69], 2, 1/90000: Unknown: none

This is with ffmpeg 2.5.2.

Full ffprobe-report created with
% ffprobe sample.ts -report
and sample.ts are attached.

Some more details about the streams:

  • Stream #0:0[0x65]: video (correct)
  • Stream #0:1[0x68]: First teletext PID, misrecognized as MP3 with 0 ch.
  • Stream #0:2[0x6a]: real audio (AC3)
  • Stream #0:3[0x67]: real audio (mp2)
  • Stream #0:4[0x66]: real audio (mp2)
  • Stream #0:5[0x69]: Should be second teletext PID, recognized as "unknown"

Attachments (3)

ffprobe-20150104-044059.log (12.8 KB) - added by olifre 3 years ago.
ffprobe log
ffprobe-20150104-153725-sample2.log (40.9 KB) - added by olifre 3 years ago.
ffprobe for second sample (containing only teletext-pids)
sample2.ts (1.0 MB) - added by olifre 3 years ago.
second sample (only teletext-pids recorded)

Download all attachments as: .zip

Change History (8)

Changed 3 years ago by olifre

ffprobe log

comment:1 Changed 3 years ago by olifre

I actually uploaded the sample.ts as teletext-streams-misrecognized.ts to the ftp, adding a teletext-streams-misrecognized.txt linking here. Much smaller files than the few MB sized one exhibit much less teletext data in comparison to video / audio.

Changed 3 years ago by olifre

ffprobe for second sample (containing only teletext-pids)

Changed 3 years ago by olifre

second sample (only teletext-pids recorded)

comment:2 Changed 3 years ago by olifre

I figured it would probably be more useful to only have the streams in question to have a larger sample of the interesting streams.
Patching mpv (which I use for recording) I did a recording of the same program, but only selecting the "0x68" and "0x69" streams.
The file is attached as sample2.ts, with corresponding full ffprobe report.

comment:3 Changed 3 years ago by kierank

sample2.ts has no PMT so it's impossible without hacks to decode.

comment:4 Changed 3 years ago by olifre

Thanks kierank for your quick reply!

This is indeed the case. I just checked with szap-s2 recording the same channel with PAT, PMT and teletext - ffprobe works fine then, while without PMT, the detection fails.

Still, without PMT, video and audio channels are detected just fine, only teletext gets broken.

I will try to implement PMT-PID extraction from PAT into mpv, this should fix it also there.

Does this invalidate the bug, as the issue can be resolved by adding the PMT (then you can just close it), or should it be left as a wish to have a clearer error message ("PMT missing => decoding may fail")?

Thanks again!

comment:5 Changed 3 years ago by olifre

I already saw work on the git HEAD on this - I can confirm the subtitle-detection now appears to work even without PMT (I added the PMT to mpv by now, so it also works in a clean way). The teletext-detection does not, but that is not really too useful, anyways.

As PMT and PAT are now there in the TS, I encountered another somewhat related issue described in #4228.

Note: See TracTickets for help on using tickets.