TransEdit: unable to detect second section of SDT

[oleq]

I've ran across some issue, which might be interesting to look at.

TransEdit is unable to detect the second section of SDT table in some DVB-T stream.

 

I'm attaching a sample (full TS).

 

https://www13.zippyshare.com/v/FwOaHvJZ/file.html

 

This is resulting in missing last 3 services names.

 

Sections length seems to be OK, also CRC32 is fine. Maybe a bit untypical is that second section is starting in the middle of the packet, but I think that this shouldn't be an issue (?)

[Griga]

The link yields a "403 Forbidden" error message.

 

[oleq]

Oops, sorry, reuploaded: https://potylica.pl/2021-03-28_2159_SDT.zip

[Griga]

Ok, I can see the problem. LastSectionNumber is 1 in the SDT, as the Analyzer -> Table Stats function indicates, so there should be two SDT sections, one with SectionNumber = 0 and one with SectionNumber = 1.

 

However, even with a manual search by using the Analyzer -> Hex View of the SDT packets I can't find a section with SectionNumber = 1. So it is simply missing, as far as I can see. It looks like the broadcaster's fault...

 

[oleq]

Thanks for verification and help

 

The issue is that section 1 is present, it's a little bit hidden, but please look at the screenshot - it will help.

 

Directly after "Rock Radio" name there's a CRC32 of section 0 (marked with red, value is correct) and section 1 is starting (marked with blue) directly right after.

 

https://i.ibb.co/TKjZ56k/section1.png

Edited March 29, 2021 by oleq

[Griga]

vor 42 Minuten schrieb oleq:

The issue is that section 1 is present, it's a little bit hidden, but please look at the screenshot

 

It seems to present, but it doesn't comply to the basic ISO/IEC 13818-1 specifications for transport streams. See section 2.4.4.2, Semantics definition of fields in pointer syntax:

 

Zitat

pointer_field – This is an 8-bit field whose value shall be the number of bytes, immediately following the pointer_field until the first byte of the first section that is present in the payload of the Transport Stream packet (so a value of 0x00 in the pointer_field indicates that the section starts immediately after the pointer_field). When at least one section begins in a given Transport Stream packet, then the payload_unit_start_indicator (refer to 2.4.3.2) shall be set to 1 and the first byte  of  the  payload  of  that  Transport  Stream  packet  shall  contain  the  pointer.

 

Your screenshot shows, that neither the payload_unit_start_indicator is set in the packet where the sections starts, nor a pointer field (following the 4 TS header bytes and pointing to the beginning of the section) is present. It's a proprietary (or simply wrong) way of inserting the second section. That's why TransEdit is not able to find it.

 

[oleq]

Thanks, wow, it's a tricky issue on the broadcasters side.

Thanks for your explaination, now I understand the problem