demuxer fails when corrupted PES packet advertises incorrect length

[tmm1]

I have a sample that looks like this:

$ ./astits-probe packets -i id3.ts
2022/01/21 12:07:04 Fetching packets...
2022/01/21 12:07:04 PKT: 0
2022/01/21 12:07:04   Continuity Counter: 4
2022/01/21 12:07:04   Payload Unit Start Indicator: true
2022/01/21 12:07:04   Has Payload: true
2022/01/21 12:07:04   Has Adaptation Field: false
2022/01/21 12:07:04   Transport Error Indicator: false
2022/01/21 12:07:04   Transport Priority: false
2022/01/21 12:07:04   Transport Scrambling Control: 0
2022/01/21 12:07:04 PKT: 480
2022/01/21 12:07:04   Continuity Counter: 4
2022/01/21 12:07:04   Payload Unit Start Indicator: true
2022/01/21 12:07:04   Has Payload: true
2022/01/21 12:07:04   Has Adaptation Field: false
2022/01/21 12:07:04   Transport Error Indicator: false
2022/01/21 12:07:04   Transport Priority: false
2022/01/21 12:07:04   Transport Scrambling Control: 0
2022/01/21 12:07:04 PKT: 502
2022/01/21 12:07:04   Continuity Counter: 13
2022/01/21 12:07:04   Payload Unit Start Indicator: true
2022/01/21 12:07:04   Has Payload: true
2022/01/21 12:07:04   Has Adaptation Field: false
2022/01/21 12:07:04   Transport Error Indicator: false
2022/01/21 12:07:04   Transport Priority: false
2022/01/21 12:07:04   Transport Scrambling Control: 0
2022/01/21 12:07:04 PKT: 502
2022/01/21 12:07:04   Continuity Counter: 14
2022/01/21 12:07:04   Payload Unit Start Indicator: true
2022/01/21 12:07:04   Has Payload: true
2022/01/21 12:07:04   Has Adaptation Field: true
2022/01/21 12:07:04   Transport Error Indicator: false
2022/01/21 12:07:04   Transport Priority: false
2022/01/21 12:07:04   Transport Scrambling Control: 0
2022/01/21 12:07:04   Adaptation Field: &{AdaptationExtensionField:<nil> DiscontinuityIndicator:false ElementaryStreamPriorityIndicator:false HasAdaptationExtensionField:false HasOPCR:false HasPCR:false HasTransportPrivateData:false HasSplicingCountdown:false Length:80 IsOneByteStuffing:false StuffingLength:79 OPCR:<nil> PCR:<nil> RandomAccessIndicator:false SpliceCountdown:0 TransportPrivateDataLength:0 TransportPrivateData:[]}
2022/01/21 12:07:04 PKT: 502
2022/01/21 12:07:04   Continuity Counter: 15
2022/01/21 12:07:04   Payload Unit Start Indicator: false
2022/01/21 12:07:04   Has Payload: true
2022/01/21 12:07:04   Has Adaptation Field: true
2022/01/21 12:07:04   Transport Error Indicator: false
2022/01/21 12:07:04   Transport Priority: false
2022/01/21 12:07:04   Transport Scrambling Control: 0
2022/01/21 12:07:04   Adaptation Field: &{AdaptationExtensionField:<nil> DiscontinuityIndicator:false ElementaryStreamPriorityIndicator:false HasAdaptationExtensionField:false HasOPCR:false HasPCR:false HasTransportPrivateData:false HasSplicingCountdown:false Length:82 IsOneByteStuffing:false StuffingLength:81 OPCR:<nil> PCR:<nil> RandomAccessIndicator:false SpliceCountdown:0 TransportPrivateDataLength:0 TransportPrivateData:[]}

which fails to demux with this error:

$ ./astits-probe data -i id3.ts
2022/01/21 12:09:22 Fetching data...
2022/01/21 12:09:22 astits: fetching data failed: astits: getting next data failed: astits: building new data failed: astits: parsing PES data failed: astits: fetching next bytes failed: astikit: slice length is 184, offset 285 is invalid

http://0x0.st/oo1F.bin

[tmm1]

I ran the same sample through ffmpeg, and noticed:

[mpegts @ 0x7fd14b815000] PES packet size mismatch
[mpegts @ 0x7fd14b815000] Packet corrupt (stream = 3, dts = 466149000).

Then I tried DVBInspector, and it appears the first packet advertises a length of 279 bytes, but the rest of the data never appears.

Ideally astits would detect and ignore this corruption.

[tmm1]

Ideally astits would detect and ignore this corruption.

If we implemented the CorruptedPacketHandler described in #22 (comment), these packets could be sent there instead of being silently ignored.