GNOME Bugzilla – Bug 727319
Allow generating a unique "thumbnail" to represent a project (timeline)
Last modified: 2015-10-20 13:04:35 UTC
Maybe we could find out a way to "thumbnail a project", to provide a visual representation for our welcome dialog (as part of bug #693014) and (perhaps, optionally) Nautilus. Here's an exerpt/summarized version of an IRC discussion around that: <jimmac> in our weltanschauung mimetypes are not very relevant, we don't present the filesystem to the user anymore <nekohayo> well, as long as Nautilus still exists... <mclasen> there's certainly nothing wrong with providing a mime type icon <jimmac> nothing wrong, sure <jimmac> [but] i can imagine a thumbnail telling me way more about a sequence than a mimetype icon <nekohayo> how do you fit a visual representation of 2 hours of timeline into a 128² or 256² space? (and how do you even represent that thing...) <pippin> "visual rythm"? [...] I am referring to things like: http://moviebarcode.tumblr.com/ <pippin> you can also, instead of just using the same column of pixels throughout the video - scan right (and wrap around when you reach the rightmost one) <pippin> jimmac: I've experimented with using such a thumbnail in the timeline scrollbars of video editors before. such visual rythm; shows the pace of cuts - other things like zooming in and out in the video/ and fades become very apparent <nekohayo> project thumbnails would make sense for bug #693014 I think, but probably not for pitivi project files in nautilus, which I just want them to "look different than plaintext files" <jimmac> nekohayo, yea if you're falling back to nautilus, you lost :) <nekohayo> I'm not "falling back" to it, but I'm using nautilus to actually do stuff it's meant for... like moving/renaming/deleting files :) <nekohayo> pippin, the barcode/visual rhythm approach is very interesting I'd say... the problem is that it would be quite processing intensive, you would have to (frequently) play through the entire timeline to rip out frames and analyze them etc. There's the open question of "when should the thumbnail actually be updated (invalidated)" too <pippin> nekohayo: the architectural impact is the same as for audio-mipmaps in DAWs <pippin> a cached render of distilled information; that doesn't have to be up-to-date for the processed result; but it is nice that it is as immediate as possible <nekohayo> well, imagine a 2 hours long timeline with 20-40 tracks/layers and hundreds of clips, in different file formats (some of which horribly slow to seek etc), and all of that with required 100% trust in the stuff below (GStreamer, gnonlin, etc.) being absolutely bulletproof AND superfast I can't imagine things not going wrong, if you see what I mean <pippin> I can eerily imagine that doing this with a gstreamer based stack is trickier than in the video editor I worked on ;p <nekohayo> and at this point I'm wondering "wouldn't it be much faster and saner to actually take a *screenshot* of the timeline and save that straight to png?" (for project thumbnailer purposes of course, not a rhythm-scrollbar)... but I don't know, in a gtk4-wayland-enabled world, if that would be possible at all <nekohayo> I've thought also of "seek to 20%, 40%, 60 and 80% of the timeline and grab the frame there, combine the 4 into a mosaic" too
Oh yeah, another funky idea that I thought of (but forgot to mention in that discussion above): instead of a static mosaic, one could also imagine an "animated" version of the timeline thumbnail (ex: 4-10 images, one per second, in a loop)
The mosaic and the animated thumbnail ideas looks promising. I don't think, though, that animated thumbnails are that awsome because, e.g. if the user opens Pitivi and lots of animated thumbnails are loaded, the user will have a hard time trying to discover which is the project he wants to open. Too much movement on the screen. The mosaic is the most promising idea for me. But it'll mean that we will have to implement a thumbnailer app, or something like that.
the thumbnail could animate only on mouse hover or keyboard selection
I think this is "only" a matter of making GESTimeline usable inside decodebin. That would allow us to do no extra effort to support thumbnail generation inside totem-thumbnailer or any other thumbnailer of the kind.
I'm not sure that having a reduction of the timeline as icon to represent a project is a good idea. Personnally, when I'm thinking of a project, I'm thinking of rushes and final video result. I don't pay attention to the look of the timeline and I don't even know the look of the whole timeline, since I'm only working on part of it. Let me illustrate that : I can think of a project even before having started to work on the timeline. But I already have my rushes and I already know how should be the result. On the same way, when I want to do some cooking, I think about ingredients and final result, not aboyt the look of the recipe ! Therefore I think that the project icon should use video frames.
I think the concept was in fact the use of rendered images instead of timeline screenshots. The "animate on hover or selection" idea is really awsome! And with the new GtkFlowBox, it shouldn't be that hard to achieve this. The downside, however, is that it doesn't solve the problem for external previewers that cannot render animated thumbnails (e.g. Nautilus). Maybe the best to do is to use both alternatives: on Pitivi, use the animation; for the rest, use the "4 rendered images" approach. Video frames are a nice addition as well. I'll work later on a proof of concept and we'll be able to discuss it with real feedback.
By 'Vide frames' I understood those video bars placed both at left and right side of video previews on Nautilus.
This bug has been migrated to https://phabricator.freedesktop.org/T3175. Please use the Phabricator interface to report further bugs by creating a task and associating it with Project: Pitivi. See http://wiki.pitivi.org/wiki/Bug_reporting for details.