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 432661 - Properly cache and generate thumbnails for the media library
Properly cache and generate thumbnails for the media library
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: Media library
Git
Other Linux
: Normal normal
: 0.93
Assigned To: Jean-François Fortin Tam
Pitivi maintainers
Depends on: 667203
Blocks:
 
 
Reported: 2007-04-23 16:29 UTC by Edward Hervey
Modified: 2014-01-04 17:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2007-04-23 16:29:00 UTC
We should cache the generated thumbnails, possibly using the freedesktop.org specs.
Comment 1 Jean-François Fortin Tam 2009-01-04 19:26:14 UTC
This is why thumbnails are not shown when I load a saved project, I presume. Or should I file a separate issue about that?
Comment 2 Edward Hervey 2009-01-05 09:24:20 UTC
Yes and No. It would solve the issue on standard systems (respecting the fdo specs), but we would still need to also store them in the project files/directories (so we can move the thumbnails along with the project).
Comment 3 Jean-François Fortin Tam 2009-01-05 14:15:40 UTC
My understanding would rather be:
1) if there is no thumbnail, create it according to fdo (so nautilus and such benefit from it; and, inversely, you can get thumbnails for free from nautilus' thumbnailer/fdo-compliant apps)
2) if the project (.pptv) moves, thumbnails are unaffected since they come from the system anyway; the thumbnail is not stored with the project per se
3 if the .pptv is moved onto an altogether different computer, goto 1
4 if the media files moved, goto 1
5 if the thumbnails disappeared, goto 1

I think thumbnails are not important enough to be moved along with the project. They can be generated on demand on the working system, no?
Comment 4 Edward Hervey 2009-01-06 09:33:38 UTC
That logic makes sense... except for one little thing ... You're not guaranteed that, if you move the project to another computer, that person has the plugins needed to decode/playback/support all the files.

If we move the thumbnails with the project then for the unsupported files we could:
* still show the sources used in the sources browser along with its metadata and thumbmail,
* still show in the timeline the sources using that file and instead of using the fully-decoded audio/video we could show a continuous video stream using that thumbnail (along with maybe a "missing file overlay").

This is something we want to have supported in the new design and is already supported in some pro editors as well as in AAF for example.
Comment 5 Jean-François Fortin Tam 2009-01-06 13:16:06 UTC
I'm not sure to understand the usefulness of showing thumbnails for a clip that the user can't playback because of lack of plugins or because the file is 404; I was thinking that, on the contrary, missing thumbnails might be a very obvious visual "indicator" to the user raise awareness of the problem? 

But I guess I see what you want to achieve. It might be more complicated for not much though, just a thought.
Comment 6 Alessandro Decina 2009-03-13 10:38:45 UTC
Regarding the freedesktop thumbnailing specification, it's dead and is implemented only by nautilus afaik. Besides, it's only for one-thumbnail-per-file cases. We can generate hundreds of thumbnails for the same file so i don't think it applies to pitivi.
Comment 7 Edward Hervey 2009-03-13 10:40:51 UTC
Alessandro, argh.. that's bad :(

Aren't there any new specs for where to store thumbnails ? Or does every app do his own stuff ?
Comment 8 Alessandro Decina 2009-03-13 10:44:42 UTC
pvanhoof wrote something on his blog when he was working on the thumbnailer for hildon, but i don't think that a spec came out of that. 
Comment 9 Jean-François Fortin Tam 2009-12-01 13:36:19 UTC
http://live.gnome.org/ThumbnailerSpec seems to be about pvanhoof's work, seems to be edited often.
Comment 10 Jean-François Fortin Tam 2011-12-31 15:21:37 UTC
I finally have a fix for this is my "thumbnails-from-fdo" branch. It simply gets the thumbnails from the fdo thumbnails dir and does no thumbnail generation. From my understanding, it would make more sense for gst discoverer should be the one to do thumbnail generation (or totem's code to be upstreamed to gst).
Comment 11 Thibault Saunier 2012-01-02 13:58:29 UTC
Keep it open because of thumbnails generation. We should open a new bug about that in GStreamer for the discoverer to handle the thumbnail generation and make this one depend on the GStreamer one.

author Jean-François Fortin Tam <nekohayo@gmail.com>
 Fri, 30 Dec 2011 18:00:55 +0000 (13:00 -0500)

commit892319e0112add23881334cef2b196807ef78370
Comment 12 Jean-François Fortin Tam 2012-09-02 04:24:14 UTC
This task is open for anyone willing to attempt finishing it, so adding the gnome-love keyword.
Comment 13 Nicolas Dufresne (ndufresne) 2012-09-21 19:44:50 UTC
Pitivi can use the gnome-desktop API to generate thumbnails. This is what nautilus uses internally. Note that the API is synchronous, we probably don't want to wait for the thumbnail before adding them to the media library. Nautilus has a worker thread and a queue, it updates the UI when the thumbnail is ready.

About the unsupported format, my personal opinion is that the discoverer should tell us if a file is not supported on the current system. UI whise I would put a specific icon to represent that. We could then consider a UI similar to what Totem is doing for missing plugins.

Currently, the gnome-desktop API uses the thumbnailers specified by desktop files in /usr/share/thumbnailers/. It contains on my side the Totem and Evince thumbnailer. I feel like we could provide a thumbnailer in GStreamer (which would deprecate the totem one). This way PiTiVi would not depend on Totem for that. But that is just an idea.

Obviously, for timeline thumbnails, we have no choice but to implement our own. This makes using gnome-desktop API a little redundant. If we where to have a gstreamer thumbnailer, we could depend on that to generate both the file thumbnail, and the one for the timeline. Those thumbnails seems very specific to PiTiVi, but not specific to a project, so I'd store them in .cache/pitivi/thumbnails imho. Generating them out of process is probably a good idea.
Comment 14 Jean-François Fortin Tam 2014-01-04 17:17:32 UTC
Got a bit sick of waiting for this to happen in gst discoverer bug #667203, so I did it in Pitivi for now. If 667203 finally happens, we'll need to open a new Pitivi bug.


commit 75c01e5f0d353092ab31488ca0d1d6c629ff2041
Author: Alexandru Băluț <alexandru.balut@gmail.com>
Date:   Fri Jan 3 17:45:17 2014 +0100

    medialibrary: Generate thumbnails in the background

commit bf95c041c774eacc877b94fb2e6a3d18c2436868
Author: Jean-François Fortin Tam <nekohayo@gmail.com>
Date:   Mon Dec 16 20:53:24 2013 -0500

    medialibrary: Automatically generate missing thumbnails
    
    Completes the solution for bug #432661