[FFmpeg-devel] [PATCH] avformat/mpegts: fix resync logic stuck in 192 bytes

Limin Wang lance.lmwang at gmail.com
Wed May 20 12:37:30 EEST 2020


On Wed, May 20, 2020 at 08:26:37AM +0200, Marton Balint wrote:
> 
> 
> On Wed, 20 May 2020, lance.lmwang at gmail.com wrote:
> 
> >On Tue, May 19, 2020 at 09:06:59PM +0200, Marton Balint wrote:
> >>pos47_full is not updated for every packet, and for unseekable inputs the
> >>resync logic might simply skip some 0x47 sync bytes. In order to detect these
> >>let's check for modulo instead of exact value.
> >
> >Before modifying and returning directly, I considered whether pos
> >is a multiple of raw_packet_size, by the debug information, it's
> >not true.
> 
> Not always, because sometimes there are 0x47 sync bytes in the
> packet payload as well. But we siply ignore that case because of the
> return later originated from your patch. Checking for modulo allows
> faster detection and it also allows detection when UDP packets
> contain a single MPEGTS packet.
> 
> >Also it's possible
> >for the pos of two sync byte > 188/192/204 * n. If that's true, it's not correct
> >to look it as stats hit by the modulo logic.
> 
> I don't understand what you mean here.

Let me give one example, the size is 192*2, but the second 192 isn't start by 0x47
sync byte, checking with modulo will not correct for the case


> 
> Regards,
> Marton
> 
> 
> >
> >>
> >>Also skip unrecognized sync byte distances instead of considering them as a
> >>failure of detection. It only delays the detection of the new packet size.
> >>
> >>Also note that AVIO only buffers a single packet (for UDP/mpegts, that usually
> >>means 1316 bytes), so among every ten consecutive 188-byte MPEGTS packets there
> >>will always be a seek failure, and that caused the old code to not find the 188
> >>byte pattern across 10 consecutive packets.
> >>
> >>Signed-off-by: Marton Balint <cus at passwd.hu>
> >>---
> >> libavformat/mpegts.c | 8 +++++---
> >> 1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >>diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> >>index a065c61c40..f2b2c05d86 100644
> >>--- a/libavformat/mpegts.c
> >>+++ b/libavformat/mpegts.c
> >>@@ -2846,12 +2846,14 @@ static void reanalyze(MpegTSContext *ts) {
> >>     if (pos < 0)
> >>         return;
> >>     pos -= ts->pos47_full;
> >>-    if (pos == TS_PACKET_SIZE) {
> >>+    if (pos % TS_PACKET_SIZE == 0) {
> >>         ts->size_stat[0] ++;
> >>-    } else if (pos == TS_DVHS_PACKET_SIZE) {
> >>+    } if (pos % TS_DVHS_PACKET_SIZE == 0) {
> >>         ts->size_stat[1] ++;
> >>-    } else if (pos == TS_FEC_PACKET_SIZE) {
> >>+    } if (pos % TS_FEC_PACKET_SIZE == 0) {
> >>         ts->size_stat[2] ++;
> >>+    } else {
> >>+        return;
> >>     }
> >>
> >>     ts->size_stat_count ++;
> >>-- 
> >>2.26.1
> >>
> >>_______________________________________________
> >>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
> >_______________________________________________
> >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".
> _______________________________________________
> 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