After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 352802 - PATCH: thumbnailer sometimes picks solid-color frame
PATCH: thumbnailer sometimes picks solid-color frame
Status: RESOLVED FIXED
Product: totem
Classification: Core
Component: Thumbnailer
1.5.x
Other All
: Normal enhancement
: ---
Assigned To: General Totem maintainer(s)
General Totem maintainer(s)
: 394674 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-08-25 08:13 UTC by Paul Betts
Modified: 2007-01-09 16:09 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Patch against CVS HEAD to fix issue described above (5.18 KB, patch)
2006-08-25 08:15 UTC, Paul Betts
none Details | Review
Patch against current CVS HEAD (as of 8/25/06) (4.17 KB, patch)
2006-08-26 02:57 UTC, Paul Betts
committed Details | Review

Description Paul Betts 2006-08-25 08:13:10 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).
Comment 1 Paul Betts 2006-08-25 08:15:50 UTC
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).
Comment 2 Paul Betts 2006-08-25 08:16:53 UTC
Btw, this is a recreation with better information of bug #140679
Comment 3 Bastien Nocera 2006-08-25 10:30:48 UTC
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).
Comment 4 Paul Betts 2006-08-25 16:39:38 UTC
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.
Comment 5 Bastien Nocera 2006-08-25 17:03:57 UTC
Some of the hacks for GStreamer 0.8 have been removed. Could you update your patch for it?
Comment 6 Paul Betts 2006-08-26 02:57:56 UTC
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.
Comment 7 Paul Betts 2006-08-26 03:19:11 UTC
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
Comment 8 Paul Betts 2006-09-04 23:57:27 UTC
Is there anything else I need to do for this patch?
Comment 9 Bastien Nocera 2006-09-05 09:47:39 UTC
Nope, we'll integrate it when we branch for GNOME 2.17 work.
Comment 10 Bastien Nocera 2006-09-11 19:58:41 UTC
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)
Comment 11 Bastien Nocera 2007-01-09 16:09:45 UTC
*** Bug 394674 has been marked as a duplicate of this bug. ***