April 14, 2014

First delivery of the pitivi fundraiser: universal daily bundles for Linux

The Pitivi community is very happy to announce the availability of easy to use, distro-independent Linux bundles to test latest version of the application. This eliminates dependency problems and allows quicker testing cycles. Our entire stack is bundled, so the only requirement is glibc ≥ 2.13.

Simply Download the bundle and run it!

This is the first delivery of the Pitivi Fundraiser—as you can see, we are already well on our way to deliver what has been promised in our detailed planning. You can have a look at what is happening with the "daily build" bundles on on our Jenkins instance (main server hosting donated by Collabora—thanks!).

To build the bundles we use Cerbero, which is the build and packaging system used by Collabora and Fluendo to construct the GStreamer SDK, and is also used by the GStreamer community to deliver GStreamer 1.x binaries for Android, iOS, Mac OS X and Windows. It is a very useful and well-designed technology, which will allow us to easily create packages for Windows and Mac OS X in the future.

This does not only apply to us, of course: work that has been made for creating Linux distro bundles allows anyone to easily create bundles for their applications with Cerbero. This has not been merged just yet, but that should happen quite soon. If you want to bundle your app using Cerbero, do not hesitate to ask us, even if it should already be really straight forward!

We raised half of the amount we are targeting for the Pitivi fundraising campaign, and we are in very good shape to be able to deliver everything on time. We need your help to reach that target.

Please donate now to make sure we will be able to provide the community with the great video editing app it deserves!

April 08, 2014

How do you visually represent a project’s timeline?

Here is a fun example to illustrate why software development in general is a complex endeavour:

  1. You think you’re going to fix a tiny problem: “hey, maybe we could make ‘s welcome dialog look a bit nicer“.
  2. Eventually, someone proposes a design or idea that looks interesting, and you realize that to truly realize it, you should also implement an audacious new feature: a way to visually represent an entire timeline as a thumbnail (that one is an open question, by the way; if you have some clever ideas, feel free to share them)
  3. …and to display new feature B properly, you should also consider—ideally—being a good citizen and implementing feature C upstream, in the toolkit you use instead of doing your own thing in your corner.

This kind of serendipity and interdependence happens regularly in FLOSS applications like Pitivi where we prioritize quality over “meeting shareholders’ deadlines and objectives”, which is why we sometimes take more time to flesh out a solution to a problem: we aim for the best user experience possible, all while negotiating and working with the greater software ecosystem we live in, instead of silently piling up hacks in our application… and we depend on the involvement of everyone for things to progress.

March 21, 2014

GStreamer Hackfest and the first Beta release of Pitivi, "Ra is a happy"

Last week-end, part of the Pitivi Team went to the GStreamer Hackfest in Google's offices in Munich to work with twenty other GStreamer hackers on various important technical issues. A big thanks to Google and Stefan Sauer for hosting the event! Keep your eyes peeled: we will soon blog the results of the work the Pitivi team has accomplished during the hackfest.

During the hackfest a very important milestone has been reached: the first GStreamer Editing Services, GNonLin and gst-python stable versions in the 1.X branch have been released. That means that these very central components of the Pitivi project are now considered stable.

While this backend work was essential to the beta release, we also want to specifically thank Alexandru Balut for his impressive involvement during the 0.92 -> 0.93 cycle. He provided an impressive amount of bug fixing and cleanup patches in Pitivi itself, and has greatly helped the project reach a beta state. Any inquiries regarding the 0.93 release codename must be sent in his general direction.

This release will be the basis on which we will start our work for our ongoing fundraiser. We've done that work in our spare time, and we're excited about what we'll be able to accomplish once we start working full time! Thibault Saunier has already been preparing bundles for the release, more on that in the next post!

Once again, you can help us in producing a rock solid stable release, by donating and spreading the message!

Pitivi 0.93 released

Last week, a flash snowstorm brought me around 2ft of snow overnight. I thought, “If I’m going to clear that much snow, might as well have some fun and make a timelapse out of it”, and so I did. While watching it, I realized, “Hmm… that’s an interesting metaphor for the huge amount of preparatory and cleanup work we’ve been doing in the past few years”:

Today, we’re very happy to announce another great Pitivi release. It brings a truckload of bug fixes and refinements, which you can read about in the 0.93 release notes (prepared by yours truly). This release now brings us to a quality level where we can let go of the “alpha” status and call this a “beta”. Many nasty bugs are gone and people are increasingly relying on it for their own projects. Besides the video above, the 2014 fundraiser‘s video and the Pitivi showcase, I was quite pleased to see someone using Pitivi to easily make a nice video for a commercial booth at a technology tradeshow!

0.93 is the result of continued efforts in our spare time—occasional hacking during vacations, nights and week-ends. Just imagine what could be achieved if Mathieu and Thibault could be funded to work full-time towards bringing us to 1.0!

Update: you may also want to take a look at this blog post.

March 03, 2014

Pitivi Fundraiser Week One Update (And A Great Piece Of News)

Greetings Pitivi supporters!

We hope everyone had a great week! We've had a rather hectic one, and hopefully that's just the beginning. This is the first update for our fundraising campaign, be sure to check our blog weekly for more ;)


We are happy to announce that the GStreamer maintainers decided to show us their faith and support, by allocating 2 500 € to our project from GStreamer funds! This is great news for several reasons:

  • It's obviously nice to get such an amount of money as it represents seven percent of the total needed to get a 1.0 release or, to put it another way, three weeks of full time development!

  • GStreamer is the central component of our architecture, and it is the one on which we plan to spend most of our time during the push to 1.0. Pitivi really is just the tip of the iceberg, to put things in perspective, it now only is a mere 25,000 lines of Python code, whereas GStreamer and its plugins represent around 1.5 million lines of code.

    Our work really benefits every other project that uses GStreamer (for example, accurate seeking in ogg files? That was us!), and it is meaningful to see the GStreamer maintainers acknowledge that "officially", many thanks to them! And then many more for the road. They're awesome and a big reason why we love working on Pitivi.

  • We really hope this donation will help everyone that cares about Open Source, be they individuals craving for flawless multimedia handling on Linux or companies interested in building products around GStreamer, to see that we are an integral part of the community, and that donating to the campaign is not only about getting a great video editor, but also about improving the core multimedia engine shared by most if not all the Linux distributions!


We would like to thank each and everyone of the 350+ backers that already donated to the campaign and helped us break the 10 000 euros bar during this last week. 11 000 € is a great amount of money, sufficient to cover our expenses for three months of full-time development! With your help, we already made it to a third of our first goal, and with your help we can make it to Pitivi 1.0 and beyond. Anything helps, be it blogging, tweeting and sharing on social networks, or getting the word out to journalists.

DistroWatch also decided to make us the recipient of their monthly donation, and granted us 280 euros, it's a great honor for us to be listed among the previous recipients of that donation!


The dictionary doesn't seem to agree that this word should exist, but it's here nevertheless. Next week should see an interesting announcement for all the fans of Python, Romania and clean code, make sure to stay tuned on our twitter or to add this blog to your RSS feeds ;)

February 27, 2014

Pitivi status update for Q1 2014, fundraiser launch

Since my previous technical update in January, I haven’t had time to touch Pitivi’s code. Thankfully though, Alexandru Băluț has been filling the gap with a ton of refactoring work: around 150 commits! That took a fair amount of time to review and merge, believe me. Besides code cleanup, he also finished the port of the viewer to a cluttersink, fixed fonts and theme colors detection for the timeline (so it looks fine even if you’re not using the Adwaita GNOME theme).

Alexandru took the opportunity to not only fix some bugs, but also do some visual refinements on the timeline ruler: it now shows hours and miliseconds only when needed (depending on the zoom level) and subtly grays out units that did not change from one “tick” to another, so your eyes can focus on what actually changed:


More interestingly though, with the limited time available to me, I helped prepare Pitivi’s 2014 fundraising campaign. It involves a huge amount of groundwork from an administrative and marketing point of view. It’s been months in the making.

  • I’m glad that Mathieu and Thibault were able to spearhead the work of setting up the infrastructure, preparing the majority of written materials and setting up their legal and financial relationship with the GNOME Foundation.
  • Huge props to Fateh Slavitskaya and Bassam Kurdali for the great work they put into making the fundraiser video (I’m a filmmaker, believe me, I know how hard and time-consuming it is to get this done right, especially when you have voice-overs and 3D animation involved. Oh, and all the editing was done with Pitivi, VFX with Blender). Thanks to Thomas Vecchione for cleaning up the voice recordings and doing proper sound mixing for the video, I definitely can hear the difference.
  • Thanks to Oliver Propst for drafting initial contents for the FAQ and various emails that we had to send for outreach! It is always easier for me to start from existing contents rather than stare at a blank page (you could say I hate reinventing the wheel :)

And thanks to the 300 backers who believed in us and broke the 7000 euros bar in five days since the launch! This is a great start—it could pay for two months of full-time work for one developer such as Mathieu—but we need to reach the minimum of 35 000 and the target of 100 000 if we really want to achieve the goals we’ve set. Get involved and spread the word!

You may also be interested in the following blog posts that did not show up on Planet GNOME (but are visible on Planet Pitivi):

Oh, and besides our G+ page, we’re on Twitter now. I reclaimed control of our “brand” by kindly asking Twitter’s legal department (yes, really). Until now, the @pitivi account was held by someone unknown to us, inactive and unreachable since 2010, so it was not helping anybody:


It is now linked from the main website alongside other social gadgetry.

Also, some upcoming events:

February 26, 2014

Using GStreamer to make smooth slow motion!

This is a very good example of what our developers can do! There has been some preliminary work on bringing slow and fast motion to GStreamer and Pitivi, and a plugin has been created to allow for frame interpolation, which means you and I with our regular 24 frames per second cameras will be able to get smooth slowmotion from Pitivi in the future!

All that work has not yet been merged and thoroughly tested, and we need your help to make it happen!

To help you understand the difference between regular and smooth slowmotion, here is a video showing both types side by side, created by Alexandre Prokoudine. The difference is quite stunning!

Slowmo video effect with GStreamer from Alexandre Prokoudine on Vimeo.

February 25, 2014

Votes: a tool of engagement and development.

During the creation of the campaign, we debated what kind of perks we should offer. The thing is, we are not t-shirt creators, we are software developers and UI designers.

We believe people who give us money do so in order for us to develop a good software, and thus we tried to focus on perks that made real sense. What could we offer to the community that would help us in making the software that they truly want? Our answer to that question: a voice, simple as that.

Though we already have a very active community and listen to feedback from our users, we were missing a way to quantify the priority of feature requests for the people to whom our software matters enough to sponsor our work.

