It's supposed to take the screenshot just a little before the end of the video file, but it seems to fail when the index in the stream is too coarse. Using GST_SEEK_FLAG_ACCURATE for the seek might fix the problem.

Can you test this patch? Otherwise it'll have to wait until I can investigate more.

diff --git a/src/totem-video-thumbnailer.c b/src/totem-video-thumbnailer.c
index 48d5862..8ed1f2c 100644
--- a/src/totem-video-thumbnailer.c
+++ b/src/totem-video-thumbnailer.c
@@ -332,7 +332,7 @@ thumb_app_seek (ThumbApp *app,
                gint64    _time)
 {
        gst_element_seek (app->play, 1.0,
-                         GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT,
+                         GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE,
                          GST_SEEK_TYPE_SET, _time * GST_MSECOND,
                          GST_SEEK_TYPE_NONE, GST_CLOCK_TIME_NONE);
        /* And wait for this seek to complete */

That doesn't seem to be enough.

I can reproduce here with an MP4, WMV and MKV types.

Tim, ideas?

The reproducer is:
totem-video-thumbnailer -v -g 3 video.mov foo.png

It looks like what happens is that the videosink gets a GAP event before it gets a video buffer, which makes it preroll, but then the snapshotter doesn't find a buffer of course. The GAP event is probably sent by the streamsynchronizer in playbin because the audio track went EOS already. Possibly a bug.

One thing to try would be to tell playbin not to render any audio at all, but getting the "flags" property and unsetting the audio flag.

It's totem-video-thumbnailer, not the player. I've disabled GST_PLAY_FLAG_AUDIO to leave GST_PLAY_FLAG_VIDEO as the only flags, and it doesn't make a difference. Setting a NULL audiosink instead of a fakesink also doesn't solve the problem.

Tim, any new ideas about this problem?

I think I read about a problem with seeking to the very last frame, don't we have this bug where we may reach EOS, even though seek is accurate ? Would be nice if the offending video can be made available.

(In reply to comment #7)
> I think I read about a problem with seeking to the very last frame, don't we
> have this bug where we may reach EOS, even though seek is accurate ? Would be
> nice if the offending video can be made available.

All the AVI and MP4 videos I tried on my system failed in the same way. MKV seemed to work.

Maybe a demuxer problem?

(In reply to comment #8)
> All the AVI and MP4 videos I tried on my system failed in the same way. MKV
> seemed to work.
> 
> Maybe a demuxer problem?

Thanks, just didn't understand that from the initial problem. And is these seek accurate or not ?

(In reply to comment #9)
> (In reply to comment #8)
> > All the AVI and MP4 videos I tried on my system failed in the same way. MKV
> > seemed to work.
> > 
> > Maybe a demuxer problem?
> 
> Thanks, just didn't understand that from the initial problem.

The last frame we seek to when creating a gallery in totem-video-thumbnailer fails to get captured. Reproducer's in comment 3.

> And is these seek accurate or not ?

"GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT" is what totem-video-thumbnailer uses right now.

Using "GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE" makes no difference, we still fail to capture the last frame of our gallery.

$ totem-video-thumbnailer -v -g 3 foo.avi foo.png
TotemVideoThumbnailer-Message: Initialised libraries, about to create video widget
TotemVideoThumbnailer-Message: setting URI file:///home/hadess/Projects/jhbuild/totem/src/foo.avi
TotemVideoThumbnailer-Message: Video widget created
TotemVideoThumbnailer-Message: About to open video file
TotemVideoThumbnailer-Message: Opened video file: 'foo.avi'
TotemVideoThumbnailer-Message: Producing gallery of 3 screenshots, taken at 2661946 millisecond intervals throughout a 7985840 millisecond-long stream.
TotemVideoThumbnailer-Message: Outputting as 1 rows and 3 columns.
TotemVideoThumbnailer-Message: Scaling each screenshot by 0.400000.
TotemVideoThumbnailer-Message: Created output pixbuf (816x118).
TotemVideoThumbnailer-Message: Composited screenshot from 2661946 milliseconds (address 274855472) at (12,5).
TotemVideoThumbnailer-Message: Composited screenshot from 5323892 milliseconds (address 39850384) at (280,5).

** (totem-video-thumbnailer:14619): WARNING **: Could not take screenshot: failed to retrieve or convert video frame

(totem-video-thumbnailer:14619): GdkPixbuf-CRITICAL **: gdk_pixbuf_composite: assertion 'GDK_IS_PIXBUF (src)' failed

(totem-video-thumbnailer:14619): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
TotemVideoThumbnailer-Message: Composited screenshot from 7985838 milliseconds (address 0) at (548,5).
TotemVideoThumbnailer-Message: Converting pixbuf to a Cairo surface.
TotemVideoThumbnailer-Message: Writing header text with Pango.
TotemVideoThumbnailer-Message: Writing screenshot timestamps with Pango.
TotemVideoThumbnailer-Message: Writing timestamp "44:21" at (230.880000,170.824000).
TotemVideoThumbnailer-Message: Writing timestamp "1:28:43" at (487.880000,170.824000).
TotemVideoThumbnailer-Message: Writing timestamp "2:13:05" at (755.880000,170.824000).
TotemVideoThumbnailer-Message: Converting Cairo surface back to pixbuf.
TotemVideoThumbnailer-Message: Saving captured screenshot

This seems to work fine for me nowadays with the handful of (well-formatted/non-broken) MP4, MKV, AVI files I have tested.

Please re-open if it's still an issue, and/or make a sample file available please.