Created attachment 55644 [details]
GST_DEBUG log

http://www.linuxrising.org/chef/chef.avi 

This is an AVI with cinepak video and raw int 8bpp mono audio.

The reason it doesn't preroll properly seems to be that ffdec_cinepak drops all
the frames it decodes because it is waiting for a keyframe that never comes.

The following fixes it sort of, but needs to be double-checked before being
applied (not tested against any other codecs yet, just wanted to report my
preliminary findings):

Index: gstffmpegdec.c
===================================================================
RCS file: /cvs/gstreamer/gst-ffmpeg/ext/ffmpeg/gstffmpegdec.c,v
retrieving revision 1.130
diff -u -p -r1.130 gstffmpegdec.c
--- gstffmpegdec.c      5 Dec 2005 13:04:39 -0000       1.130
+++ gstffmpegdec.c      5 Dec 2005 19:20:06 -0000
@@ -1100,7 +1100,7 @@ gst_ffmpegdec_sink_event (GstPad * pad,
           ffmpegdec->waiting_for_key = TRUE;
         }
       }
-      ffmpegdec->waiting_for_key = TRUE;
+      ffmpegdec->waiting_for_key = FALSE;
       ffmpegdec->synctime = ffmpegdec->next_ts;
       break;
     }

Audio/Video sync also doesn't seem to be quite right with this fix, but it's
really hard to tell anyway, so I'm not sure whether there's an issue or not.

I had a look at it too, and in fact the cinepak ffmpeg codec never sets the
AVFrame->type to anything. On the other hand it always sets AVFrame->reference
to 1. I have a pending patch which checks not only for type == I_TYPE, but also
for reference == 1.
I tried it over a lot of files and it seems to work. I should also try seeking
with it to see if it doesn't break anything.
The problem is that there are FOUR different variables that ffmpeg codec can set
in a AVFrame structure to give information about the decoded frame. I already
had to file a patch for dvvideo in ffmpeg, and cinepak seems to have the same
problem. So instead of fixing it upstream (although it would be nice), it might
be wiser to find out which of those four values are actually used and what
combination means that the decoded frame is really a keyframe.

Fixed in cvs. Keyframes are now determined as follow:
iskeyframe = ((ffmpegdec->picture->pict_type == FF_I_TYPE) ||
(ffmpegdec->picture->reference))

I tried it with many files (with the testsuite and totem), and I don't think it
broke anything.