We decided on two types of perks we would offer: invitations to hangouts organized monthly (we'll tell you more about that in a future post), and the subject of today's post, our voting system!

We wanted to grant the possibility of voting to anyone who donated, from the lowest amount available, and decided to weigh the vote proportionally to the amount given, with steps at which the curve flattens a bit, to make sure people who can't donate 300 euros still have a reasonable chance to have their voice heard.

Later I'll post implementation details for those interested, on my personal blog. Suffice to say that it works, and more exciting that people are already making good use of it!

This brings me to the exciting news we want to share: we made the current vote results public! Obviously, as we're in the early stages of the campaign, they're not nearly as significant as they will be later, but we think it's already interesting data, and you can have a look at them live right now .

Now to our own analysis of the data so far:

The first exciting figure for us is that even though we're not yet guaranteed to reach a funding point that can put vote results into development (you can help us get there faster), one third of our backers already took the time to go through the form and rate features on the 0 to 10 scale, and we clearly expect that ratio to grow if we reach the 35,000 bar.

We interpret that as a sign that our voting system answers a real demand. This figure is a clear success in our effort to create sustainable community engagement to support responsive and dynamic Pitivi development, alongside the growing number of people who choose to put their faith in us and donate.

Some points in the feature ranking results caught our attention:

  • The clear first place of hardware accelerated decoding and encoding. This is really interesting to the engineers among us, who already salivate at the possible prospect of implementing it!

    It also goes to show that performance is critical to people using video editing software, and reassures us in our architectural choices: the decision to ally with GStreamer means a lot of the heavy lifting is done as part of a partner project that doesn't have to be written by Pitivi developers from scratch. Instead, we contribute to GStreamer while also reaping the huge benefits of it -- and that means we can focus better on the video editing side of our code (making sure dynamic pipelines work with hardware-accelerated decoders/encoders, adapting and extending our integration test suites to ensure it keeps on being true)

  • The very pragmatic second place of copy paste, a small but oh-so-helpful feature, which goes to show that our backers are sensible, productivity and detail-oriented people.

  • The low ranking of Windows and Mac ports, which is certainly due in part to the fact that awareness about our campaign is pretty much limited to the Free Software community for now.

  • Finally, something we don't really know how to interpret on the spot, but that is interesting to remark nevertheless is that the three last spots are occupied at the time of writing by external project formatters, such as Final Cut projects.

I'll repeat that these rankings are absolutely not definitive, as already existing backers can change their votes and new backers should hopefully continue to give their opinion on what matters to them.

The conclusion is: "Don't like these rankings ? Donate and you can contribute in changing them!"

We're really interested in your analysis of these early results, and hoping that discussion will occur about them in the comments section or on our IRC channel (#pitivi on freenode)!

Thanks for reading, the Pitivi team

February 21, 2014

Give some love to Pitivi !

Today we're thrilled to announce a crowdfunding campaign to support the development of Pitivi!

We have made the choice not to use one of the major crowdfunding platforms such as kickstarter for multiple reasons, and instead partner with the GNOME foundation, which is ideologically aligned with us and will support our financial infrastructure.

We are proud of that partnership, as we share their objective of "creating a free software computing platform for the general public", and the foundation is excited as well:

"GNOME is proud to host the Pitivi campaign. Pitivi fills a real need for stable and approachable high quality video editing. Its software architecture and UI design share the same sleek and forward-thinking approach that we value in the GNOME project." — Karen Sandler, executive director of the GNOME Foundation

With that campaign, our aim is to provide everyone with a rock-solid Free Software video editor, based on the awesome technology that is GStreamer. We have spent a lot of time working on the campaign website, and it holds a lot more content than a simple blogpost could.

We know that what we want to do is the right thing, and requesting money for quality and stabilization first is the correct and honest thing to do. We obviously encourage you to donate to the campaign, but we also hope that you will be willing to spread the message, and explain why what we do is important and good.

Free and Open Source video editing is something that can help make the world a better place, as it gives people all around the world one more tool to express themselves creatively, fight oppression, create happiness and spread love.

Hoping you'll spread the love too, thanks for reading !

February 15, 2014

Applying for a GSoC project is all about early involvement and commitment

This year, Pitivi‘s focus for GSoC projects will be a little bit different than in 2013. As you can see in our preliminary ideas page, there is much less GStreamer (or GES) work involved, as we tried to focus on Pitivi UI work — easier, concrete projects, mostly only in Python. Most of the hardcore backend work we needed to accomplish was done throughout 2013. Of course, there are still some hardcore project ideas around if you feel like you’re up for a challenge. Anyway, the list of ideas is just that: a list of ideas. We’re more than happy for you to come up with your own ideas (thinking outside the box is a positive trait, feel free to impress us).

More importantly, here’s how our approach differs this year:

  • We changed the application “procedure” (see the “How to apply and get started” section on the ideas page). Essentially, “discuss your ideas with us” has become step #3 instead of step #1. The first steps are now get your build working, test and use the application, figure out what you love and hate about it, and then start contributing some fixes immediately. This came out of the realization that this is what we actually tell everybody who shows up on IRC asking “I don’t know what to get started with as a contribution”: get the dev version, use it, then you’ll certainly see things you want to improve to get your feet wet.
  • Like one of the maintainers of Inkscape once said, I will not believe anything you write in your GSoC application. Your formal application is only 10% of the equation. We will base ourselves 90% on your involvement and demonstrated ability to contribute code to Pitivi. The more good-quality patches you’ve made, the more chances you have. As such, we expect you to start getting involved in February (March at the latest). If you only start hanging around by the time GSoC application period starts, you will need to work very hard to convince us that you have what it takes.

January 29, 2014

Presenting and hacking Pitivi at Pycon 2014

Pycon, or what I’d call the “main Pycon” (vs one of the sub-Pycons), has traditionally always been held in the United States of America. This year, it will be held in Montréal.


The most astute among you might have noticed that Montréal (Québec) is not actually in the USA (because trying to capture Québec City during a snowstorm on New Year’s Eve is a terrible idea).

Since Montréal is my homebase (and Pycon happening there might be the event of a lifetime), I decided to showcase… you guessed it: the new version of the Pitivi video editor.

  • I will be making a “scientific congress”-sized poster (122×122 cm, that’s 4×4 feet for you southerners). I enjoy distilling marketing contents into visually compelling print materials, so I’m pretty excited about making an unconventional, jaw-dropping poster. I’ll be using some Pitivi donation money to cover the printing costs (around 25$ according to UQÀM’s estimates, other places start at 90$…). If you have ideas of things I should have on the poster (besides nice charts/graphs, screenshots and artwork), feel free to comment.
  • I won’t be just talking in front of an unusually large piece of paper: it will be a live demo booth with Pitivi running in front of the poster (maybe I’ll need to get something better than a netbook…).

Besides talks, tutorials and poster sessions, Pycon also has sprints (which, as I understand it, are what I usually refer to as “hackfests”). So I will most certainly be looking to host a Pitivi sprint/hackfest from April 14th to 17th.

If you are attending Pycon this year, I hope you will drop by to say hi, try out the coolest pythonic open-source video editor out there or get started hacking on the code!

January 20, 2014

Announcing pitivi's fundraising campaign !

Our team

I've been a part of the Pitivi story on and off since three years now, whenever I could find time really. I've loved every moment I've spent in the community, I've made friends, I've learnt good engineering practices, how to fit in a team, how to communicate clearly, and so much more I can't even start to list.

Not gonna tell the whole story because that would be boring to write and even more to read, but eventually and naturally I became a maintainer alongside Thibault and Jean-François. Jean-François has been around the project for 10 years now, he's awesome, a really dedicated guy. Thibault and I are friends since a long time, well before I started programming, I've been his padawan for the best part of my initiation to programming and Free Software, and he's a great Jedi !

Recently, Alexandru Balut has also started to work with us again, I don't know him as closely as I know Jeff and Thib, but he's commited so much things in the last two months that we've had a hard time reviewing it and preparing the campaign at the same time ! I don't know him as well on a personal level as I know Jeff and Thibault, but I like working with him a lot, he makes great and clean patches and has a seemingly boundless dedication to cleaning up the code and making it elegant.

All this to say I'm proud and happy to be part of such a team. Free Software's most important asset isn't the code, the bug trackers, the continuous integration servers, it's the people, and these folks are great, I can't stress that enough.

Our project

You might have guessed by now that our project isn't to grow genetically modified potatoes in the Southern part of Italy, even though that seems like a compelling idea at first sight. Give it a second thought and you'll realize the hygrometry of that region is absolutely not appropriate, give it a third one for good measure then forget about it.

I'll briefly explain what it is that makes of the Pitivi project the most exciting open source video editing project in my very humble opinion. The reason goes down to our design choices. We've played the long game, and based ourselves on the gstreamer set of libraries and plugins. For a visual and greatly simplified explanation of how that choice is a good thing, you can refer to this animation, then have a look at the impressive list of plugins that we can tap into. GStreamer is where most of the companies interested in open source multimedia invest their money and their time, it's where most of the exciting stuff happens and it's definitely where an ambitious video editing application has to look at.

We also have made the choice of clearly splitting our editing core, our model, from our view, and made it a library, with an awesome API, gstreamer-editing-services, directly usable from C, C++, javascript, python and every language supported by introspection, and possibly any other language provided someone writes bindings for it. That choice was the right one, decoupling components always pays off in the long term, and we are finally starting to see the benefits of that choice: Pitivi has seen its size divided by two, while gaining in stability. This makes it much easier for new contributors to come in, and for us to maintain it.

tl; dr: GStreamer rocks, and GES is great. With that said, we are aware that the stabilization is not yet over. Pitivi is in a beta state, and it still needs intensive work to make it so we kill the bugs and they never come back. To do this, we must extend our test suites, we must continue collaborating with GStreamer devs, we must create better ways for users to share with us failing scenarios. For all this we've got great ideas, but what we miss is being able to work full-time on the project, which basically means we need money, for reasons I don't think I have to detail !

I'm afraid this might sound a little boring, as we all tend to be more attracted to feature promises and shiny things, and that's obviously what we all deserve, but I think that's not what we need right now (hope I got the quote right). Fortunately we estimate that phase to be around 6 months long for one person full time, we did *a lot* of the groundwork already, and we just have to expand on that, and track the corner cases cause the devil is in the details, and he knows how to hide damn well. After that, we will be ready to unleash GStreamer's power, and come up with great features in no time, and ride on the work of others to get for example hardware acceleration basically for free. From that moment, when we'll have released 1.0, things will get seriously real, and our backers will be able to vote on the features they care the most about. I've worked on the voting system and I think it's a great thing to have, I'm really impatient to see it used in real life (and hopefully not break), I think I'll write a more technical blogpost on its implementation.

How you can help.

I'm writing this the day before launching the campaign, and I have the website in the background, taunting me with its "0 € raised, 0 backers" message. Fortunately I also have the spinning social widgets to cheer me up a bit, but it's not exactly enough to get me rid of my anxiousness. I know that what we do is right, and that requesting money for stabilization first is the correct and honest thing to do. Obviously, I hope that you will donate to the campaign, but I also hope that after taking the time to read that rather lengthy blogpost in its entirety, you will be able to spread the message, and explain why what we do is important and good. Free and Open Source video editing is something that can help make the world a better place, as it gives people all around the world one more tool to express themselves, fight oppression, create happiness and spread love. Hoping you'll spread the love too, thanks for reading !

January 04, 2014

Scratching some Media Library itches

Besides looking for a job, 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.


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:


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.

November 24, 2013

Wanted: documentation specialist

The Pitivi project is looking for someone who loves teaching/writing, to fill the position of “documentation specialist” among our team! The documentation specialist will be responsible for updating our fantastic user manual (online version here) based on release notes of 0.91 and 0.92 as well as your own imagination/ideas for improvement.

cat writing

The user manual is written in Mallard, but I can even accept contributions in plaintext (I would then do the markup myself). You only have to write it in English; other languages are handled by the hyperactive GNOME translation teams. You will receive:

  • No pay
  • No company-provided car, gym or insurance
  • Praise, hugs, possibly some beers at events such as GUADEC
  • Something great to put in your résumé/CV as a technical writer and contributor to open-source
  • The feeling of a job well done in a project that matters for the world
  • An autographed biography of Richard Stallman in French, if you’re into that sort of thing. I’m not even kidding, there’s a guy actually offering that as a perk on the Internet.
  • A gentle entry into the world of contributing to Pitivi if you want to go further

Apply now on #pitivi on irc.freenode.net !

November 04, 2013

Pitivi 0.92 and the wandering opensourcerer

The past few weeks have been pretty crazy.

At the last minute, I ended up going to the GStreamer Conference in Edinburgh, thanks to the GStreamer project sponsoring my attendance. As always, it was a fantastic event and it was great to meet up with old friends and see great topics being discussed. I was pretty impressed by the amount of attendees too. I’m feeling guilty for having missed good talks while being dragged into hallway discussions or being hammered by jetlag, but our pals at Ubicast recorded everything so I should be able to catch up later. My good friend Luis summarized the event much better than I could, so I won’t go into detail here. Except that Thibault won a bottle of whiskey and was unable to claim it, so I picked it up and brought it back for him (I don’t hack on GStreamer itself, so I don’t need the whiskey):


After gstcon, I embarked on a pretty hectic journey throughout Europe, with the goal of prospecting sustainable development opportunities and to eventually crash at Mathieu Duponchelle’s home in order to spend time on Pitivi together.

shadow of the colossus horse ride

Since I’m someone who tends to plan and optimize everything, hopping from city to city in a semi-improvised way over the past two weeks has been somewhat stressful. Especially the part where I found out the hard way that some capitals have their public transportation system to the airport shut down at night, or the part where I had to sleep on the floor in the entrance of the airport that was also closed at night even though you have flights departing before sunrise. That was fun. It is also a significant amount of transportation costs piling up (even though I’m an expert at minimizing them), so if you’d like to help offset some of the costs resulting from our current Pitivi activities, please feel free to tip a few bucks ;)

