m2ts: 0x47 byte in TC code confuses seeking

[AkarinVS]

The attached file is the first GOP (24 frames) of a certain BD.
bad.m2ts.zip

lsmas.LWLibavSource is unable decode the file at all, however other ffmpeg based players like mpv are able to play it back, and ffms2.Source can handle it as well.

In fact, lsmas is not even able to create an index for the file.

If we add another GOP, lsmas is able to create the index, but it fails to output the 23rd frame.
bad2.m2ts.zip

From the lwi file, it's clear ffmpeg is able to find all 48 frames, but lsmas can't decode the 23rd frame for some reason.

[AkarinVS]

Upon closer look, the file is interesting in that, the first video TS packet's TC code field contains another TS packet sync byte.

00000300  23 8F 47 80 47 50 11 10 00 00 01 E0 00 00 84 C0 #.G.GP..........
                ^^    ^^
00000310  0A 31 98 5F 7A A1 11 98 5F 5D 4D 00 00 00 01 09 .1._z..._]M.....
00000320  10 00 00 00 01 67 64 00 29 AC 1B 1A 50 1E 00 89 .....gd.)...P...
00000330  F9 70 11 00 00 03 03 E9 00 00 BB 80 E2 60 00 04 .p...........`..
00000340  C3 7A 00 00 72 70 E8 C4 B8 C4 C0 00 09 86 F4 00 .z..rp..........
00000350  00 E4 E1 D1 89 70 F8 E1 85 2C 00 00 00 01 68 EA .....p...,....h.
00000360  8C F2 3C 00 00 01 06 00 0A 9F 57 A0 00 01 F5 7A ..<.......W....z
00000370  00 00 40 80 00 00 01 06 01 0C 00 00 03 02 09 08 ..@.............
00000380  00 AB C2 10 00 00 08 80 00 00 01 06 06 01 C4 80 ................
00000390  00 00 01 65 88 80 00 40 00 00 67 39 FF F9 66 70 ...e...@..g9..fp
000003A0  16 7B C7 64 EC FA D1 4D F4 E3 A0 A7 8F 83 21 A6 .{.d...M......!.
000003B0  D9 77 9C 90 E0 2D 23 87 2C 2B F5 EE A6 B8 B6 8D .w...-#.,+......
000003C0  23 8F 4A CE 47 10 11 11 3A 1B 5F CA AF A2 FF 56 #.J.G...:._....V

Tracing of ffmpeg mpegts read_packet shows that it tries to read a packet at file offset 0x300, but nothing skips the 4-byte TC code field, as the first byte is not 0x47, it goes into a resynchronization process (mpegts_resync)
and curiously find the new sync point at 0x302.

I'm unable to figure out whether this is a ffmpeg bug or not (when avio_seek to pkt.pos returned from av_read_packet, and then reread the packet again, you won't get back the initial pkt), therefore, I will workaround it in lsmas.

[AkarinVS]

I think we also need to fix this for audio seeking as well. Reopen.

[ValeZAA]

Look related? https://patchwork.ffmpeg.org/project/ffmpeg/patch/D1KH1R9UF2X7.7AQL6DW1P6EV@gmail.com/

[ValeZAA]

Found another related issue

[ValeZAA]

So. It appears you are using ffmpeg API wrong. FFmpeg has no issues with these two files, it just searches again to the next 0x47 byte.

[ValeZAA]

Okay, ffmpeg actually has a bug in this file: https://0x0.st/XVJi.m2ts

after applying this patch https://patchwork.ffmpeg.org/project/ffmpeg/patch/D1KH1R9UF2X7.7AQL6DW1P6EV@gmail.com/

it can copy all video frames (the black ones).

ffmpeg -i XVJi.m2ts -c copy fafma.h264