GNOME Bugzilla – Bug 140679
nautilus sometimes chooses bad frames for video thumbnails
Last modified: 2006-08-25 08:19:54 UTC
This applies to thumbnails of video files only. When picking a frame to serve as the thumbnail, Nautilus sometimes selects all-black frames, or other frames that don't show anything interesting. Instead of trying to make it "smart" about the selection, maybe Nautilus should allow the user to request a new thumbnail frame be chosen. This would require two things: 1) The frame selection appears to be deterministic (if you delete a thumbnail and reload, the same frame will be selected). Frame selection would have to be made more random. (Would this break anything?) 2) Some sort of UI would have to be added to refresh the thumbnail. (As a user, the first thing I tried was to click on the thumbnail image in the Properties dialog.) This is somewhat related to bug 43335 and bug 106092.
do you still get this problem ? nautilus doesn't make video thumbnails but totem and nautilus-media do, are you using one of them ?
Yes, the behavior is still the same. To be clear, there is no problem in the thumbnail creation. It does pick and display valid and proper-looking frames from the movies. However, I don't like the frames it chooses for some movies, and would like a way to request that a new frame be choosen. I do have Totem installed, but I'm not using it when thumbnails are made. I'm viewing the directory with Nautilus (in icon view) and can see each thumbnail being created as it grinds on the disk. Does Nautilus ask Totem to make the thumbnails?
yes, nautilus doesn't make video thumbnails, this job is made by totem. I'm reassiging the bug.
Ok, although Nautilus would still need a way to request that a new thumbnail be created.
new thumbnail -> "Bug 43335: we need an explicit "Make Thumbnail" command."
Created attachment 36731 [details] My config.log
Oops, sorry this attachment was for another bug :(
Created attachment 47254 [details] [review] patch with my small c/c++ knowledge, i created a small patch that adds some randomeness to the chosen frame. instead of taking the frame at 1/3th of the file, it takes one at 100+x/300 where x ranges between -30 and 30.
Created attachment 47264 [details] [review] patch it's my first time, i am allowed to make mistakes :)
" 1) The frame selection appears to be deterministic (if you delete a thumbnail and reload, the same frame will be selected). Frame selection would have to be made more random. (Would this break anything?) " Hmm, this is expected. Say you copy a file to a CD or whatever, you know that you have the same video because the 2 files show the same thumbnail.
Good point; it does need to be deterministic. So how about just choosing a second frame if the first is too dark? I don't think it would break anything.
And how do you check if the video is too dark?
There must be an established way to determine the "brightness" of an image. What comes to mind, and this may be too simplistic, is to just take the average of all three components of all pixels in the chosen frame. If the average is less than X, move to the next spot (deterministically) and try again. The next spot could be 3-5 seconds forward-- after the 'fade out', and maybe already in the disk cache. If it turns out to just be a very dark movie, it should probably give up and go with the original frame chosen, so as not to change legacy thumbnails.
Feel free to re-open this bug if you know a way to "determine the brightness of an image", and have some code for it.
I've written a patch for this issue, I've described it in bug #352802