GNOME Bugzilla – Bug 352802
PATCH: thumbnailer sometimes picks solid-color frame
Last modified: 2007-01-09 16:09:45 UTC
I've written a patch that fixes #140679. The problem is that totem-video-thumbnailer always uses the same frame 1/3rd through a video clip to use for the thumbnail. However, sometimes the frame it picks is "boring", that is it's at the end of a fade-out and so the frame is solid black. In this patch, I've done two things: 1. I've added a function called is_image_interesting. This function reads the image as a set of discrete samples (so essentially, a b/w image) and calculates the statistical variance; it returns true if the variance is above a certain threshold. Images that are solid colors (or near it) will have very low variance, whereas more "interesting" images will be higher. 2. Instead of only reading one frame, the thumbnailer will iterate through a predefined list of offset percentages to check (1/3, 2/3, 1/2, etc..). If the frame isn't interesting, it tries the next one. If none of them are interesting, it will take the last one (currently at 1/2). This patch solves the previous patch's issue of jittering the frame, because this method will always generate the same image for a given video, as well as handle solid images regardless of what color they are (for example, detecting the brightness wouldn't work if the movie did a fade-to-white).
Created attachment 71570 [details] [review] Patch against CVS HEAD to fix issue described above patch -p1 in the root Totem directory (or is it -p0, not sure).
Btw, this is a recreation with better information of bug #140679
How much longer does that make capturing an image? Also, there are some files for which this is not going to be useful, particularly those for which seeking to keyframes isn't implemented (on some WMV files, or Ogg Theora, you'd get black after a seek, until after reaching a keyframe).
Overall, it was hard to get any numbers on it, I tried to do some basic profiling using time but it was mostly based on disk access time (so naturally, the 2nd time you ran it, it'd go faster). All it does is quickly iterate through the image buffer twice, I suspect it's not going to add any significant amount of time on anything other than a really old processor.
Some of the hacks for GStreamer 0.8 have been removed. Could you update your patch for it?
Created attachment 71636 [details] [review] Patch against current CVS HEAD (as of 8/25/06) This patch also fixes a bug where if all the images were solid colors, the pixbuf would be unref'd and burning death would result.
I can't really get any reasonable perf information, even after running it on 25ish movie-sized files in a row, I think it's fine. paul@desdemona:~/Repos/totem/src$ time find /media/usbdisk-1/Movies . | grep '^[^\"]*\.avi$' | xargs -i ./perf_helper ./totem-video-thumbnailer "{}" real 1m1.325s user 0m51.939s sys 0m3.852s paul@desdemona:~/Repos/totem/src$ time find /media/usbdisk-1/Movies . | grep '^[^\"]*\.avi$' | xargs -i ./perf_helper /usr/bin/totem-video-thumbnailer "{}" real 1m29.261s <-- The disk blocked for no particular reason on this run user 0m50.927s sys 0m3.480s
Is there anything else I need to do for this patch?
Nope, we'll integrate it when we branch for GNOME 2.17 work.
I fixed the most obvious style problems, and committed this to HEAD. 2006-09-11 Bastien Nocera <hadess@hadess.net> * src/totem-video-thumbnailer.c: (is_image_interesting), (main): Patch from Paul Betts <paul.betts@gmail.com> to try and get a useful thumbnail picture, avoiding solid-colour backgrounds (Closes: #352802)
*** Bug 394674 has been marked as a duplicate of this bug. ***