Managing and maintaining an established open-source project does not just mean coding: there is a lot of administrativia and planning involved, which has been consuming my free time lately. After discussions with Karen and Jim at the GNOME Montréal Summit, the post-GSoC stuff to deal with, the big research project I’ve been tackling and the research around the infrastructure needed for it, all on top of paperwork needing to be done at home during my absence, there was pretty much no time left for me to look at code. I somehow still managed to squeeze in a few commits to fix some blockers and a few trivial things, but that means that larger projects (even something as “simple” as reviewing a new set of icons) had to be renegotiated in my TODO list.


While staying with Mathieu in the past few days, we made some good progress on a big project coming up for Pitivi (more on that later) and released 0.92 to provide some fixes and polish over the earth-shattering 0.91. As you can see, this release comes just one month after the biggest release in years, so we are indeed aiming to get back onto a “release early, release often” cycle now. We hope you like it.

October 05, 2013

Pitivi 0.91 “Charming Defects”

And so it has come to this.


A few days ago, we stealthily published the tarball of the first Pitivi video editor release based on the GES engine. Incredible but true! 0.91 is finally out! In case you were living under a rock for the past two years, this release is the result of a major rework of the entire Pitivi architecture, and as such it is considered an “alpha” release. From a very (VERY) high level, it includes:

  • Replacing the core of Pitivi by GES; 20 thousand lines of code removed
  • Porting to GStreamer 1.x
  • Porting to GTK+ 3.x
  • Replacing GooCanvas by Clutter for the timeline
  • An automated UI test suite, with many checks for mission-critical parts
  • Fixing hundreds of bugs
  • Implementing many new features
  • UI polish all over the place
  • Refactoring pretty much the entire codebase

Since 0.15.2, over 1300 changes have been committed in Pitivi alone. That’s not even counting the incredible amount of work we’ve done in GES and GStreamer. See the details in the 0.91 release notes.

I would like to extend my deepest thanks to all the people who, through their contributions and the trust they have put in us over the past two years, have helped us achieve this milestone. The adventure continues however: we need your involvement more than ever to continue on the path we have set! If you’ve been shy about getting involved because of the huge amount of architectural changes we were going through, now is the perfect time to start contributing on fresh grounds.

Oh, and one more thing: “PiTiVi” is now known as “Pitivi”. Our website, documentation and infrastructure have been updated to reflect this small branding adjustment (the only part I didn’t update yet is the logo image). Moreover, in order to support open standards, free ourselves from YouTube (or any third party, really) and to make it easier to transition to a responsive design (more on that later), we now use HTML5 videos in open formats all across the website. Woohoo!

September 04, 2013

Fix it thrice

Some of you may be familiar with the good old “fix it twice” adage: fix the problem and then ensure it never happens again.

Last year, when I made Pitivi’s automatic backup feature work, I requested someone to write extensive automated tests for it (with Dogtail), so that I could feel confident about this feature never being broken again, even if it underwent massive refactoring or if everything else changed around it.

Turns out that it did break again this year. After the port to GES Assets and GES Project, loading a backup project would not actually populate the media library and timeline! The tests were not strict enough to check those kinds of “details”, so this flew completely under the radar.

I thought I’d fix the whole thing again… however, in addition to not wanting to see it break again later I wanted to be more efficient, so I did things differently this time: test-driven programming. I refactored our automated UI tests, made them much more exhaustive and sadistic, made them fail, and then spent time fixing the code until the tests would pass. And whenever I found another bug in that branch, I wrote tests to fail before I would fix the issue.

Now it works, and I can be confident about it again. I have effectively fixed it thrice.

Testing a bulletproof vest, 1923 - cropped

Why do I care so much about making it bulletproof? Because projects are Pitivi users’ most important data. It is critical to ensure their safety through unsaved changes warnings, disaster-proof automatic backups, backup restoring that actually works, and preventing accidental overwrites: Pitivi tries to gently steer you away from overwriting important stuff (you need to go through the “Save As” process and confirm the overwrite, if you consider the restored version to be the correct one). All that, and much more, is part of my automated tests.

Other recent stuff

Software Center description

I’ve been watching closely as Richard Hughes put forth a proposal for a new specification to describe applications in the GNOME Software Center. Here is what I wrote for Pitivi.


A video editor that aims to appeal to hobbyists and professionals alike, with a strong focus on usability, efficiency and quality


Integrating well with the GNOME desktop environment and other applications, Pitivi sports a beautiful user interface designed to be powerful yet easy to learn.

With a non-modal editing workflow, a framerate-independent and playhead-centric timeline, Pitivi allows you quickly and accurately trim, split and review your scenes. Pitivi’s ripple and roll editing features allow spending more time on storytelling and less time on “pushing clips around”.

Some other features include:

  • Accepts any file formats supported by the GStreamer multimedia framework
  • Can animate hundreds of special effects and filters with keyframable properties
  • Ability to set custom aspect ratios, framerates and rendering presets
  • Easy to use crossfades and SMPTE transitions
  • Multihead-friendly with detachable user interface components

Hopefully this should capture the essence of what it can do.

On a sidenote, we currently use INTLTOOL_XML_RULE to make this file translatable, and I heard that’s terribly uncool. Please help us by providing a patch to make it work using itstool instead!

New project render dialog, filesize estimates

It feels great when you pick up a patch you wrote “blindfolded” four months ago (back then, it was impossible to test) and see it “just work”: I had this small “Knuth” moment when it not only rebased cleanly, but worked as intended with only one or two Python syntax adjustments. The patch in question is a little feature I wanted to make it easier to figure out if the resolution/quality/bitrate settings I chose are getting me to get the kind of filesize I want: output filesize estimation.

2013-08-31 23:26:09

The algorithm I devised is naïve, but does the trick for the vast majority of cases. I cheat a little bit by waiting long enough to have gathered enough data for prediction to be somewhat significative, and by fuzzying the estimates — you’d be surprised how innacuracy can improve perceived accuracy!

While I was doing that, I started playing around to make the rendering dialog prettier and more informative. For starters, the “Rendering movie” header felt wrong for various reasons, and this became quite apparent once you add the “Estimated filesize” text right below it. Rewording the header to say something like “Your movie is now being rendered and encoded” didn’t help much.

That header was basically still duplicating what was in the window title. I pondered what could be put in its place; emptiness would look a bit silly, as the dialog would just be a titlebar, a progressbar and buttons. I then decided to put some informational text for educational purposes: few people actually understand what factors influence the encoding performance (or the speed at which your project renders), yet many people are surprised when it takes a long time, so I thought I’d add a contextual tip:

2013-09-01 00:14:09

2013-09-01 00:12:17

“What’s that ridiculous amount of empty space below the progressbar”, you say? A bug in GTK, it seems. I spent quite some time changing things all over the place until I discovered that making the window non-resizable “fixes” the issue. My guess is that GTK3′s size calculations are based on the height of the window before its width would be set by the “default width” property in my dialog… and then the height would never shrink. How odd. Anyway, the new text paragraph does prevent the window from being too narrow now, so the dialog doesn’t really need to be resized by users. Here’s how it looks like now:

2013-09-01 09:54:22

Certainly more useful than what we started out with, isn’t it? Paying attention to little details like that — having empathy for your userbase — allows creating what I call “intuitive” or “self-documenting” software.

Brace yourselves, 0.91 is coming

Oh, did I mention that Pitivi actually renders now? Well yes, that’s because we (especially Mathieu) have been doing a massive amount of work all across the GStreamer, GES and Pitivi stack to make this happen.

We have been incredibly busy in the past few months, pushing really hard to finally get a release out of the door by the end of the summer. In recent times, we have committed around 250 changes in Pitivi, 180 in GES, and I don’t know how many hundreds in GStreamer. My spare time was spent swimming through emails, having many technical discussions on IRC and dealing with hundreds of bug reports/issues/TODOs.

Working hard at GUADEC

Working hard at GUADEC

With a few issues remaining (mainly related to scaling in videomixer), we’re now at the point where stuff… works. Audio mixing and video compositing are back (and keyframable), effect properties are keyframable, deadlocks and crashers are pretty much gone (as far as we can tell), etc. I’m starting to run out of bugs. Amazing!

We can finally make an alpha release in the near future.

How you can help with 0.91

0.91 will be our first alpha release based on GES. It’s a very exciting release with many improvements, bug fixes and new shiny things. You can help by:

  • Trying out the development version right now. Come have a chat and let us know how well it works for you!
  • Documenting. The user manual is quite outdated right now (it is still based on the 0.15 featureset). We need writers!
  • Helping me prepare the huge release notes. If you’re crazy enough.
  • Creating simple and lightweight test projects for Mathieu
  • Helping with packaging efforts (ensuring this can be packaged nicely, fixing build/setup issues etc.). Two issues you can tackle immediately are:
  • Revising the existing bug reports and doing a big triage cleanup
  • Hacking! As usual, we’ll be happy to help you get started.
  • Spreading the news

July 26, 2013

Prague, Brno, London, GNOME + Pitivi

Guess where I am going?


That moment when you think “jeez, I wish I could bring less equipment with me for once”…

To the end of the world and back

To that event “where nobody goes anymore”. I’m not entirely sure what’s in the air this year. I’m not talking about what’s been going on in the industry and the public perception of GNOME in various circles, that might not be the whole picture. There may also be something else I’d like to assess while I’m there. While I deeply disagree with the use of sensationalistic and “demotivational” titles like Lionel’s last blog post, some of those concerns are quite valid and important to our sustainability. I, for one, am looking forward to participating in the ecosystem BoF.

Taking it easy. Maybe.

  • Before GUADEC, I will spend a few days visiting Prague with friends. I’m pretty bad at this “taking vacations” thing however; my obsessive self might spend time trying to fix some Pitivi issues instead of being a good tourist.
  • I will not be working while at GUADEC. I will be devoting my mind to attending and giving (two!) presentations, interacting with new and old community members and having fun (might even try playing futbol this year, but I fear Bastien will kick my arse for all those years of pestering him with bug reports).
    • I might have a twisted definition of “fun” though: I have 30+ items in GTG tagged “@guadec”, which means I will be chasing down people all over the place. I’m looking at you, Allan, Bastien, Karen, Cosimo, Benjamin, Zeeshan, Jon, Lionel, Jakub, Sebastian, Tim, Edward,… gosh, the list is endless. I’m forgetting a ton of people. I also have to catch up with Igalians, Lanedians, Pitivites… the fact that I didn’t mention your name doesn’t imply that you’re safe.
  • Unfortunately, special circumstances will call me back to work in the last few days of GUADEC. I will be in London on the 8th and 9th.

If you want to catch me in Prague or London, let me know.


All the equipment shown previously fits in these two carry-on bags. Nekohayorganization at its finest.

Pitivi happenings

  • Pitivi hackfest @ GUADEC 2013. Be there.
  • I think I’m at the point where I really need someone to succeed me in the role of writing the Pitivi user guide and release notes for the upcoming release. Please get in touch if you love writing and are interested in helping out. If you’re at GUADEC, we can even get started together!
  • Interesting results for the 2013 Pitivi user survey, pretty much confirming what I’ve been thinking for many years. Hopefully I’ll touch upon that in my talk.
  • For those interested in vastly improved playback performance with super-high-definition footage: take a look at our spec for proxy editing and let us know what you think. Anton, one of our GSoC students, is working on laying the foundations for that.
    • I haven’t had time to blog about the big question around video codecs, but I’ll get to that eventually. Grab me at GUADEC to discuss this, if the feature matters to you or if space-performance tradeoffs are a problem that you find interesting to think about.
  • Brace yourselves, a new website is coming. It’s friggin’ awesome. Not releasing it yet though, so you can relax for now.
  • Mathieu Duponchelle made a small script to do special video compositing of a dance clip… in ten minutes! That’s how powerful GES is: it’s not just about making full-fledged video editing apps, it’s also a powerful scripting and automation engine. See his explanations (with source code!) here.

June 25, 2013

2013 open source video editor user survey

What was initially planned as a one-question referendum for Pitivi users (how critical is it for us to have perfect xptv import on the upcoming release) became a full-fledged survey to give us a clearer picture of what users care the most about these days. If you’re a fan of Free Software and video editing, please take a few seconds to fill this survey. Please please share this with everyone you know who is interested in Free and Open-Source video editing. Thanks!

