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

lance.lmwang at gmail.com lance.lmwang at gmail.com
Tue May 19 13:53:04 EEST 2020


On Sun, May 17, 2020 at 02:41:18PM +0200, Marton Balint wrote:
> 
> 
> 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.

I have send it the sample to you privately, if you haven't got it, please let me
know.

> 
> [...]
> 
> > 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.

You can tried with my pcap sample, please update the pcap mac info and use
tcpreplay to get the udp stream.

> 
> > 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?

Sorry, I'm miss it before.  I have tried with the patch, you can reproduce with
my sample with offline file, below is the log:

[mpegts @ 0x49a9940] reanalyze: stat: 4, stat[0]: 0, stat[1]: 1, stat[2]: 0, pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 5, stat[0]: 0, stat[1]: 2, stat[2]: 0, pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 6, stat[0]: 0, stat[1]: 3, stat[2]: 0, pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 7, stat[0]: 0, stat[1]: 3, stat[2]: 0, pos: 240
[mpegts @ 0x49a9940] reanalyze: stat: 8, stat[0]: 0, stat[1]: 3, stat[2]: 0, pos: 195
[mpegts @ 0x49a9940] reanalyze: stat: 9, stat[0]: 0, stat[1]: 3, stat[2]: 0, pos: 195
[mpegts @ 0x49a9940] reanalyze: stat: 10, stat[0]: 0, stat[1]: 3, stat[2]: 0, pos: 298
[mpegts @ 0x49a9940] Packet corrupt (stream = 0, dts = 446069).
[mpegts @ 0x49a9940] reanalyze: stat: 11, stat[0]: 0, stat[1]: 4, stat[2]: 0, pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 1, stat[0]: 0, stat[1]: 1, stat[2]: 0, pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 2, stat[0]: 0, stat[1]: 2, stat[2]: 0, pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 3, stat[0]: 0, stat[1]: 2, stat[2]: 0, pos: 240
[mpegts @ 0x49a9940] reanalyze: stat: 4, stat[0]: 0, stat[1]: 2, stat[2]: 0, pos: 312


> 
> Thanks,
> Marton

> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 0833d62ea5..921a7ae2db 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2774,11 +2774,6 @@ static int handle_packet(MpegTSContext *ts, const uint8_t *packet, int64_t pos)
>      if (p >= p_end || !has_payload)
>          return 0;
>  
> -    if (pos >= 0) {
> -        av_assert0(pos >= TS_PACKET_SIZE);
> -        ts->pos47_full = pos - TS_PACKET_SIZE;
> -    }
> -
>      if (tss->type == MPEGTS_SECTION) {
>          if (is_start) {
>              /* pointer field present */
> @@ -2926,6 +2921,8 @@ static int read_packet(AVFormatContext *s, uint8_t *buf, int raw_packet_size,
>              else
>                  continue;
>          } else {
> +            MpegTSContext *ts = s->priv_data;
> +            ts->pos47_full = avio_tell(pb) - TS_PACKET_SIZE;
>              break;
>          }
>      }

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


-- 
Thanks,
Limin Wang


More information about the ffmpeg-devel mailing list