Solve the the issue of non-DVB transport stream(TS) which using the PID, 0x10~0x1F, as the PIDs of the video/audio streams of program

[jlnieh]

Scenario

We got the sample transport stream from IPTV source, which using the PID 0x10 as the program PID, 0x11 as the video stream PID, and 0x12 as the audio stream PID. The transport stream would cause the PSI checksum error, while we tried to use the demux to get NextData() of the stream.

ISO Standard

According to the Table 2-3 -- PID table of the standard ISO/IEC 13818-1:2007, the PID range 0x0010~0x1FFE may be assigned as network PID, program map PID, elementary_PID, or for other purposes.

Changes

1. Use existed struct programMap to setup the locks of the PIDs which used in the program already
2. While demux parseData(), use the locks to avoid the used PIDs of elementary streams to be identified as PSI table.

[asticode]

Which type of content are you demuxing (you say non-DVB, but what's the exact type?) and how can we identify it as non-DVB?

[jlnieh]

Which type of content are you demuxing (you say non-DVB, but what's the exact type?) and how can we identify it as non-DVB?

I believe it is following the ATSC standard or just the IPTV transport stream which does not use those DVB metadata, NIT or SDT. It is not easy to identify the transport stream is following which standard, since both DVB and ATSC standards have their own specific PIDs for their system tables . I would suggest

1. add one more option to NewDemuxer to let user/developer to choose the TS standard, like the tool, streamXpert, OR
2. in this case, we could demux the transport stream based on the PAT and known PMT to identify those PIDs, 0x0010~0x001F, is used or locked by one known program/service, OR
3. in parsePSIData(), if we got the table ID, which is not reasonable, for example the table ID 0x00 is coming with the non-zero PID, we should stop and fall back to identify this PID is non-PSI and may parse it as the PES or some kind of private data in the following packets.

[asticode]

OK thanks for the clarification 👍

In that case I would rather you add a new elementaryStreamMap, similar to programMap but separated from it. You can use the same function names.

[jlnieh]

Updated to add a new elementaryStreamMap. Please check.