Version française: la prochaine version de Pitivi approche rapidement. Suite à une discussion concernant nos priorités à court terme afin de pouvoir sortir une nouvelle version au cours de l’été (avec un peu de chance), nous avons concocté un court sondage sur votre utilisation des logiciels de montage vidéo libres. S’il-vous-plaît, veuillez prendre quelques secondes pour répondre à ce délicieux questionnaire, et n’hésitez pas à en parler à tous ceux autour de vous qui s’intéressent à l’édition vidéo libre!

June 08, 2013

Status update — new Pitivi timeline, GSoC projects, etc

Dear shareholders fans, here is the quarterly report from the frontlines of Pitivi, your favorite futuretrocyberpunk video editor.


A typical day in my life as of late

I will cover the following from a very high-level view (I’ll have to make separate blog posts to cover them in detail, there’s too much to say):

  • The state of our multimedia stack
  • Our new timeline canvas and how you can help
  • This year’s accepted Summer of Code projects
  • Upcoming GUADEC presentation

Also, a small announcement: for those who also want some shorter, less formal status updates and occasional feedback probes, you can look at the new PiTiVi G+ page.

Clutter timeline canvas

In preparation for the Summer of Code, but mostly just to help us and demonstrate how much of a badass he is, Mathieu Duponchelle killed our goocanvas-based timeline and redid the whole thing with Clutter. In two weeks. This is what it looks like at the moment:

The state of our multimedia stack

We fixed some initial bugs in GNonLin in Milan. Since then, further investigation revealed that most of the issues we are encountering are actually generic bugs in GStreamer. Mathieu is now working full time on fixing bugs everywhere in the stack. We hope to have something showable (beta) for GUADEC and a release this fall — as you can imagine however, I’m unable to make solid promises at this point.

There are still many things that we need to rearchitect in GNonLin, but that’s a story for another blog post.

We recently started using Github’s bug tracking tool to keep a more easily manageable list of issues we have to deal with in the development version. Please note:

  • This is not a replacement for GNOME Bugzilla. It is meant as a temporary measure for our extended development version, for stuff that is too small, fluid or uncertain to be filed as proper bug reports. Once we release, we’ll move remaining issues to Bugzilla. Upstream issues in GStreamer, once properly identified, are always filed in GStreamer’s (GNOME) Bugzilla.
  • We welcome your help in fixing or investigating these issues. There’s also an “easy” tag for those of you looking for bitesized stuff.

Stuff you can fix in Pitivi, right now.

If working on GStreamer and GES is not your cup of tea, we still have a ton of fun little projects for you to do on Pitivi itself, including:

  • A bunch of little nitpicks/papercuts for our Clutter timeline
  • During the port to Clutter, Daniel Thul helped Mathieu by rearchitecturing and fixing the timeline clip thumbnailer module. It works, but there are some remaining, significant performance issues. This is a great project if you’re looking for finite, concrete, self-contained work to improve performance with a very highly visible impact on the UI. You would get a ton of love points for this.
  • We have a title editor UI, but it needs some love. You don’t want us to ship with an unrefined UI, do you?
  • UI tests!

This Summer of Code’s projects

We have four students working on Pitivi this summer, thanks to GNOME kindly offering us an extra slot to be able to achieve our mission. Here’s our ambitious list of project goals:

  • General bug fixing in the entire GStreamer + GES + Pitivi stack, to be able to make a Pitivi release.
  • Motion ramping (keyframable fast/slow motion, allowing the speed of clips to be changed over time, ideally with smooth frame interpolation)
  • Finish the enablement of our new timeline layers management UI
  • Reimplement audio waveforms. Better, faster, stronger.
  • Video compositing
  • Proxy editing. I’m currently writing a design and API requirements brainstorming page to help plan this feature. I will share it in my next blog post, where I’ll present some of the dilemmas I’m encountering (particularly around codecs).

Presenting at GUADEC

Come to GUADEC and attend my presentation at the beginning of August. Plans are a bit fuzzy for the time being, but you can expect my typical award-winning presentation style. Also, as usual, we’ll be having a Pitivi hackfest there. Czech it out.

Fun with videomixer


When you've spent the whole week painstakingly fixing bugs, coding something just for fun is a welcome breath of fresh air. These last weeks, one of my areas of work has been the gstreamer "videomixer" element. It needed some love, and still needs, but I've been able to fix some of the issues we had. When we first ported gstreamer-editing-services and gnonlin to gstreamer 1.0, even the most basic editing became impossible. That was quite frustrating to say the least, and being able to do edition once again feels extremely good !

One of the great things with the extraction of pitivi's edition code to GES is that you can now write fancy scripts to make automated edition, and with a little luck you won't encounter a bug on your way. At the end of this article, you will find a video showing an example result.

There haven't been much tutorials about using GES, the only way to learn that is either looking at the examples on the git repo, or to directly look at pitivi's source code. With that blogpost I'm gonna try to present that cool library, while coding something fun. The idea from the script came from that video : http://vimeo.com/35770492, linked to me by Nicolas Dufresne. We won't be able to reproduce the most advanced bits of this video, as it also seems to be content-aware at some points, but we will make a fun script nevertheless !

Sounds sweet, where's the code ?

Looks fine, explain it now !

I'll select the meaningful bits, assuming you know python well enough. If not, this is easily translatable to C, or any language that can take advantage of GObject introspection's dynamic bindings.

First, let’s look at the main.

    timeline = GES.Timeline.new_audio_video()

This convenience function will create a timeline with an audio and a video track for us.

    asset = GES.UriClipAsset.request_sync(sys.argv[1])
    audio_asset = GES.UriClipAsset.request_sync(sys.argv[3])

This is part of the new API. Thanks to that, GES will only discover the file once, discovering meaning learning what streams are contained in the media, how long it lasts and other infos. Previously, we would discover the file each time we created an object with it, which was not optimized. request_sync is not what you would use in a GUI application, instead you would want to request_async, then take action in a callback.

Now, let’s look at createLayers, which is where the magic happens.

    layer = timeline.append_layer()

A timeline is a stack of layers, with ascending “priorities”. Thanks to these layers, we are able for example to decide if a transition has to be created between two track objects, or, if two clips have an alpha of 1.0, which one will be the “topmost” one.

    clip = layer.add_asset(asset, i * Gst.SECOND * 0.3, 0, asset.get_duration(), GES.TrackType.UNKNOWN)

This code is very interesting. We are basically asking GES to : create a clip based on the asset we discovered earlier, set its start a i * 0.3 seconds, its inpoint (the place in the file from which it will be played) to 0, and its duration to the original duration of the file. The last argument means : for every kind of stream you find, add it if the timeline contains an appropriate track (here, audio and video). We could have decided to only keep the VIDEO, but that was a good occasion to show that.

With that logic, we can now see that the resulting timeline is gonna be sort of a “canon”: one video mixed with n earlier versions of itself.

    for source in clip.get_children():
        if source.props.track_type == GES.TrackType.VIDEO:
    source.set_child_property("alpha", alpha)
    alpha = mylog(alpha)

Here, I browse the children of my timeline element, and when I find a video element, I set the alpha of an element inside it, and update the alpha. The log here makes it so each layer has the same perceived opacity at the end.

Afterwards, we create a pipeline to play our timeline, and if needed we set it to the render mode, that code is quite self-explanatory.

We now just have to wait until the EOS, or until the user interrupts the program.

I use Gtk.main() out of pure laziness, a GLib mainloop would work as well.

How does it look like then ?

I really hope this example made you want to learn more about GES, it’s a great library that lets you do awesome stuff in very few lines of code, we’re in active development and the best is still to come !

Here is the promised video:

Notice the code was only tried with mp4 containing h264, feel free to report any issues with other codecs on my github !

April 28, 2013

No more stuck rendering dialogs!

If you’ve tried rendering projects with Pitivi 0.15 or older, chances are you’ve encountered one of these dreadful situations where the rendering process would get stuck:

  • …at the beginning, with the progressbar saying it’s currently “estimating” — which was a lie that I corrected a little while ago.
  • …at the very end. Extra trolling points for having made you waste a huge amount of time to get a 0 bytes output file (if we’re lucky, that bug is gone).
  • …somewhere in the middle, because caps negotiation failed, some elements were not linked, GStreamer thinks you ran out of available RAM, or because you’ve been very naughty.

In any such case, the rendering dialog just sat there and smiled at you, as if everything was fine in the world. Well, no more:


Pitivi is going to give you the honest, brutal truth.

This is the result of a horrifying thought suddenly springing to my mind yesterday night: “Hey, what if the code was not even checking for errors in the pipeline when rendering?”

Indeed, it wasn’t. How silly is that! I have thus prepared a simple fix to improve the situation: catch pipeline error messages, abort the render (you really don’t want to ignore a GStreamer error) and display an error dialog. This will at least let people know that something is wrong and that they should start writing patches to GStreamer instead of accusing Pitivi of hurting kittens. You’d be surprised how many people can sit for hours in front of that stuck progressbar.

Before I commit the fix however, I would need your feedback on the usability of that dialog:


This is not terribly pretty, but it’s better than nothing. A few things to consider:

  • In that screenshot, all the text except the window title (“Error While Rendering Project”) comes from the GStreamer pipeline error message (the error and the error’s details). I know that the error details look ugly, but I suspect it wouldn’t be useful to GStreamer/Pitivi developers if we don’t have them “verbatim”. Maybe we could try to mangle the error details string (split using “:” and take only the first and last two items of the resulting list?) and encourage the user to run from a terminal to get better debug info, but that feels a bit backwards.
  • We should probably have some less-scary text to accompany the actual error details. Something that guides the user towards an action that can be done to address the problem (ex: reporting a bug). Maybe it can be placed between the header and the details (above the “qtdemux.c” line)? The problem is finding a universal text to be used.
  • If we consider the route where we suggest the user to report bugs, where should we point to? The Pitivi bugs investigation page? Pitivi bugzilla? GStreamer bugzilla? The distro’s bug tracker?
  • Let’s keep this simple, both visually and in terms of code/implementation.

What do you think? Is the current approach sufficient or is there something better that we can easily do?

Update: here’s an alternative dialog with some more comprehensible text, where the actual error (as seen in the previous screenshot) gets shoved under the rug by putting it in a GTK expander widget (clicking “Details” reveals the error’s details as above):


April 11, 2013

PiTiVi and the 2013 Summer of Code

This year will be a little bit different. In a rather unexpected turn of events, PiTiVi has been accepted as a mentoring organization but GStreamer has not. Fear not however, as GStreamer has no better ally than the PiTiVi team when it comes to pushing our favorite multimedia framework to its limits and beyond. As you may know, PiTiVi makes heavy use of the GStreamer Editing Services library and, in turn, GNonLin and the rest of GStreamer. With the switch to GES and the irrevocable shedding of our old skin, any backend work done for the sake of the PiTiVi project ends up benefitting GStreamer and other projects.

One way to look at things is that there is no such thing as a PiTiVi backend anymore. PiTiVi is a frontend that pushes the latest and greatest open-source multimedia technologies forward.

With the GES port nearing completion, this is the first time that we can truly say there are three interrelated components to contribute to. This new reality sets the tone for a different way to look at PiTiVi project ideas this year: you can finally…

Choose your character class

pitivi hacker style

Are you a ninja? A spellcaster? A tank? While most projects are a balance of backend and UI work, we know that some people prefer to lean more to one side or another of the continuum — that’s why I created a new visual notation for our ideas page this year. Instead of an “easy/hard” system (which would be inaccurate and misleading, as perceived difficulty is measured differently for everybody), we simply provided a visual indication of the expected involvement in the various components for a given project idea (for example, “PiTiVi: ◼◼◻◻◻ GES: ◼◼◼◼◼  GStreamer: ◼◼◼◻◻”). So if you were looking for something closer to a hardcore GStreamer GSoC project, you can spot ideas that might interest you here.

Not a programmer? You can help raise awareness about this. Maybe you know a brilliant hacker friend/relative or a top-notch computer science student waiting for a chance to make a big difference in the world. Tell that person about how cool and welcoming PiTiVi is and how getting involved is the best way to advance free, powerful and intuitive video editing for everyone!

September 03, 2012

KSE 0.1 released !

I just finished fixing the blocker bugs for the open source assets' manager KSE, and I pushed a release there : https://github.com/MathieuDuponchelle/Kerious-Resource-Editor on the branch 0.1.

I recorded this screencast to make a demo of the features included in this release.

I want to say thank you to Simon Corsin for his work on the windows port and manual management.

I'd be glad to see pull-requests on github, or comments, critics and feature requests here.

Here is the text of the video for those with no audio:

