Bug in TsPacketFactory.GetTsPacketsFromData() about tsdecoder

[lewk2]

After too long, I found some time to come back to this (another paying project allowed me to put some time in here). I also needed the fix myself, although I kinda forgot about the issue specifics until I hit the problem last night and then fixed the bug myself.

While I was there, I strengthened unit tests, updated the unit tests project, and optimized some needless memory copying in certain conditions.

NuGet is now has version 3.0.131 of the library with these changes - although I'm afraid that this will render the pull-request obsolete (to retain consistency too, I do not call 'sizeof(byte)' because if the size of a byte is not always 1 byte for this library then the entire library will just implode :)

I will close this issue (just tested against NuGet edition my side) and close the PR - many thanks for caring, and sorry I was so quiet.

[replaysMike]

here's the data, first 4 bytes 47 41 00 30 are the TsPacket header and the adaptation field header is 07 50, so 7 is the length. However, if you see the data in bold it's actually 8 bytes, which puts the PES start code next at 00 00 01. The code currently doesn't account for that extra 0x00 which is either incorrect adaptation field length or a padding byte.

47 41 00 30 07 50 00 00 00 00 FE 00 00 00 01 E0 00 00 80 80 05 21 00 01 00 03 00 00 00 01 09 F0 00 00 00 01 67 64 00 2A AC 2C 6A 81 E0 08 9F 97 01 6E 02 02 02 80 00 00 03 00 80 00 00 1E 42 00 00 00 01 68 EE 3C B0 00 00 00 01 06 E5 01 E1 80 00 00 00 01 65 B8 00 00 08 B5 A0 00 01 7F 6D 0B 52 D2 A2 D1 EF 11 EC FF C5 4A EC 63 C1 47 9F A7 78 36 7B 1F 30 0A 24 C8 0C 35 2D 96 BD BC 97 B5 E0 AA 40 A3 9F 3E 4A 42 C2 9B D0 43 63 6F 82 CD 94 2C 3C 7F A2 C1 A4 29 DE 73 80 5E BF 1C 1B E9 73 0B F5 FE FD BC 92 ED 11 67 8C 94 63 AB CE 40 4C 5C D2 68 DC 2D 91 CE 19 2E BB 98

If I'm wrong here, please someone correct me. My fix so far only fixes this value, other adjustments may need to be made to the header length still and I'm working on that

[wingman-jr-addon]

I can concur this is a real problem and I think @replaysMike has the correct solution (thanks @replaysMike !). If I read an FFmpeg-produced video stream and have a frame that has both AdaptationFieldExists=true and then follows that up with PUSI=true, the PesHeader does not parse correctly because it is offset by 1. I can verify this is the case by using DVB Inspector.

Here's the full packet:

Data:
         0001 0203 0405 0607 0809 0A0B 0C0D 0E0F 0123456789ABCDEF
0x000000 4740 4130 0750 09A8 678C 7E00 0000 01E0 [email protected].~.....
0x000010 0000 8080 0521 4D47 8A61 0000 0001 09F0 .....!MG.a......
0x000020 0000 0001 6742 C00A DA7E 2223 0110 0000 ....gB...~"#....
0x000030 0300 1000 0003 00A0 F122 6A00 0000 0168 ........."j....h
0x000040 CE0F C800 0001 0605 FFFF 40DC 45E9 BDE6 [email protected]...
0x000050 D948 B796 2CD8 20D9 23EE EF78 3236 3420 .H..,. .#..x264 
0x000060 2D20 636F 7265 2031 3539 202D 2048 2E32 - core 159 - H.2
0x000070 3634 2F4D 5045 472D 3420 4156 4320 636F 64/MPEG-4 AVC co
0x000080 6465 6320 2D20 436F 7079 6C65 6674 2032 dec - Copyleft 2
0x000090 3030 332D 3230 3139 202D 2068 7474 703A 003-2019 - http:
0x0000a0 2F2F 7777 772E 7669 6465 6F6C 616E 2E6F //www.videolan.o
0x0000b0 7267 2F78 3236 342E 6874 6D6C           rg/x264.html

DVB Inspector readout looks like this:

[wingman-jr-addon]

Thanks so much @lewk2 !