Scratching some Media Library itches4 min read

Besides catching a cold and shovelling snow, this holiday season I spent some time scratching itches in Pitivi. For starters, thumbnails generation: if you’ve been using the new Pitivi, you certainly ran into this:
medialibrary - partial thumbs
As you can see, thumbnails were not necessarily being shown for all clips. That was not the result of a buggy algorithm or anything like that (I don’t code often, but when I do, it’s perfect, of course), simply the fact that my solution for bug 432661 was partial: it would fetch the thumbnails if they already exist, but not create new ones.
Well, this is solved now. No more need to browse the folder with Nautilus to generate thumbnails! This does not block the user interface, thanks to Alexandru Băluț who helped me finish the job by correcting my incorrect attempt at threading with his own implementation.
medialibrary - complete thumbs
The only downside of the threaded version is that you lose the simple benchmarking system I had put in place, but no matter: I’ve measured the numbers already, so let me share them with you.
As you know, I’m pretty adamant about maintaining good performance and responsiveness in Pitivi, especially for operations such as importing clips or loading projects. I know that iconview can be slow, so my commit (before Alex’s changes) had various timers to check if searching through the iconview or updating its items was a significant performance problem. I tried with two scenarios: importing 68 clips to thumbnail, and importing 485 clips to thumbnail. Here are the resulting processing times in seconds:

68 thumbnails 485 thumbnails
Generation 20.131 141.059
Model search 00.1186 004.8595
Model insertion 00.0432 000.4

thumbnail pixbuf iconview model insertion benchmark
As you can see, for reasonable amounts of clips, the amount of time spent interacting with the iconview/treeview model, even using a naïve linear search, is insignificant:

  • The proportion of time spent searching increases when you have to generate hundreds of thumbnails, but it’s still mostly negligible (in the “worst case” shown here, it rises from 0.6% to approximately 3.4%).
  • Surprisingly, the time spent updating the model (inserting the pixbufs) is even more negligible than the time spent searching.
  • In the real world, it is unlikely that each and every thumbnail needs to be generated, searched and inserted. This happens only once in a while for a portion of your clips, not everytime you import each clip or load a project. No point in obsessing and complicating the code with caching, fancy search algorithms or data structures.

I’m hoping that we replace both the iconview and listview by a single “responsive” GTK FlowBox widget eventually, if FlowBox has better (or equal) performance than IconView, but this might take a while. If someone wants to tackle this or wants to help, please get in touch.

Better importing progress indication and error handling

First, the way we counted progression was wrong from a psychological standpoint. A bit tricky to explain, but the label needs to represent the position in the process (so eventually it reaches 100%), whereas the progressbar must hint at the amount of work remaining to complete (so it never goes to 100%).
Second, the error infobar’s “Close” button took an insane amount of space, which became quite apparent in verbose languages like French. GTK+ really didn’t want me to compact that button no matter what I tried, and using an icon instead of text didn’t yield as much space savings as using a single unicode character: ✖
Third, the error infobar was a bit of a tease: it told you that errors occured but did not tell you how many:
pitivi medialibrary error infobar - after
Well, now it does (you can also see the more balanced layout with the new ✖ button):
pitivi medialibrary error infobar - before
As you can see, when it comes to designing a good user interface, I’m kind of obsessive about details.

HeaderBar

I also have a branch where Pitivi uses the client-side decorations and HeaderBar widget from GTK+ 3.10, however I’m blocked by the fact that GStreamer’s video overlay doesn’t work with client-side decorations:
2014-01-04
In other news:

  • Alexandru Băluț fixed importing and timeline thumbnailing for MPEG-TS clips. He also spent a big amount of time and efforts on refactoring various modules.
  • Mathieu Duponchelle made rendering to MP4 and MPEG-TS possible again.
  • Jakub Steiner’s new super-high-res logo icon for Pitivi has been merged.
  • Tomas Karger got started on updating the user manual. It’s great to see someone new getting involved to finally give the user manual the attention it deserves! Thanks, Tomas.
  • I looked again into reimplementing the missing codecs installer dialog, but I’m blocked by the wrong information being provided by the discoverer error signals. On hold for now.
  • I implemented a very nice playback performance boost feature, but I’m blocked by the fact that it would pause the pipeline everytime a backup is saved in the background. Need to think of a solution for that without resorting to questionable hacks.
Jeff

Comments

6 responses to “Scratching some Media Library itches”

  1. God job !
    About MPEG-TS, does it mean that MPEG-TS is now a rock solid, 1st class citizen in Pitivi ?

    1. No, as the quality of its plugin in GStreamer is still not something we could call “good” for Pitivi’s usecases. Random access seeking in MPEG-TS is hard, and in Pitivi you will see it being slow and inaccurate: you will see macroblocks/compression artifacts unless you play or hit a keyframe.

      1. Do you mean that these defects affect the preview or the final work ?

        1. Alex Avatar
          Alex

          It means that if you add a clip to the timeline, the interval [start of the clip, first keyframe) appears bad.

        2. I expect them to mess up the rendering just like live playback, so I filed bug 721812.