Hi, my name is Mathieu Duponchelle and I am glad to present you the first release of kse, which is
a tool to simplify asset's management written in python.

This release covers spritesheet creation, sprite naming, automatic sprites detection in an existing spritesheet,
animation referencing and tons of other stuff.

Spritesheet creation.

Let's create a new spritesheet, and start importing resources.
First we create what we call an "atlas", specify its width and height and the location of the resulting file.
Then we can specify the size we wish the next sprite to have, and start adding sprites by double-clicking.
Next step is to start naming all these sprites, for now the naming part is a bit tedious, but it works.

Animation referencing.
Another cool feature of KSE is that we can reference animations easily, using multiple selection.
Let's say these sprites belong to the same animation.

We now save the project, and have a look at the xml that was produced.

We can see that a simple xml parser could easily extract coordinates for a given name, here X.

Automatic sprite detection.

Let's now say that we want to use an already existing spritesheet. I have this one, which will make for a good
A really cool feature is automatic sprite detection, which can be configured with this button.
Match-size will specify the desired width and height multiples for the resulting sprites.
Now let's try it out !
As you can see, KSE detected the sprites and automatically highlighted them. However, if the position or size
of any sprite does not match what we intend, we can easily resize and move them using the mouse or, if we want
a more fine-grained control the comboboxes that we have here.


With some friends of mine, we already developed a space shooter using KSE.
This helped me finding out the features that were most needed.
It can greatly improve the collaboration between designers and developers, by reducing the number of back and forth
trial and errors, allowing the programmer to only parse the xml file looking for the sprite or the animation name,
and thus not having to hardcode coordinates, which is an obvious advantage, and allowing the designer to try things
without having to modify the code or asking the programmer to do so.

KSE now works on both linux and Windows, it has not been tested on OSX yet.

My thoughts for future features are listed in the poll on the right-hand side of the blog, don't hesitate to comment if you have other ideas/remarks/critics. Thanks for watching !

July 17, 2012

Selectable layers

Finally, it’s done. Thanks to some hints in the source code of Jokosher I was able to implement selectable layers in PiTiVi.
The problem is that some widgets in Gtk+ don’t have gdk screens. This means that you can not change their background color, which is a really important thing for showing if a layer is selected or not.

The solution for this problem is to derive the widget from EventBox. This gives the possibility to modify the background using the modify_bg(…) function.

Based on that work I was able to implement proper selectable layers. So if you click on a layer control widget or a
layer in the canvas now, the layer gets selected and changes its background color. You can see a selected layer in the following screenshot. Note that I disabled all non-functional widgets (the entry, sliders, buttons…) for now, so this isn’t the final look.

Selected video layer

This work builds the base for more nice stuff like drag and drop layer reordering or menu actions on layers. I’ll cover these in the next post.

June 27, 2012

Week 1 & 2

Back from holidays I worked on including the newly created widgets in the user interface.

Before all video or audio layers only had one label. Now we want one widget for every audio/video layer. Therefore I had to change the internal logic quite a bit.

Afterwards I noticed that hard coded layer heights didn’t work well with the new widgets. The more layers you had the more you saw that they weren’t properly aligned. My solution for this problem is that I adjust the layer height to the height of the layer control widget. This also gives us basic folding support as well.

The current UI now looks like this:

PiTiVi screenshot with new layer control widgets.

You can find my branch on github. I’m also happy to hear your comments, hints or whatever you want to say :)

June 19, 2012

Week -1

Because I didn’t have time to work on my project after the official start because of exams and vacation I started working the weeks before.

The first part consisted of designing and implementing new control widgets for layers with more functionality. After some inital atteps that didn’t look good, nekohayo (btw my super helpful mentor) jumped in and helped me to review and improve the designs. We ended with these mockups in Glade:

Then I started implementing them using pygtk. Unfortunately we still have to use Gtk+ 2 so we don’t get the cool new style. Furthermore I didn’t yet find a way to make a container widget selectable, so I added the ‘Delete’ button to delete layers. However this should be gone in the final version.

The next step was to use these new widgets in the PiTiVi interface. I’ll cover this in the next post!

May 20, 2012

Advanced Layers for PiTiVi

I’m happy to announce that my project proposal for the summer of code 2012 has been accepted!

I’ll be working on creating an advanced layer system for the PiTiVi video editor under the umbrella of the GStreamer project! Thanks to everyone who helped me!

About my project:

The current approach of layers in PiTiVi does not provide more functionality than grouping video and audio sources in different levels. I want to add an advanced layer system to the PiTiVi video editor to improve the video editing workflow and user experience. This is based on two ideas. On the one hand putting more functionality into layers helps to avoid repetitive tasks like adjusting volume and panning, muting or applying effects to clips. On the other hand improving the management of layers by offering to name, reorder, fold and resize them makes working with layers more convenient.

April 27, 2012

Getting video properties out of GStreamer

GStreamer is a pretty nice piece of software for handling almost all of your multimedia needs but the time will come that you get to the point where seemingly easy things are pretty hard to figure out. I hit this point when working on the thumbnailing code of PiTiVi and realizing that there is no […]

October 28, 2011

Homework :)

I had plenty of other things to do today, so I iterated from that code :
http://encrypt3d.wordpress.com/2007/06/19/level-order-traversal/ , which I found pretty elegant.

Function of the code:

Breadth first tree traversal, display the level and show if the node is the first one of its level (starting from the left).


As it was homework, I had to give the is_first property. What would be better would be to display the order of the node in the level.
Also, wondering about the best way to display a tree.
May'be starting by the bottom ?


typedef struct s_infos
  int is_first;
  int level;
  t_btree *node;
} t_infos;

t_infos    *create_new(t_infos *par, t_btree *n, int first)
  t_infos    *q;

  q = malloc(sizeof(t_infos));
  q->node = n;
  q->is_first = first ? 0 : 1;
  if (par)
    q->level = par->level + 1;
    q->level = 0;

void    levelorder(t_btree *p,
        void (*applyf)(void *item,
                   int current_level,
                   int is_first_elem),
        int *size,
        int *qptr)
  t_infos    **queue;
  int    *tab;
  t_infos    *q;

  q = create_new(0, p, 0);
  tab = malloc(sizeof(int) * 100);
  queue = malloc(sizeof(t_infos *) * 100);
      applyf(q->node->item, q->level, q->is_first);
      queue[*size] = create_new(q, q->node->left, tab[q->level + 1]);
      *size += 1;
      tab[q->level + 1] = 1;
      queue[*size] = create_new(q, q->node->right, tab[q->level + 1]);
      *size += 1;
      tab[q->level + 1] = 1;
      q = queue[*qptr];
      *qptr += 1;

void    *btree_apply_by_level(t_btree *root,
                              void (*applyf)(void *item,
                                             int current_level,
                                             int is_first_elem))
  int    size;
  int    qptr;

  size = 0;
  qptr = 0;
  levelorder(root, applyf, &size, &qptr);


Let root be the root of the tree, and applyf the adress of a function returning void and using as arguments the data of each processed node, its level and its is_first property (Crap how useless is that ..) Also, t_btree is a classical node structure containing the left child, the right child and the data.

Also, today I coded a function that allows you to insert a data in a red black tree.
I'll try to post that  when I have time, it's a little longer but I think it's worth it.

September 28, 2011

PiTiVi 0.15 is out

The PiTiVi team is proud to announce the 0.15 release. This will be the last release using the "traditional" core/engine of PiTiVi. The next releases will be based on GStreamer Editing Services (GES) and should thus depart significantly from this release in terms of performance, features and stability.

Jean François did a great screencast that sums up what has been done during the last 2 years:

He also published the video of the 2011 desktop summit and PiTiVi/GES hackfest for your enjoyment:

All those videos are also accessible in HTML5 versions on the showcase page.

Thanks to everybody who made this release possible!

July 09, 2011

Weekly report number 6 and 7 for my GSoC

Hi everyone !

These last two weeks were pretty busy for me.
First off, last week I reached my mid-term evaluation goal, which was to load a GESTimeline with xptv projects thanks to my GESPitiviFormatter, then load a GESTimelinePipeline with the timeline, then connect it to the viewer in Pitivi, all of this using my python bindings for GES. This was a long sentence but quite a short job, and this was still pretty hacky.
Afterwards, I played around a little with projects, only to realize that I had a nasty bug with the interaction of effects and transitions, which obviously came from my formatter. This was in the middle of last week.

After this discovery, I moved in to another flat, and the end of the week was not really filled with working.

I started to tackle this bug by the beginning of this week, and I must admit it took me a long time to figure out where it came from (the respective priorities of transitions and effects, which determine which object is "above" and which is "under" had to be set in the appropriate way), and still longer to fix it : once I made out how everything had to fit together, I also realized that the calculating of the needs in terms of transitions had to be refactored, I needed to compare the sorted track objects one after another, and not the track objects belonging to the sorted timeline objects one after another. I hope I'm clear enough, anyway I had to add a function to the GESTrack API to achieve this, which makes me think I'll also have to update the bindings aha.

Also, during this week I broke my scooter, and that didn't help me in concentrating on my problems. It now lies in pieces in my yard waiting for me to fix it or for someone to steal it xD.


These bugs are now fixed, and I can now attack the rest of the integration with a free mind.

I will now explain you how to checkout my work and give it a try, if you find bugs don't hesitate to contact me.

This is if you don't use jhbuild :

First, you'll need pitivi. After that, you'll need the latest gst-python, then you'll have to get to my GES repository, which is at https://github.com/Mathieu69 as usual. You'll want to checkout the "integration" branch, autogen it *without* prefix (this is due to the CONFIGURED_PYTHON_PATH in pitivi, will fix that when I'll have time), make and make install.

To test the bindings : ipython, from gst import ges. If it imports, fine ! You're nearly done. Otherwise, mail me with the traceback.

Afterwards, all you'll have to do is go to my pitivi repo, and checkout the "intcheck" branch. Just switch to it, launch pitivi, and load a project *using the start up wizard*. You'll then be able to press play and profit :D You can also pause, undock the viewer, and that's pretty much all xD.

Anyway, what's interesting is to compare the playback between master and my branch, you'll be able to see the difference in smoothness ;) GES makes playback nearly smooth, it only lags a little when transitions start or if you think that a clip is way cooler with agingtv, chromium, color lookup table filter, vertigo TV, and whatever effect *at the same time*, where in pitivi and with my computer you can only see one picture every 2/3 seconds, with no transitions. When transitions or effects kick in, you just want to switch to pause and go ahead by hand, it's nearly smoother ;)

If you have issues at any point of the testing, mail me or directly come to pitivi's IRC channel, my nick is Mathieu_Du.

Voila !

June 16, 2011

PiTiVi: Let's go faster!

As I said in the last release announcement post, the PiTiVi community needs changes in the releasing process, and as newly appointed release manager I have the primary goal of making the development as dynamic as possible. The last release cycle lasted 8 months, which is way too long when we are supposed to be following the "release early, release often" philosophy. Avoiding it, is something we really want to work on, but I think a little explanation of why it happened is well needed:
  • We had blocker bugs that could only be fixed by the main developers, and it was difficult for them to do so.
  • The person in charge of releasing was much too busy to do the job, which is why I have now been appointed as new release manager and will do my best to find the time to do it well.
  • We did not have any release schedule, which meant that we did not have any obligation concerning releases.
Also I want to explain a few of the reasons why I do believe this is something we really want to avoid:
  • Users think nothing is happening, that the project is dying. Yet, as the activity on our git repository shows, rumors of our death have been greatly exaggerated.
  • Potential contributors are hesitant to invest in the project because they think the project is dormant.
  • Without a feature freeze, bugs tend to accumulate as new features land Contributors may be discouraged by the fact that they do not see their work reach the users quickly enough.
  • There are many more reasons, as you can guess, but listing them all here would take too much time and I would have to delay the release ;-)
Therefore, we decided to take a set of measures concerning our release process to keep our current developers active and attract as many new contributors as possible. So here are the changes that are going to occur in the near future:
  • First and foremost, starting from now, PiTiVi should follow the Gnome release schedule. This is not going to be easy, since our manpower is quite limited, but this is something that is really needed to ensure a healthy development pace.
  • Have an official patch review policy: we want to "guarantee" that any patch that is sent to us will be reviewed *within 3 weeks*. This is also a great opportunity for new contributors who have experience in programming in general and would like to start by reading and improving other's code. Collaboration towards making a great patch is a great motivator! Upholding this goal will be a challenge, and your help in reviewing patches is very welcome.
  • We want to make sure that deprecated libraries or broken/unmaintained features get removed as fast as possible. Dead code must die.
