Now that the Internet is back to normal, here’s a status update on what I’ve been busy doing lately.
You may remember my initial donation experiment last month where I presented the new realtime trimming preview feature—I was not kidding. It’s merged in the pitivi “ges” development branch now, with some additional improvements tacked on.
Since my last blog post, I’ve been spending a lot of spare time:
- Preparing Pitivi for GSoC (and in general, every detail counts to make the lives of new contributors easier)
- Mentoring GSoC candidates
- Filing bugs and cleaning up my shared internal “Pitivi GES TODO”
- Making GNOME git the official development repository for PiTiVi
- Reviewing and merging patches. One of the new visible features I’m enthusiastic about is the ability to export standalone archives of your project (thanks to Paul Lange), which can come in handy for debugging!
- Documenting various things:
- What GES is and how important the port to GES is to us.
- Creating some new brainstorming pages for the title editor and for grouping/nesting.
- The situation with GTK 3/GSt 1.0 (hopefully, with some help we will resolve that quite soon, actually)
- Searching for creative ways to get people to contribute to GES and solve the bugs that prevent us from making a release right now.
If you take a step back and compare to the latest stable release (0.15.1), on the pitivi side you have:
- Clip thumbnails in the media library are not only much prettier: they load instantaneously too.
- An automated project backup/restore system. The new code for it is beautiful. I spent a crazy amount of time testing it (those of you who know me know that I’m probably the most meticulous tester that can be), and as far as I can tell, it’s bulletproof.
- Cleaned up menus and keyboard shortcuts
- The ability to export the current frame
- Sleep inhibition (thanks to Stephen Griffiths)
- An improved clip previewer that gives you more space to view the video, yet stays out of your way (pictured above)
- Better filename/paths handling
- Less CPU usage when idle
- Match GTK’s appearance regarding button icons
- Various little UI fixes all over the place
- A huge code cleanup and refactoring all around, with a vastly simplified codebase and much simpler architecture
That’s just the surface. With GES, in addition to the simplified Pitivi codebase, we have some other niceties:
- Playback performance back to the 0.13.1 levels (or better?). Want to play a 1080p clip? No problem. A 4K clip? Then you’ll probably benefit from hardware decoding acceleration when we switch to GStreamer 1.0, if your video hardware and driver supports it—goodbye, CPU bottlenecks.
- Importing clips is blazing fast and asynchroneous (it won’t block the UI).
- Loading a project timeline is instantaneous.
- Various backend bugs that plagued earlier releases are possibly a thing of the past.
- Faster application startup.
- Boundless possibilities…
It’s not ready just yet though. We need your help to be able to get 0.16 out of the door. There are some feature regressions (like drawing the clip thumbnails or waveforms on the timeline), but more importantly there are a handful of serious bugs in GES that are blocking us (they are not many, but they’re hard to solve). If we can get help to fix these we might finally be able to get a release (or at least an alpha) out of the door.
Comments
6 responses to “PiTiVi GES spring sitrep3 min read”
The new media library clip previewer looks awesome !
Man! the preview looks gorgeous! will it have any editing funcionalities (buttons) so we can prepare the clip for the timeline? Or will it just preview (as the name itself describes) 😀
Eventually yes, it would be nice to add some buttons to set the in/out point of clips so that the can be “pre-trimmed” before insertion in the timeline. Patches for https://bugzilla.gnome.org/show_bug.cgi?id=353864 are welcome 🙂
this is awesome. I’m so looking forward to PiTiVi 0.16!
is it possible to add frame precision to the edits? so when you zoom in the timeline you could set the program to handle the cuts at the start of the “frame tick” instead of a random spot in time.
@Biel: that’s an interesting question… something that should be done in GES (rather than Pitivi itself)… but how can you guarantee the presence of keyframes? Not only do we expect users to mix various codecs/clips/sources, but some codecs have variable framerates or variable keyframes and whatnot. You can’t guarantee you have a keyframe at a particular point, and that’s why seeking in some formats is slow (because you don’t have keyframes everywhere). Perhaps you could come discuss this in #gstreamer or #pitivi and file a bug eventually?
i didn’t know there where codecs with variable frame rate… I thought you could have diferent videos with diferent framerates. but a single video with variable framerate?
you could either repreoduce the videos to the current framerate (this is what Blender does)
or you could also either repete or delete frames so the reproducing time stays the same yet the frames get adapted to the new framerate (the one from the project)
this last technique is like changeing the velocity of reproduction and then reproduce the adapted frames to the framerate stipulated in the project. so the iend result is a resulting vide of hte same duration but reproducing at diferent FPS.