[FFmpeg-cvslog] r20839 - trunk/libavformat/id3v2.c

[Michael Niedermayer]

On Sun, Dec 13, 2009 at 07:19:14PM -0800, Baptiste Coudurier wrote:
> Hey guys,
>
> On 12/13/09 5:53 PM, Michael Niedermayer wrote:
[...]

> If you have any question, I'll be glad to explain the changes.

heres one:
             put_bits(&s->pb, 6, (uint32_t)((time_code / fps) % 60));
             put_bits(&s->pb, 6, (uint32_t)((time_code % fps)));
-            put_bits(&s->pb, 1, !!(s->flags & CODEC_FLAG_CLOSED_GOP));
+            put_bits(&s->pb, 1, !!(s->flags & CODEC_FLAG_CLOSED_GOP) ||
+                     (s->avctx->max_b_frames > 0 &&
+                      !s->current_picture_ptr->coded_picture_number));
             put_bits(&s->pb, 1, 0); /* broken link */
         }
 }

why the max_b_frames > 0 check?
also why the hunk at all? for what case does this make a difference?


and heres another question:
@@ -141,12 +144,22 @@
        to have the full timing information. The time take by this
        function should be negligible for uncorrupted streams */
     mpegvideo_extract_headers(s, avctx, buf, buf_size);
+    if (!s->pict_type && buf_size) {
+        av_log(avctx, AV_LOG_ERROR, "error fetching pict type, discarding\n");
+        /* update parser context anyway for timestamps and pos */
+        s->frame_offset = s->next_frame_offset;
+        s->next_frame_offset = s->cur_offset + next;
+        s->fetch_timestamp = 1;
+
+        *poutbuf = NULL;
+        *poutbuf_size = 0;
+        return next;
+    }
 #if 0
     printf("pict_type=%d frame_rate=%0.3f repeat_pict=%d\n",
            s->pict_type, (double)avctx->time_base.den / avctx->time_base.num, s->repeat_pict);

why that?

and
this:
diff -uN /home/michael/ffmpeg-revs/ffmpeg-r20539/trunk/libavcodec/cavsdec.c ./cavsdec.c
--- /home/michael/ffmpeg-revs/ffmpeg-r20539/trunk/libavcodec/cavsdec.c	2009-12-13 14:13:19.000000000 +0100
+++ ./cavsdec.c	2009-11-15 04:50:19.000000000 +0100
@@ -634,7 +634,6 @@
     const uint8_t *buf_end;
     const uint8_t *buf_ptr;
     AVFrame *picture = data;
-    uint32_t stc = -1;
 
     s->avctx = avctx;
 
@@ -649,6 +648,7 @@
     buf_ptr = buf;
     buf_end = buf + buf_size;
     for(;;) {
+        uint32_t stc = -1;
         buf_ptr = ff_find_start_code(buf_ptr,buf_end, &stc);
         if(stc & 0xFFFFFE00)
             return FFMAX(0, buf_ptr - buf - s->parse_context.last_index);

?

Also, is if the h264* stuff contains bugfixes it would be great if you could
post the relevant hunks to the matching issue on roundup or on ffmpeg-dev.

ill probably have more questions :)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20091214/4d6da713/attachment.pgp>