The project is pretty active these days, and I believe it is the right time to get those changes done. The feature list is becoming bigger and bigger and thanks to our very close relationship with the GStreamer multimedia framework, implementing new ones is becoming very simple. Also, the GStreamer community is very active and we are looking forward the GStreamer 1.0 release which should come out soon and will bring us new opportunities toward our goal of creating a video editor that can serve the needs of professional video editors.

So if you are interested in helping us making those changes happen, you are very welcome to have a look at our wiki page and our task list. I also warmly encourage you to join us on #pitivi on the freenode irc server, I am sure people will be happy to help you getting involved in this great software development project!

June 10, 2011

Calendar Update Part II - After The Release

Following up on my promise to detail some of my future plans. But first, a word about that nasty memory leak.

Memory leak in pycairo or pango/cairo.

I am 80% confident that there's a bug in the python bindings shipped on ubuntu 10.10. I developed a minimal example, (full source here), which just draws some text repeatedly in a window. The relevant bit of this example is the following function:

def draw_text(self, cr, text, x, y, width):
pcr = pangocairo.CairoContext(cr)
lyt = pcr.create_layout()
cr.move_to(x, y)
return lyt.get_pixel_size()[1]

This little script will om nom nom your memory -- over 100 mb of memory after just a few minutes, and I think we can all agree that even if this it's not the most efficient example, its memory usage should be nearly constant. I haven't yet opened a bug, because I still don't know which component(s) contain the actual leak. At least feel better that it's probably not something I'm doing wrong, which gives me the confidence to move forward with the release.

To mitigate against the leak, I threw in an optimization that ensures only one pangocairo context and one text layout is created, per expose event, per widget. This seems like a reasonable thing to do in general, so I will probably leave this optimization in even after the bug is fixed. Unfortunately, all this does is slow down the leak. The leak is still there, which means you still wouldn't want to leave the calendar application running indefinitely.

In passing I'd like to say that the idea that a pango layout needs to be associated to a particular context bothers me a lot. I wonder if I can get away with re-using layouts with different pangocairo contexts.

A better grammar

The current parser for recurrence expressions could use some serious help. The parser for the existing grammar is in the "proof-of-concept" stage of development. It's intuitive for simple things, but you will notice that parenthesis are needed to get correct parsing of more complicated examples. This is due to unresolved ambiguities in the grammar.

Most of the ambiguity could likely be resolved with associativity and precedence declarations, but when you're developing a new notation it's difficult to know in advance what the intiutive associativity is. Basically I didn't bother trying to get it right at all, and rely on parenthesis as a crutch. I recognize that this neither intuitive nor natural. Even I am surprised at how wrong the unparenthesized parse can be.

I am also aware that this approach is horribly anglo-centric. You would have to write separate parsers for  every language you wanted to support, and it's a good bet that language constructs don't always map onto each other so neatly.

I am also playing around with graphical approaches to the same problem, but to be perfectly honest they've all sucked so far. I might do a separate posting on one of them just to show you how god-awful it is.

A mouse-driven way to add recurrence exceptions.

When dragging a recurring event, the current behaviour is to shift the entire recurrence pattern. This is a deliberate choice on my part: it's a novel feature that I want to highlight it. Unfortunately, many times time what you actually want to do is shift just the occurrence you've selected, and occasionally you want to move all the events after the selected occurrence.

Note, you can do this now: however, you have to go through the text interface. Even I find this quite tedious. The solution most obvious to me is to introduce control and meta modifier keys, but I have found that other users do not share my enthusiasm for mouse modifiers. In usability parlance, we say that   modifiers are less discoverable than more explicit features.

Another idea would be to add some tool bar buttons that silently add modify the recurrence rules of the selected event. This would be fairly easy to do, but I have a couple of misgivings. The first is that the toolbar is getting crowded already. The second is that it won't be obvious what those buttons do at first. Clicking on the "except this occurrence" button will not produce an immediately visible change, only modify the behavior of future interaction. This would be especially be confusing if you hit the button by accident.

A more radical idea would be to place special "handles" on the clip itself. That way dragging from a handle could have a different meaning from dragging the clip itself. I am leaning towards this approach, but it is not without drawbacks of its own. For example, the handles compete for space with the event text. They will necessarily be small, which could hurt usability in a tablet.

Integration with other calendars

Syncing with Google Calendar and / or EDS
importing from, and exporting to, .ics.

This work ought to be pretty straight-forward given how the code is organized, but I haven't really looked in detail at the APIs / File formats I'd be working with. If you're interested in helping out with that, you know where to find me ;)

Event alarms

This might not be necessary if I can use something like EDS as the default back-end. But we'll see. Depending on how hard it is to map the concepts in my application onto the APIs exposed by EDS, it might be easier to roll my own implementation.

June 09, 2011

Calendar Update

What a crazy couple of months it's been. I have been back in San Francisco since late February, but not found the motivation or time to post until now. Among other things, I've been to racing school, and I've taken up drumming as a new hobby. I also attended the meego conference here, where I was showing off my QML GES demo (another post about this is still in progress).

I thought I'd take some time to write about the work I've done on my desktop calendar application over the past several months. This will stop me from pestering my friends about it, which will make them a lot happier.

  • Major cosmetic face-lift.
  • Added an infinite-scrolling month view.
  • Added support for all-day events, which are displayed in a pane along the top row.
  • Added support for recurring events via a natural-ish language parser which supports english-like recurrence expressions such as "every two days from now until october", or "the 3rd wednesday of every month except this wednesday"
  • You can easily shift the entire recurrence pattern by dragging a single occurrence with the mouse
  • Possible to select the same block of time across multiple days.
  • Added support for editable event text.
  • Removed dependency on goocanvas. Since all the drawing code is custom, and the entire widget is re-painted on every expose, there really is no point in using goocanvas.

I am considering making an initial release, but would like to address the following issues:
  • I need to come up with a name. As my music teacher once told me, "Name your children." Anything is better than cal.py.
  • Adopt some system for installation, most likely distutils.
  • Currently the calendar widget leaks about 100kb of memory for every expose event. After a few minutes of scrolling and dragging it's pushing 100mb. It's obviously a bug, and I've narrowed it down to the functions I wrote to simplify drawing text. Disabling these functions reduces the memory consumption to a much more reasonable 15-ish mb, Either I am doing something memory inefficient in python, or I've found a leak in pango / cairo. I would very much like to understand that better.
  • I recently added all-day events. You can create an event as an all-day event, or you can drag an existing event to the all-day area. But you can't drag an all-day event back into the timed area.
I did some "usability testing" on a hapless friend of mine, and the results were encouraging but showed there was a great deal of room for improvement. Unfortunately, my select-then-add paradigm of creating new events is confusing for those used to applications like google calendar and evolution. In evolution I find the click-to-create behaviour frustrating. Google calendar, on the other hand, seems to get it right.

After the release
This post is getting long enough already. I've also got some ideas for subsequent improvements, which I will summarize here. TTFN

  • A better grammar
  • A mouse-driven way to add recurrence exceptions.
  • Integration with other calendars
  • Event alarms

June 03, 2011

Second weekly report for GSoC

Here is my weekly report for the second week of GSoC :

Hi !

I've spent my week refactoring my formatter, and after successfully integrating the effects handling, I've banged my head against the track objects wall.

My first version worked fine, but I had worked around the following problem in a way that was not the ideal one :

When you create a timeline object, the track objects are not immediately created, and when timeline objects are ungrouped in Pitivi, you want to access the track objects of the timeline file sources to move them accordingly. I worked that around by creating two file sources when needed, and setting one mute and the other blind.

My new version added a "track-object-added" signal to GESTimelineObject, which I caught to move the track objects accordingly. This worked fine, but there is now another trouble : transitions added after track objects were created are not taken into account, even if GST_DEBUG tells me they were really added. I have a good test case that shows that, and I pushed that yesterday for bilboed and thiblahute to have a look.

I just started to have a look at the unhandled argtypes in the bindings, and I will work this week-end to get back in my schedule.

I'll be able to use the old version of the formatter to start integrating it anyway, for the API will not change when the refactoring is done.

By the next report, I plan to have finished the bindings, to have them merged soon, cause other GSoCers will need them. I will then start the integration, to reach the goal of my mid-term evaluation : having pitivi load projects, and see them in the viewer.

Have a good week-end :)

June 01, 2011

PiTiVi 0.14 "No longer kills kittens"

The PiTiVi team is proud to announce the immediate availability of our new 0.14 release, with major new features, bug fixes and usability improvements. We hope you can use and enjoy the improvements in PiTiVi 0.14, and report bugs you may encounter (bugs are a fact of life! Help us hunt them out!).

Some of the major new features deserve to be enhanced in here such as:
  • Audio and video effects: with PiTiVi 0.14, it is now possible to add all the effects provided by GStreamer and some other libraries, which, depending on what is installed on your system, means "a lot". The user interface for managing those effects will improve in future releases.
  • Ability to preview video, audio and image files before importing: the file chooser dialog now lets you directly preview the files you want to import. This is pretty useful when you don't remember the name of a file you wanted to import, or when you're just "looking around" for media to use in your project.
  • Welcome dialog: when starting PiTiVi, a startup assistant now helps you load recently used projects in two clicks or create a new project. Don't feel like using this dialog? Just click its Close button or press the "Escape" key on your keyboard. However, we trust that this little fella will make you much more efficient, not less. We hate useless windows. See also this post, for some explanation of the design process that went into this welcome dialog.
...And more. See the full release notes for a more exhaustive list of goodies.

This release cycle has been very eventful. As the list of contributors reveals, lots of people got involved in the software development. I also want to thank all the people who worked hard on translating PiTiVi in a timely manner and reporting localization issues.

We are now entering a new cycle on the road to maturity. Four students are working full time on PiTiVi this summer, thanks to the Google Summer of Code program, and we will try to increase the general development pace to keep the great momentum we had in the past few weeks. Stay tuned for another blog post on how we plan to achieve this!

To celebrate, I personally wanted to do some dogfooding by making this little video, with the additional constraint of using only footage coming from my own camera (no, I am not a video artist!):

But this is for sure, not the best PiTiVi can do. See our showcase page for examples of videos we found to be aesthetically interesting, and feel free to submit your own! Post links to your videos in comments, and if they're really cool, they could end up in our showcase! ;)

PiTiVi pre-release

The whole PiTiVi team is pleased to announce a pre-release of the PiTiVi video editor.

This pre-release contains the past 7 months of work, implementing this pretty new feature list:
  • Audio and video effects
  • Completely redesigned project settings dialog, with the ability to create presets
  • Completely redesigned rendering dialog
  • Welcome dialog that helps you start a project or load recent projects in two clicks
  • Ability to preview video, audio and image files before importing
  • Add a "best fit" zoom button
  • Ability to jump to an exact position in the timeline
  • Ability to specify custom aspect ratios and framerates
  • Show a progress bar when loading projects
  • 300% faster project timeline loading
  • Search bar in the Media Library
  • Ability to detach all the tabs and the previewer
  • New manpage
  • Commandline render mode
  • Use the standard infobar widget all around
  • And lots of bug fixing

Unless anything critical or regressions pop up, expect the 0.14 release next tuesday (May 31st).

Please test it and abuse it and report bugs at:

Tarballs are available here:
Thanks for testing and helping us make this the best release ever :)

May 27, 2011

I have been lurking and hacking Pitivi's source code for quite a while now, and I think it is now time for me to sum up my opinions about it.

The first time I launched it, I had just installed Ubuntu and the version I had was 0.13.4, without the effects and anything. I was new to coding, so the only thing I could judge about it was the user interface and how everything fitted together. And I must admit that I thought : "Wow ! This is not what I would use if I wanted to make a short movie or anything .."

Anyway, I started messing up with the code, making my way through the architecture with wild prints and crazy changes, and I quicly reckoned that Pitivi was only the visible part of a greater framework, namely GStreamer, and that this framework really rocked, and gave Pitivi an unprecedented advantage on what existed before : A solid community, with hundreds of active members, all of them dedicated on taming the wild beast which is media handling, writing a great number of plugins ranging from codec handling to effect creation or object transformation !

