On Sun, 17 May 2020, lance.lmw...@gmail.com wrote:
On Sat, May 16, 2020 at 07:36:45PM +0200, Marton Balint wrote:
On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
> On Sat, May 16, 2020 at 11:44:01AM +0200, Marton Balint wrote:
> >
> >
> > On Sat, 16 May 2020, lance.lmw...@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
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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
