On Wed, May 20, 2020 at 08:26:37AM +0200, Marton Balint wrote:
>
>
> On Wed, 20 May 2020, lance.lmw...@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 <c...@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@ffmpeg.org
> >>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >>To unsubscribe, visit link above, or email
> >>ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> >--
> >Thanks,
> >Limin Wang
> >_______________________________________________
> >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".
> _______________________________________________
> 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".
--
Thanks,
Limin Wang
_______________________________________________
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".
