[FFmpeg-devel] [PATCH] avformat/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size

[Marton Balint]

On Sun, 17 May 2020, lance.lmwang at gmail.com wrote:

> On Sat, May 16, 2020 at 07:36:45PM +0200, Marton Balint wrote:
>> 
>> 
>> On Sat, 16 May 2020, lance.lmwang at gmail.com wrote:
>> 
>> > On Sat, May 16, 2020 at 11:44:01AM +0200, Marton Balint wrote:
>> > > 
>> > > 
>> > > On Sat, 16 May 2020, lance.lmwang at gmail.com wrote:
>> > > 
>> > > I suggest you capture the input, so this issue can be properly reproduced
>> > > and share it. It may even make sense to create a fate test from it.
>> > 
>> > Have tried, the issue can't be reproduced by capture offset file. I guess it's
>> > caused by live stream seek isn't same as off line file.
>> 
>> If that is the case then you can override the seekability of files by using
>> -seekable 0 option. Alternatively you might find some other means to replay
>> the recorded ts, anyhow this should be reproduced, because I have a feeling
>> we don't have the whole picture of what is going on.
>
> I have spend more time to investigate it, I have try to capture a pcap file to
> reproduce the issue, with tcprelay, it can be reproduced every time, however
> if export to ts, I failed to reproduce it.

Great. Can you share the pcap file? You can may send it to me privately if 
you don't want it to be made public.

[...]

> Thanks for the advices, I spend more time to investigate and  try to fix it in the
> resync logic, with more debug info, I notice the old reanalyze() has one drawback,
> the pos isn't one of 188/192/204, so it'll cause the stat will reset all stats
> ahead of one of stats[i] which cause normal 188 failed to detected anymore. I
> think it's better to return if pos isn't one of 188/192/204, it'll fix my issue
> by testing, please help to review whether it's reasonable or not.

I am not sure yet.

> the log which explain why it failed to detect back to 188:
>
> [mpegts @ 0x3ef0180] reanalyze: stat: 1, stat[0]: 1, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 188
> [mpegts @ 0x3ef0180] reanalyze: stat: 2, stat[0]: 2, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 188
> [mpegts @ 0x3ef0180] reanalyze: stat: 3, stat[0]: 3, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 188
> [mpegts @ 0x3ef0180] reanalyze: stat: 4, stat[0]: 4, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 188
> [mpegts @ 0x3ef0180] reanalyze: stat: 5, stat[0]: 4, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 564
> [mpegts @ 0x3ef0180] reanalyze: stat: 6, stat[0]: 5, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 188
> [mpegts @ 0x3ef0180] reanalyze: stat: 7, stat[0]: 6, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 188
> [mpegts @ 0x3ef0180] reanalyze: stat: 8, stat[0]: 6, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 376
> [mpegts @ 0x3ef0180] reanalyze: stat: 9, stat[0]: 7, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 188
> [mpegts @ 0x3ef0180] reanalyze: stat: 10, stat[0]: 7, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 474
> [mpegts @ 0x3ef0180] reanalyze: stat: 0, stat[0]: 0, stat[1]: 0, stat[2]: 0, raw_packet_size: 192, pos: 752

pos as a multiple of 188 and not 188 is very suspicious, and it might be 
because pos47_full is only updated if the packet has a payload. Can you 
try the attached patch and see if it makes a difference?

Thanks,
Marton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pos47.patch
Type: text/x-patch
Size: 871 bytes
Desc: 
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200517/06df2a30/attachment.bin>