Pitivi was nothing but the editing emerged part of the iceberg, and a part which was still to grow to its real size. After all, the version naming is not random, the 0.13.x name means that it really is not mature yet, and misses a bunch of basic features essential to video editing, listing them would be too fastidious.

But the whole point of my argumentation is that I think Pitivi has bet on the good horse, cause now that I begin to know a little more about GStreamer's internals, I realize the power that lies in its architecture : Flexibility and Modularity, through the use of combinable elements to form new elements, which in turn can be combined to finally make complex pipelines, ready to be played or rendered at will.

I don't know well the other available frameworks, for example MLT, but what I know is that I love GStreamer, and a lot of other people look like they love it as well, shaping up the biggest media framework community by far.

That's why I stuck up to pitivi until now, eventually applying for a Summer of Code to be able to give it still more of my time, and I can say now I'm happy of my choice. Indeed, a long-awaited release has just arrived, shipping a whole lot of goodies, first of them being the effects handling, and I can see some lines moving. Pitivi's IRC channel has never been so active, and new enthusiastic developers wannabe's pop up every day. On top of that, Gstreamer and Gnome have allocated no less than 4 Summer of codes to us (against only one last year) which means we're gonna be able to take this software to a new level :
  1. One GSoCer is going to implement complex object recognition algorithms (robust estimation of Optical flow), which will make pitivi conscious of the different layers (background, foreground) and moving objects in a video.
  2. Another will use Gstreamer filters to provide object's transformation options to the user, and also give titling support to Pitivi, another essential feature that it was lacking until now.
  3. The third one will allow users to upload videos to streaming websites such as youtube or dailymotion, and also provide them with rendering presets (IPod, YouTube, Android Phone etc..).
  4. I will integrate a new C library in pitivi, which will replace a lot of its backend with C optimized functions, making it more performant in the process, and allowing new features
     integration (for example new kinds of transitions, the default one for now being the classical overused crossfade).
This is exciting isn't it ? I can't wait to see the next release, which will hopefully come way faster than the previous one. Kudos to thiblahute for bringing it to us !

My Google summer of code weekly report number 1.

Hi everyone !

I started working on my project before the actual Summer of Code began, and I already successfully compiled the static bindings with a code coverage of about 90 %, wrote the beginning of a test suite for them and a basic example script.

Since then, effects have been merged in GES master, so the .xptv file formatter I had written has got outdated, and since it's a critical component of my project, I decided to update it before going on with the bindings, in the hope of getting a near 100% code coverage.

This has involved some massive refactoring, since I had not clearly envisioned the way the formatter would work with the effects (shame on me ;), and I'm not done yet : effects are integrated, but I still have to re-integrate the transitions properly).

However, work is going well, and I'm not blocked anymore on my way to integrating GES in pitivi, given one of the members of the IRC channel gave me a hand on solving the problem of GST argtypes that were not properly handled by the code generator I use to create the bindings.

By the end of next week, I will surely have finished my work on the formatter (code cleanup, fixing of the tests), and I hope to have solved the GST argtypes problem completely as well (This could be the matter of 2 or 3 hours of coding if everything goes as intended). With some luck, I'll be able to write overrides for the last 10 or 12 functions as well, which will leave me free to attack the real meat of my project, i.e. integration in pitivi proper.

Most of my problems this week were very specific to my project, and I don't think they'd be very useful to anyone.

December 18, 2010

Working for Collabora Multimedia :)

This month is my first month working (part time) for the multimedia team at Collabora. I think you all know about this company which is specialized in open source softwares particularly in Gstreamer and all majors Gnome/Freedesktop technologies.

So I am now working on GStreamer related technologies and in particular on PiTiVi to make it rock more and more!

I am very glade to be part of this team and am looking forward the good time I am going to have hacking as a multimedian :)

December 10, 2010

Change in the plans !

YouTube law-kicked us so I had to find more suitable streamers.

I just implemented archive.org and blip.tv and it rocks.
Archive has a very serious, research-oriented(but not only) database, with private collections and plenty of available formats for most videos.
The only problem I see with it is the 'picture coming soon' on 3/4 of the thumbs..
I hope it's true :)
That is not a problem with blip.tv, which is more youtube-like. You only get .flv on the other hand.
Anyway, I'm now lurking for another friendly streaming site. Any suggestions accepted :) 

November 27, 2010

Drag and drop would be difficult though :)

First blog : Introduction.

