[mpegts] Only auto-register PAT PIDs and validate the PSI section header - PlutoTv fails on ads for 21.5.21.1#2083
Conversation
Commit 59fd1b3 ("Accept any PID number not only PAT with PID 0") made ProcessTSPacket auto-register any first-seen PID as a PSI packet when its payload bytes matched table_id 0x00 (PAT) or 0x02 (PMT). The PMT case is both redundant and unsafe: PMT PIDs are always registered by the PAT parser (parse_ts_psi, table_id 0x00) before any PMT packet arrives, so a valid PMT PID never reaches this branch. The only PID that does is a non-PSI PID whose payload happens to begin with table_id 0x02 -- common on discontinuous /corrupt live HLS-TS. Such a PID is then misparsed as a PMT, triggers a spurious program change, corrupts the demux state, and crashes on the next TSResync() in AP4_ByteStream::Read (SIGSEGV). Fix: auto-register only when the PID carries the start of a *PAT* section, and validate the section header (reserved bits set, sane section_length) before trusting it. This preserves the original intent (accept a PAT not on PID 0) while removing the crash. No regression observed on DASH or well-formed TS. Author: Wagner Brito <wagnerbrito@gmail.com>
|
Decision: APPROVE Issues: none Evidence:
Review Details
|
|
Unfortunately here you fix one thing but are breaking the previous attempt to make work the other video I’m not saying that mentioned commit was right, because i’m not expert on TS demuxer side note: we works on master branch "Piers", not Omega |
Understood. I will try to fix the other issue you mentioned. For piers I will install that version to test it. Right now I am using librelec 12.2 which runs Omega. Thank you |
Create the PR: #2084 |
Description
Commit 59fd1b3 ("Accept any PID number not only PAT with PID 0") made ProcessTSPacket auto-register any first-seen PID as a PSI packet when its payload bytes matched table_id 0x00 (PAT) or 0x02 (PMT).
Motivation and context
The PMT case is both redundant and unsafe: PMT PIDs are always registered by the PAT parser (parse_ts_psi, table_id 0x00) before any PMT packet arrives, so a valid PMT PID never reaches this branch. The only PID that does is a non-PSI PID whose payload happens to begin with table_id 0x02 -- common on discontinuous /corrupt live HLS-TS. Such a PID is then misparsed as a PMT, triggers a spurious program change, corrupts the demux state, and crashes on the next TSResync() in AP4_ByteStream::Read (SIGSEGV).
Fix: auto-register only when the PID carries the start of a PAT section, and validate the section header (reserved bits set, sane section_length) before trusting it. This preserves the original intent (accept a PAT not on PID 0) while removing the crash. No regression observed on DASH or well-formed TS.
############### LOG FILE ################
14:00:42.107 T:418559 inputstream.adaptive: [AS-16] Download finished: .../hls/stream-13259.ts (2223852 byte)
14:00:42.108 T:418559 CurlFile::Open - https://redebrasil.nuvemplay.live/hls/stream-13260.ts
14:00:42.255 T:1258 inputstream.adaptive: Download finished: .../hls/stream.m3u8 (438 byte)
14:00:42.256 T:1258 inputstream.adaptive: Manifest saved to: .../manifest_1782493242_child-video.txt
14:00:42.376 T:1170 warning: ActiveAE - large audio sync error: -1007.649115
14:00:42.426 T:1170 warning: ActiveAE - large audio sync error: -1006.661655
... (≈20 consecutive ~-1007 ms audio-sync warnings) ...
14:00:42.626 T:418559 inputstream.adaptive: [AS-16] Download finished: .../hls/stream-13260.ts (2137936 byte)
14:00:42.628 T:418559 CurlFile::Open - https://redebrasil.nuvemplay.live/hls/stream-13261.ts
...
14:00:43.126 T:1170 ActiveAE::SyncStream - average error -989.564397 above threshold of 200.000000
14:00:43.379 T:1170 ActiveAE::SyncStream - average error -0.017912 below threshold of 30.000000
14:00:43.536 T:418994 inputstream.adaptive: IsLastSegment: Check for last segment (period end PTS: 6000, segment end PTS: 6000)
############### END LOG FILE ################
How has this been tested?
A custom version with those changes was built and installed on Kodi.
The same stream that was failing after a few minutes, every time, now run for more than 24h without crashing. Same thing was happening with PlutoTv when ads were playing, it crashed every time, but now works fine.
Screenshots (if appropriate):
Types of change
Checklist: