[Ffmpeg-devel] Seeking with in an MPEGTS

[Andy Parkins]

Hello,

As part of my search for this bug I've been looking in mpegts.c:read_seek()
I think I've found a bug; rather than the loop searching for byte 1 of a 
packet to match 0x40 is it not better to simply call mpegts_resync() which 
will find the start of the next PES packet?  The patch below does just that.

I'm not sure that I'm correct in this; because it may be that the seek is 
actually looking for the next start of payload packet (hence buf[1] & 0x40).  
However, even if I'm not I think that read_seek should at least resync before 
it goes looking for the start of payload - unless I've missed the part that 
ensures av_seek_binary() only returns on a TS boundary.


Index: libavformat/mpegts.c
===================================================================
--- libavformat/mpegts.c        (revision 3)
+++ libavformat/mpegts.c        (working copy)
@@ -1338,18 +1347,9 @@
     if(av_seek_frame_binary(s, stream_index, target_ts, flags) < 0)
         return -1;
 
-    pos= url_ftell(&s->pb);
+    if (mpegts_resync(&s->pb) < 0)
+        return AVERROR_INVALIDDATA;
 
-    for(;;) {
-        url_fseek(&s->pb, pos, SEEK_SET);
-        if (get_buffer(&s->pb, buf, TS_PACKET_SIZE) != TS_PACKET_SIZE)
-            return -1;
-//        pid = ((buf[1] & 0x1f) << 8) | buf[2];
-        if(buf[1] & 0x40) break;
-        pos += ts->raw_packet_size;
-    }    
-    url_fseek(&s->pb, pos, SEEK_SET);
-
     return 0;
 }
 


-- 
Dr Andrew Parkins, M Eng (hons), AMIEE

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20050621/9da7022e/attachment.pgp>