Hi ! I'm making this blog to present the results of my work on Pitivi, the open source video editor that is shipped with ubuntu 10.04. My git branches (not always up to date :) are available here :
As I currently am unemployed, I have found quite a lot of time to mess with pitivi's source code, and produced some enhancement features that were suggested in the Pitivi_love wiki.
At the moment, I work on a feature that no doubt people will like. It's the ability to browse youtube's videos within pitivi (see screenshot), directly stream them ( a bit like totem's plugin that actually does not work for me :) and download them. They are then added to the sourcelist, where you can edit them as usual clips ( to make a cool video playlist with fancy transitions for example ?).
The retrieval of the video can also be done directly with its url, and I just implemented the processing of dailymotion's urls as well. Direct streaming is not available for the moment with this method, but it can be implemented quite easily. One could also add a lot of ways to retrieve contents online with this method. The search is permitted by google gdata API, but a download address can however be figured out from google video and other kinds of online streamers. GData also provides an API to search Picasa, I dont know to what extent it would be useful in a video editor. Any feedback appreciated, have a nice day :)

Testing Interactive Code

The preceding work on the Render and Project Settings dialogs in PiTiVi has led to some fairly complicated UI logic, and we haven't really got a good way to test it.

Imagine that we want to test the following trivial python UI
import gtk
import gobject
import random

def b_clicked_cb(button):
clicked = True
button.props.label = "Ouch!"

w = gtk.Window()
v = gtk.VBox()
b = gtk.Button("Click me")
b.connect("clicked", b_clicked_cb)

We want to check that the button label is correctly changed after being clicked. Because of control inversion, we obviously can't code in a direct, sequential style. At the very least we must install a timeout or idle function into the main loop.

This is a naive approach:
def test_case():
assert b.props.label == "Ouch!"
return False

gobject.timeout_add(1000, test_case)

It doesn't work because of timing issues. The button's label won't change immedately after activate() is called, so you get the following error -- despite the fact that the the label clearly changed.

Traceback (most recent call last):
File "figure_1.py", line 19, in test_case
assert b.props.label == "Ouch!"

The obvious solution is to split the callback in twain:

def test_case():
gobject.timeout_add(1000, finish_test)
return False

def finish_test():
assert b.props.label == "Ouch!"
return False

gobject.timeout_add(1000, test_case)

It's good enough for this trivial example, but it should be clear that as the complexity of the UI increases you'll end up with yet another maze of callbacks.

Last night I experimented with applying python generator functions to this problem. The idea is to (ab)use the yield keyword as a way of passing control between the test and the mainloop. It's similar to concepts presented in this paper, which describes how continuations can be used to solve the problem of control inversion in web programming.

Quick summary of python generator functions: the yield keyword in python is a limited form of either lazy evaluation or continuations, depending on your point of view. Usually we think of generators as sequences. For example this generator can be thought of as the sequence of positive integers from 1 to 10
def ints():
i = 1
while i <= 10:
yield i
i += 1
I can treat it as sequence and take its sum, or iterate over it:
print sum(ints())
squares = [x ** 2 for x in ints()]
What actually happens when squares is called is that an iterator is created and returned to the caller. Yield indicates to the interpreter that squares() is a generator, and that the state should be saved so it can be re-entered later. The fact that the state of the function is saved inside iterator allows us to think of the iterator as a continuation (generators are not as powerful as continuations). With this in mind, we re-write our test function:
def test_case():
assert b.props.label == "Ouch!"
Here the yield keyword is going to provide the same control flow boundary that splitting our code into separate functions did earlier. Now all we need is a bit of code to consume values from this iterator until it is exhausted. We do this using timeouts -- as we did in earlier examples -- which allows the mainloop to continue running in between the two halves of our test case.
def run_test_case(iterator):
print "Tick"
except StopIteration:
print "Test Case Finished Successfully"
return False
except Exception, e:
print "An error occured"
return False
return True

gobject.timeout_add(1000, run_test_case, test_case())
This is already an improvement, but not yet flexible enough. Suppose we add a new widget:
def c_clicked_cb(button):
def set_label_async():
c.props.label = "Ouch!"

gobject.timeout_add(random.randint(500, 5000),
c = gtk.Button("Async Operation")
c.connect("clicked", c_clicked_cb)
Now we have a problem: we have no idea when the action triggered by clicking the second button will complete. Simply waiting for one second will not always work. At the very least we should be able to override the default sleep value. But it would be better still if we could wait until the label value itself is changed. That way if the action takes only a short time, we don't have to wait, while if the action takes longer than expected, the test can still finish successfully. In other words, we shouldn't just assume that after each step in the test we straight on to the next one. Let's factor out portion of the loop that does the scheduling:
class Sleep(object):

def __init__(self, timeout=1000):
self.timeout = timeout

def schedule(self, iterator):
gobject.timeout_add(self.timeout, run_test_case, iterator)

def run_test_case(iterator):
print "Tick"
scheduler = iterator.next()

except StopIteration:
print "Test Case Finished Successfully"
return False

except Exception, e:
print "An error occured"
return False

return False
Now we can easily customize the timeout for the second button specifying a Sleep scheduler with a different timeout.
def test_case():
yield Sleep()
assert b.props.label == "Ouch!"

yield Sleep(6000)
assert c.props.label == "Ouch!"
Actually we can go one better. We don't have to rely on timeouts for scheduling at all. For example, we can easily define a scheduler that will wait for a signal to fire:
class WaitForSignal(object):

def __init__(self, obj, signame):
self.obj = obj
self.signame = signame
self.iterator = None
self.sigid = None

def schedule(self, iterator):
self.sigid = self.obj.connect(self.signame, self._handler)
self.iterator = iterator

def _handler(self, *args):
Adopting this is just a one line change to test_case():
def test_case():
yield Sleep()
assert b.props.label == "Ouch!"

yield WaitForSignal(c, "notify::label")
assert c.props.label == "Ouch!"
And we don't have to touch run_test_case() at all. I think this idea could be expanded into a framework for testing event-driven code. True, I would want much better error reporting. But with just that, it would be pretty straight-forward to cover every part of PiTiVi's interface except the timeline (for the Timeline, I need is the ability to synthesize raw input). If necessary, I can include other types of scheduling scenarios, such as waiting for a file or socket access. And, because I can work with the widgets directly, it's possible to verify conditions that would be impossible to check for under Dogtail or LDTP (which are both limited to what AT-SPI exposes, and run the test from a separate process). Full Source

November 26, 2010

And the winner is...

The overwhelming majority went for version B. I changed the layout a bit, and a cleaned up version is what's in my branch now. Thanks, everyone.

November 18, 2010

Round 4

So it's down to two competing ideas. At this point my brain is shot and I can't really decide between them. So I've decided to put them up here and see what people think. The best way to compare the two is right-click the images into separate tabs and switch between them a few times. Take a good hard look at each one.

What I'm looking for here is clarity of ideas, not cosmetic considerations like alignment and balance. That is, which of these dialogs is easier to understand?



Now that you've done that, does anything seem to be missing from either one that would make it an improvement over the other?

November 17, 2010

Round 3

09:38 < bemasc> emdash: So, the true parameters here are the storage height,
storage width, PAR, and DAR.
09:39 < bemasc> that's 4 values in total, but only 3 degrees of freedom.
09:40 < bemasc> Personally, I would expose all 4, and update PAR after each change to DAR (and vice versa)

How about this, then?
Starting to look a bit better? I kept the notion of 'Display resolution' mainly as a source of feedback, but it occurs to me now that perhaps little rectangle that represents the display aspect ratio would be a better idea. Unfortunately that would mean increasing the size of the dialog again.

I'm actually not so sure that DAR and PAR should update each other, as I played around with it and it's somewhat frustrating. I think most of the time you're either targeting a specific format (for example, 480i) in which case you'd just choose a preset, or you'll be working with square pixels.

I think i need to add a 'constrain aspect ratio' check-button to make scaling a bit easier.

Project Settings Progress

Re-worked it a bit this afternoon. But i'm still not happy with it. I think it might be too confusing to expose pixel-aspect-ratio to the user (hell, it's confusing enough for the programmer).

Another idea: present display width / height, optionally allowing the user to constrain to an aspect ratio. Separately present content (storage) width / height, and finally show the pixel-aspect-ratio as a read-only label, as a form of feedback. In other words, PAR would be computed working backward from display and content resolutions.

Mockup: The diagram on the bottom shows how updates
would propagate between widgets

November 16, 2010

PiTiVi Dialogs

I am (finally) making progress on the two main dialogs in pitivi: "Project Settings" and "Render". I'll just get right to the point: Screenshots!

Render dialog showing video tab

Render dialog showing general tab
Project settings showing video tab

I spent most of my time today on project settings. I'm still not quite happy with it, as the current design is, well, huge. I think I could make it a little narrower and shorter. But that's more-or-less what I'm after.

The properties in the video tab are inter-dependent. One feature I wanted was for the widgets to ripple-update like a spreadsheet. To make this easier I wrote a class that manages a graph of widgets that you give it. Each widget can have an update function, and when the user changes one of the widgets, the the update functions are called starting from that widget in breadth-first order. During the traversal, updates are ignored to prevent infinite loops of signal emissions. This means I get my ripple updating behavior, but I only have to write a single, naive update function for each widget without worrying about keeping other widget values in sync.

Tomorrow I will implement presets, make sure the dialogs remember their state, and then test the hell out of them.

November 01, 2010

Side Project

I started working in a calendar app. Right now you can think of it mainly as a prototype, but it's already got some interesting features. It's implemented in python, and while it relies on goocanvas at the moment, the calendar view is actually one big canvas item and could easily be ported to a stand-alone widget.


At first glance it looks like the week view used in most timelines. However, the view is an infinite scrolling area. There is no horizontal scroll bar, as this is a ranged widget. You move in time by clicking and dragging on the day heading. If you flick the heading, the calendar will continute to 'coast', slowing down gradually until it stops (or immediately if click on it).

I've found that I rarely look at the month view in a calendar application, so I sought to eliminate it. My calendars tend to have a lot of daily repeating events, making the month view seem cluttered. I mainly use it for skipping forward or backward to a specific week without loosing context, or to see a group of days that span a weekend.

With infinite scrolling I found I really don't need the month view. I don't loose context skipping around because of the smoothness of the animation. Moreover, it's no trouble to position the calendar so that Friday is in the middle of the window (the coloration on the heading serves as a reference). Expanding the window will reveal more days, not make the days larger. If you want to look two weeks ahead, you can -- even on an eee 901. I do plan to add a zoom feature, however.


Another feature I've added as a reaction against current calendars: When you click and drag on the calendar itself, it doesn't create a new event automatically. I've always found this to be annoying. When I make a selection, I am usually in some kind of tentative state of mind. Moreover, in thunderbird and evolution, it's possible to accidentally create events that are too small to be selected, forcing you to go into another view to delete them. Again, really annoying. I don't want the application taking some action based on my half-baked ideas. I much prefer it to wait until I'm sure of myself.

Undo / Redo

This applet is the first time I've implemented the Command Pattern in a program, and I'm curious to see how it pans out. The idea is that rather than employing low-level tricks to capture state for undo, you explicitly code the do and undo procedure for each action that your application supports. So far, New, delete, move, resize, and select can all be undone.

I think that selection is too often left out as an undo action. Doubly annoying because selections are ephemeral, disappearing the minute you focus on something else. Often I select things without thinking. I've put a lot of work into creating selections, only to have them evaporate due to an errant click.

On the implementation side, I distinguish between MenuCommands, from which menu and toolbar items can be created automatically, and MouseCommands (invoked repeatedly with new mouse coordinates before being committed to the UndoStack in their final state). Both types support a class-methods indicating whether they are currently available. This allows toolbar state to be managed, and for the controller to distinguish between one of several commands it might support.

One thing I found is that with this approach, the Controller becomes a general-purpose object which mostly creates and commits commands to an UndoStack in response to low-level events. The controller implements the logic for detecting drag, click, double-click detection. The commands implement more concrete actions, such as moving an event in the calendar based on given mouse coordinates. The Controller only needs to be specialized to add new input events. For example, flicking the calendar is currently implemented with a custom controller.

In the future I plan to make navigation undoable. I'm debating whether navigation commands should be posted to the main UndoStack, or into a separate stack that would be exposed as "Forward / Back".  I'll have to try and see.

Development Status

If I follow this out to its conclusion, it would need at least the following features before I'd call it "Done".

  • Ability to edit the names of events
    • tricky because the whole thing is done in raw cairo
  • Some system for handling repeating events
  • convenience navigation buttons, such as "Today", "Last {Week, Month, Year}", "Next {Week, Month, Year}" etc.
  • Alarm notification system, and ability to handle alarms
  • Integration with google calendar (probably using libgdata)
  • some cosmetic improvements
The implementation of the alarm notification system worries me most. I have only a vague idea of how I would implement that, and it would need to be absolutely reliable before I'd consider using this program myself. I do have some interesting ideas for how to create alarms and repeating events in the UI, however.

October 30, 2010


Coming home Saturday night I was delighted to see that "The Co-Operative" grocery store nearest my house was still open. I went in to buy some things for next morning's breakfast.

There were two choices for bacon: one claiming Britain as its origin, and another from "the family farms of the Netherlands". At this point I must confess that my first reaction was "Eek! Why would I want Dutch bacon? I'm in England! The British bacon is for me." It seems I have begun to adopt a British point of view after only a few short weeks. That is until I looked more closely at the package and read that it consisted of "87% pork."

I was perplexed. How in he world can 13% of a slice of bacon consist of something other than pork? Some minutes passed, during which time I surveyed the contents of the package. Perhaps closer inspection would reveal a portion of the of the slice where some miscreant had inserted turkey or beef. At least that would be a reasonable explanation. Alas, I found no signs of obvious adulteration.

Unsettled, I chose the Dutch variety.

Scene from a small boat punting up the Cam (the river in Cambridge).

October 09, 2010

Some More Pics From Spain, Continued...

I ate at this really neat cafe in Figueres. 
The bathroom was entirely stainless steel, and used car door handles.

Here I am, trying to be artistic

There's a lot of really good street art in Figueres...

...as well as the more typical variety.

More scenes from Figueres.

Waiting for the train back to Barcelona.

In front of the Dali museum, with a dopey grin.
It's worth the trip. Thanks for the tip, Kat!

A closeup of the the dots on the exterior of the
building. Each one appears to be slightly

Some More Pics From Spain

I've been out of Spain for a couple of months, but I still have plenty of photos I never posted. Truth be told I found it a bit painful to manually upload them. I don't know why it never occurred to me to use Picasa until just now. Enjoy.


Scenes from a public concert in Montjuic

A warm waffle, covered in chocolate sauce and sweetened condensed milk. Purchased from the above stand.

October 04, 2010

So, I'm in Cambridge, UK now. I've been meaning to post up for days but haven't quite found the time. I'm going to try to get some longer posts out in the next couple of weeks, but for now I'll settle for something short and simple.

Quote of the Week

The other day I was walking through Midsummer Common, which is a big green field near the center of town that normally contains quite a few cows. Instead there was some kind of bicycle race event and the place was packed with people and cycles. I smelled the smell of good, greasy food -- like the kind you get at a county fair or a race track -- so I sauntered on in. As I was munching on a tasty roast pork sandwich (with stuffing and apple sauce) I overheard the following snippet of conversation:

Boy (in a whiny English kid voice): So, can I mum, can I?
Parent: No Roger, you've been an absolute muppet today!

That's the first time I have ever heard the word "muppet" used this way. I wasn't sure whether it was a fluke or not, but while house-hunting today, my would-be roomate used the term in the exact same way to describe someone who forgets to lock up the house when they're the last to leave.

Nerd Section

Some time ago I got distracted by a silly idea that just wouldn't leave me alone. It kept gnawing at me to follow it up, so eventually I gave in and started hacking on it. Have a look at the following code. I'll give you three guesses to tell me what language it's written in.

     DEF (id(outer) FUNCTION(id(x)
       FUNCTION(id(ignored) VAL(x))))

     DEF (id(one_ret) APPLY(VAL(outer) _(1)))
     DEF (id(two_ret) APPLY(VAL(outer) _(2)))

     PRINT (APPLY (VAL(one_ret) _()))
     PRINT (APPLY (VAL(two_ret) _()))

     DEF (id(count_backward) FUNCTION(id(x)
              PRINT (_(done))
                PRINT (VAL(x))
                APPLY(VAL(count_backward) MINUS(VAL(x) I(1))

No, it's not LISP. The parenthesis go on the outside of the expression.

No, it's not python. Notice how there's no commas separating arguments.

Did I hear someone say haskell? Now you're just being silly.

It's actually C. Through abuse of variadic functions and preprocessor macros, I implemented a functional, dynamic language directly in C. For the curious, you can see the full example at my git repository, http://github.com/emdash/goof/blob/no_commas/simple.c:

I did it for fun, but it does work. Bonus points for explaining how it works in a comment.

September 22, 2010

Pitivi master finaly gets effects!

So as suggested by the title, the work I did during the Google Summer Of Code has been Merged! It means that the next Pitivi release which should arrive quite soon will gain effects.

I haven't been blogging for a long while so sorry about not telling you what was happening but I did it in order to make a surprise :P

Now that it is merged, you are very welcome to test it and report all the bugs you will find so we have a great release soon to propose the world.... with effects!

Sorry for not making a screencast but as you can test it quite easily, it shouldn't matter so much ;) (and nekohayo is telling me he should make one soon)

As I enjoyed a LOT working in the pitivi community during this summer, I am going to keep working on it in my free time fixing the bugs you are going to report. And of course I am planing to enhance effects support and add features such as keyframes handling...

And just a little screenshot so you can have an idea about how the UI looks like now:

August 16, 2010

Returning Home

I'm a bad blogger, I know. I didn't even post before leaving spain :( In the last couple of weeks I managed to do some traveling around Catalonia, seeing Taragona and Figueres. Dali Museum is really quite awesome in Figueres. Taragona has roman ruins and a good beach. Have pictures, but not on this computer. Will try and post them soon.

I'm currently in Boston visiting some friends on my way back home. My friends live between Harvard and MIT. Walked around the campus and then my friend took me down town to see boston common, and the harbor. We also passed by the grave yard where Paul Revere, John Hancock, and the victims of the Boston Massacre are buried. John Hancock's tomb stone is the largest of the bunch. While walking through downtown Boston we ran into Richard Stallman. That's all I've got for the moment.

Today I am thinking about busing to New York city and back for a bagel, a hot dog, and a pizza. But we'll see. Jet lag and my friend's cat have combined to give me a bit of a jumpstart on the day. I'm looking at the schedules right now.

August 12, 2010

Pitivi get effects, part 6

Sorry for not blogging in such a long time!

Now that I am back in chile afer the GUADEC, I have finally been able to hack again on Pitivi. So has I said during my presentation of my project during the GUADEC, I implemented everything I wanted to. So I am now working on debugging everything, cleaning code, and even if I have a few remaining critical bugs (which could probably be bugs in gnonlin), you can use it for testing purposes.

I also started to work on a new branch[0] in order to save the undocked windows state, but since I found new bugs on the effect implementations, I am working on them.

So for now I don't have a screencast, but I promise I will make one when I can show everything working smoothly.

You can give it a try if you have the latest gstreamer from git using my git repo[1]

[0]: http://github.com/thiblahute/Pitivi/commits/save_undock_windows_state
[1]: http://github.com/thiblahute/Pitivi

August 05, 2010

Great time at GUADEC

So as you may know, last week took place GUADEC and I am one of the lucky guys who have been sponsored by the Gnome fundation to take part in it! I spent a great time there and finally could meet all the people I have been working with those last two years!

So I wanted to say a big thanks to all people who organized this great event, and all the sponsors.

See you all at GUADEC 2011 in Berlin!

July 23, 2010

Getting Ready for GUADEC

The last few days have been a welcome reprieve from the oppressive summer heat. Thank god for that. Of course it cools down just before my departure to the Netherlands for GUADEC.

Going to GUADEC next week. There's going to be a big PiTiVi hackfest involving the majority of the current PiTiVi contributors. I'm really looking forward to some serious progress.

Also hoping to give a lightning talk about some hair-brained ideas I have for UI development.
Last week, my friend Aaron came to visit and we rented scooters and rode around the city. It was hot, but fun. Enjoy the photos.

This is us up at Parc Guell.

Did you ever think you'd see Aaron on a scooter?