June 13, 2013

Andy Wingobut that would be anarchy!

(Andy Wingo)

Good morning, internets!

This is the second of a series of articles on what it's like to work for/in/with a cooperative; the first one is here. Eventually I'll update the first one to link to the whole series, whereever it goes.

I work for a worker's cooperative, Igalia. This article series is about moving beyond theory to practice: to report on our experience with collective self-determination, for the curious and for the interested. It's a kind of exercise in marketing the revolution :) I hope I can be free from accusations of commercial interest, however; for better or for worse, our customers couldn't care less how we are organized internally.

the ties that bind

The essence of a worker's cooperative is to enable people to make decisions about their work to the degree to which they are affected by those decisions. For decisions affecting the whole group, you need collective deliberation. You could think of it as workplace democracy, if you understand democracy to go beyond simple voting and referenda.

Collective decision-making works, but you need some preconditions -- see for example conditions for consensus, from this excellent article on consensus. More so than any other enterprise, a cooperative needs to have a set of goals or principles that binds all of its members together. In Igalia, we have a rather wordy document internally, but it's basically a commitment to finding a way to let hackers work on interesting things, centered around free software, in a self-organized way. Everything else is just strategy.

structure

There are two more-or-less parallel structures in Igalia: one for decision-making and one for work. There is also a legal structure that is largely vestigial; more on that at the end.

The most important structure in Igalia is the "assembly". It's composed of all workers that have been in Igalia for a certain amount of time (currently 1 year, though there are discussions to shorten that period).

The assembly is the ultimate decision-making body, with power over all things: bank accounts, salary levels, budgets, strategies, team assignments, etc. All company information is open to all assembly members, which currently comprises all of the people in Igalia.

The assembly meets in person every two months at the head office in A Coruña, with the option for people to dial in. Since many of us work in remote locations and just communicate over mail and jabber, it's good to see people in person to renew the kind of personal connections that help make agreement easier. Incidentally, this requirement for group face-to-face meetings influenced the architecture of our head office; there is a dividable room there that can be expanded into a kind of "round table" with microphones at all the posts. You can see a picture of it on the about page.

The in-person assemblies are usually a bit abstracted over day-to-day operations and focus more on proposals that people have brought up or on strategy. Sometimes they are easy and quick and sometimes they go late into the night. The ones associated with longer-term planning like the yearly budgeting assemblies are the longest.

How well does this work, you ask? I would summarize by saying that it works OK. There are so many advantages to collective decision-making that I now take for granted that it is difficult to imagine other ways. However, making decisions is hard on a personal level: it's a challenge to hold all of the ideas in your head at one time, and to feel the right level of responsibility for the success of the business. I'll write another article on this point, I think, because it is also part of the cooperative working experience.

"The assembly" is both the bimonthly meeting and also the body of people. We're all on a mailing list and a jabber channel, which is where a lot of the other day-to-day business decisions get made, like "do we accept this contract", "should we hire people soon", "should we hire X person in particular", etc. However with some 40 people it's tricky to establish an active consensus on a mailing list, so it's usually the people that lead with proposals and actively round up people to help them implement that get things done.

work groups

So that's the power structure in Igalia. However on a day-to-day level, unless a thread is really active on the assembly mailing list, folks just do their jobs. Sounds silly but it has to happen. We're organized into teams, like in a normal company, but without managers -- we also do consensus on a smaller, more informal level within the teams.

Since we're a consulting shop, most people write code all day, but there are also people that primarily focus on other things: sales, team coordination (who's available for what work when?), administrative work, finance and cash-flow monitoring, etc. This broader team allocation is also a result of consensus. (You can see the theme here.) Ideally we rotate around the "coordinator"-type jobs so everyone stays fresh, hacking-wise, and we don't entrench these informal power structures. We've done some of that but could do more.

I've heard people say that "if you don't have a boss, the customer is your boss", but that's simply not true for us in any of the ways that matter. Our working conditions, pay, holidays, hours -- all of this is up to us. Yes, we have to do good work, but that's already an expectation we have of ourselves as hackers. It's a much healthier perspective to consider your customer to be your partner: both providing value for the other. If this isn't the case, we should find other partners, and happily in our particular industry this is a possibility. (More on cooperatives, capitalism, and crisis in a future post.)

legalities

As I said in the beginning, the important thing is that a group share principles, and agree periodically on the strategy to implement them. In that light, the particular legal structure of Igalia is an afterthought, though an important one.

Although Spanish law explicitly provides for cooperatives as a kind of legal entity, Igalia is organized as a limited-liability corporation. The reasons are not entirely clear to me, and periodically come up for debate. One of the issues, though, is that in a cooperative, 85% of your partners have to be Spanish residents, and we did not want that restriction.

Spanish workers are employees of Igalia, and folks outside of Spain are freelancers. However once you've been in the assembly for an amount of time, currently 2 years (way too long IMO), you have the option to become a legal partner in the business, purchasing an equal share of the business at a fixed price. I say "option" but it's also an expectation; the idea is that being a partner is a logical and natural outcome of working at/with/on/in Igalia. We have partners in a number of countries now.

You see my confusion with prepositions, and it's because you have to fit all of these ideas in your head at the same time: working for Igalia as an employee, on it as a project, with it as a partner, at it as a social experiment, etc.

Partners are the legal owners of Igalia, and there are about 30 of them now. They meet every few months, mostly to assess the progression of "prepartners" (those in the assembly but not yet partners, like myself). Ideally they don't discuss other things, and I think that works out in practice. There is a small power differential there between the partners and the assembly. However all the really important things get done in the assembly.

Finally, since Igalia is an S.L. (like an LLC), there is a legal administrator as well -- someone who's theoretically responsible for the whole thing and has to sign certain legal papers. In fact we have three of them, and the positions rotate around every three years. If we were a legal cooperative we could remove this need, which would be convenient. But that's how it is right now.

domination

I want a society without hierarchical power: no state, no military, no boss. But that would be anarchy, right? Well yes, of course that's what it would be! "Anarchy" doesn't equate to a lack of structure, though. It's true that Igalia is embedded in capitalism, but I think it and other cooperatives are a kind of practical anarchy, or at least a step along the path.

I'll close this epistle with a quote, in Chomsky's halting but endearing style. The whole interview is well worth a read.

Anarchism is quite different from that. It calls for an elimination to tyranny, all kinds of tyranny. Including the kind of tyranny that's internal to private power concentrations. So why should we prefer it? Well I think because freedom is better than subordination. It's better to be free than to be a slave. Its' better to be able to make your own decisions than to have someone else make decisions and force you to observe them. I mean, I don't think you really need an argument for that. It seems like ... transparent.

The thing you need an argument for, and should give an argument for, is, How can we best proceed in that direction? And there are lots of ways within the current society. One way, incidentally, is through use of the state, to the extent that it is democratically controlled. I mean in the long run, anarchists would like to see the state eliminated. But it exists, alongside of private power, and the state is, at least to a certain extent, under public influence and control -- could be much more so. And it provides devices to constrain the much more dangerous forces of private power. Rules for safety and health in the workplace for example. Or insuring that people have decent health care, let's say. Many other things like that. They're not going to come about through private power. Quite the contrary. But they can come about through the use of the state system under limited democratic control ... to carry forward reformist measures. I think those are fine things to do. they should be looking forward to something much more, much beyond, -- namely actual, much larger-scale democratization. And that's possible to not only think about, but to work on. So one of the leading anarchist thinkers, Bakunin in the 19th cent, pointed out that it's quite possible to build the institutions of a future society within the present one. And he was thinking about far more autocratic societies than ours. And that's being done. So for example, worker- and community- controlled enterprises are germs of a future society within the present one. And those not only can be developed, but are being developed.

The Kind of Anarchism I Believe In, Noam Chomsky, 28 May 2013

by Andy Wingo at June 13, 2013 07:55 AM

June 12, 2013

Felipe Contrerasgnome-3

Since I started using Linux I used GNOME, v1.2 in those times. It has always done what I needed, maybe not perfectly, and not fully, but for the most part. GNOME 3 changed all that.

I complained about GNOME 3 since day one, and I discussed with GNOME 3 developers many problems with their rationale about why what they were doing made sense, and I foresaw many of the problems they are now facing.

I even started the GNOME user survey, in an effort to make GNOME developers see the light.

I blogged once before about GNOME 3, but only superficially, and even then GNOME developers didn’t take it well. Some GNOME developers might be tired of my arguments in Google+ and other media, but it’s time to dive into the issues with GNOME 3 in this blog.

Two years after the first release of GNOME 3, once GNOME developers have had the time to polish the rough edges, it’s time to make the call; GNOME 3 sucks. Here’s why.

The purpose of GNOME

Before we start, we need to clarify the purpose of GNOME, or rather; the purpose of any software project in general, which is to be useful to the users. Your software might the most efficient at doing certain task, it might have the simpler code, and the best development practices, but it’s all for naught if it’s not useful to anybody.

Software has to be useful for other people, otherwise nobody will use your software, and nobody will contribute to your software. Quite likely there will always be other software that does something similar to yours, so you need to convince users that your software is better than the alternatives, usually by providing a good user experience.

Once the user has spent time analyzing the alternatives and has chosen your software, the user expects your software to keep working, and in the same way. If the software keeps changing the way it behaves from one version to the next, it’s not achieving it’s main goal; to be useful to the users. If you do this, your users will move on to another project that might not have as many features, but at least they can rely on it and they don’t have to spend any more of their valuable time learning what broke now in the new release.

More important than providing a good user experience, is to not break existing user expectations.

You would think this is as obvious as a leopard’s spots, yet many software projects, including GNOME, don’t seem to understand this fact.

No project is more important than the users of the project. — Linus Torvalds

What users want

The problems I’ll talk about are not my invention, but conformed by GNOME user surveys, which show the most important issues according to the users:

  1. Lack of configuration options
  2. Developers don’t listen to users
  3. Bring back traditional interface

I knew these were important issues myself before the survey, but a survey was needed in order to know for sure. Of course, even after the survey, GNOME developers reject these issues are important to their users.

Developer attitude

In my opinion the main problem with GNOME is not just the code, code can be fixed, but the attitude from the developers (which is reflected in the code), and as users made it clear in the survey.

Many open source projects would kill to have the user-base GNOME had, and welcome their input with open arms, but GNOME neglected their users, they thought they were irrelevant, and they tried to dismiss their complaints with typical defenses, which of course don’t make sense.

no-feedback

People hate new things

By far the most widely used defense for the changes in GNOME 3 is that some people are backwards, and always hate new things, so it’s no surprise that they hate GNOME 3.

Any rational person would see the problem with this claim, but unfortunately I must spell it, because I had to explain it at great length to GNOME developers, and based on the responses, one would think they are incapable of seeing hasty generalization fallacies.

Say 50% of users hate GNOME 3, how many of them have legitimate reasons, and how many hate it just because they always hate new things? It’s impossible to know. So to dismiss every complaint saying “people hate new things” is totally stupid; you cannot know beforehand if they belong to this group or not, you first need to hear their complaints, and then decide if the complaints are invalid or not.

Saying “Jon doesn’t have legitimate complaints” makes sense (after analyzing his complaints), saying “people hate new things” does not, and GNOME developers do the later when people complain about GNOME 3.

Users don’t know what they want

Really? People don’t know if they want a punch in the face or not? Some people might not know what they want, but they definitely know what they don’t want.

Moreover, that’s a very rudimentary notion of user choice. Malcolm Gladwell explains rather well how it’s true that people don’t know what they want, or rather; they can’t tell you what they want, but when they get a taste of it, they most definitely can tell you: this is what I want.

If it wasn’t clear by now; GNOME 3 is not what a lot of people wanted.

gnome-hate

People complained about GNOME 2 too

Did this actually happen? If you google GNOME 2 for results between 2002 and 2004 you would find barely (if any) results that show negative comments, so if it did happen, the backlash probably wasn’t that bad, and it probably died rather quickly. Check the thread in Slashdot, and try to find one comment suggesting to go back to GNOME 1; I couldn’t find any.

Did anybody create forks after GNOME 2 was released the same way people forked after GNOME 3? No.

Yes, people complained about GNOME 2, but not nearly as much as they do about GNOME 3. There’s even an entire wikipedia article dedicated to the controversy over GNOME 3.

 

Sorry GNOME developers, none of your excuses for not listening to your users make sense. You should always listen to your users. Without them your project is nothing.

Configuration

The biggest complaint users had was the lack of configuration options, which could have been solved very easily, if the developers had more than two neurons in their brain, but instead, there’s only sub-par alternatives.

Advanced mode

GNOME 3 got rid of a bunch of useful configurations users relied on, and to defend themselves they said you could use gsettings manually, or install (or write) an extension, and so on, but I argued that there should be an “advanced mode” that the user can optionally turn on in order to further configure the system the way they wanted.

GNOME developers argued that this was a bad idea, because more code would need to be maintained which is absolutely not true for gsettings; the configurations are already there in the code, the only thing missing is the UI. Then they argued that it would mess up the configuration UI, which they wanted to keep clean, but adding a single check box can’t possibly mess with anything. In the end, I never received a single satisfactory answer of why an advanced mode didn’t make sense.

Tweak tool

The tweak tool is the closest thing to a sane configuration interface, however, it should be cleaned up, distributed by default, and integrated in the GNOME control center by adding an “Advanced mode” checkbox that when switched on enables these settings which should be distributed among the different “capplets”.

Even then, the amount of configurations available is not enough.

Shell extensions

Finally, there’s shell extensions which sound like a great idea at first, but if you think about it for thirty seconds, you realize the problem; there’s no APIs for extensions. This means extensions bring many problems.

First, there’s no guarantee that an extension will work the next version of GNOME, because it’s modifying the JavaScript code directly, and there’s no guarantee that the code will remain the same. There’s no extension API like with Chrome, or Firefox. The result is not unexpected; extensions break very easily from one version of GNOME to the next.

The second issue is that extensions can easily break GNOME, because they can modify absolutely anything in the shell.

gsettings

Another option is to manually change the configurations through the command line. This is obviously not user-friendly, and not ideal either.

 

GNOME developers made the mistake of not allowing configurability directly into GNOME, and as a result they have made the much needed configurations second class citizens, than no matter what you do, they don’t work as expected. The problem is very easy to solve; the configurations should be integrated into GNOME, and activated by a single switch, so their normal configurations are not disturbed. But talking sense to these guys is next to impossible.

Classic mode

Finally, after so much backlash from the users for years, GNOME developers had to implement the classic mode, so users could be able to run their beloved GNOME 2 interface with GNOME 3 technology.

Unfortunately, GNOME classic is more of a hack than anything else; it’s full of bugs and inconsistencies. Sure, this mode is still in its infancy, and will probably improve in the next releases, but it’s safe to bet that it would never be as polished and usable as GNOME 2 was.

Sorry GNOME devs; too little, too late.

Suckage

I am not going to list every single reason why GNOME 3 sucks, I would never finish this post, and there’s plenty of people that have already added their share (I’ll list some of them).

Personally for me the most obvious way to see that GNOME 3 defaults are brain-dead is the way alt+tab works. The whole purpose of work-spaces is to separate work, instead of having all your browser windows, terminals, editors, email client, and so on, on the same work-space, you split them among different ones. Even their own design references for GNOME shell say so. So, to make alt-tab cycle through the windows in all works-paces instead of only the current one is idiotic; it undermines the whole purpose of work-spaces.

Instead of accepting this obvious fact (which many users complained about), they disregard any feedback, and say “oh, you can use an extension for that”. Never mind the fact that a huge percentage of their users need to install the extension just to have a sane behavior, and that the extension can break at any moment.

gnome-3-is

Another quite obviously stupid behavior is to switch to an already running “application” instead of opening a new one. For example; if I press the Windows key, and type chromium, I expect a new browser window to open, but no, instead I’m unexpectedly dragged to another work-space where there’s already a browser window. This makes sense on single-window applications, but not on other ones.

Linus Torvalds and others complained about this, and I proposed a solution; add a menu item when right clicking on the application that says “Always open new window”; problem solved. Now each time the user tries to open this application, it’s done in a new window. But no, users don’t know what they want; GNOME developers know better what’s best for us.

The list of stupidities in GNOME 3 is never ending:

gnome-3

The Linux way

What GNOME should have done is simple; don’t ever, ever break user experience. This is how the Linux project has managed to become the most successful software project in history. There are no forks of the Linux kernel, simply because there’s no need; user experience is never broken; what works in v2.0, works in v3.0, and will work in v4.0. New features are added carefully, making sure nothing breaks, and users always have a way to make the system work the way they expect it to work.

GNOME shell should have been developed alongside GNOME 2 and users should have given the option to turn this mode on and off. Slowly, GNOME shell would get more features from GNOME 2, until it was a full replacement, and at the same time GNOME 2 would evolve to integrate GNOME 3 technologies (like GTK+ 3.0). Eventually GNOME shell becomes the default, but always with the option to use the classic interface. After some cycles, the GNOME shell interface is bound to be a full replacement for the classic one.

Unfortunately, they chose not to do this.

Going this way requires more effort, of course, but it’s the only way to move forward without loosing developers and users along the way. GNOME developers argued that they didn’t have the resources to do such careful move, but that is clearly false, as the developers working on MATE, Cinnamon and GNOME classic show; there’s developers interested in making things work for the traditional mode.

They chose not to listen to the warnings, and they became impatient and went forward with a move that had the potential of angering a lot of users. Well, this potential was fully realized, and now they are paying the consequences.

They were wrong

They argued this was like GNOME 2; the people complaining about it will eventually learn the new ways, and most will be happy. They were wrong.

Even to this day people keep complaining about GNOME 3, how the interface doesn’t make sense, how the developers don’t listen, and how the design is brain-dead.

There’s no other way to put it; GNOME 3 was a mistake.


by FelipeC at June 12, 2013 03:39 PM

June 11, 2013

Andy Wingoecmascript generators from a performance perspective

(Andy Wingo)

It's been really gratifying to see the recent interest in ES6 generators in V8. I'm still a Schemer at heart, but one thing all language communities should learn from JS is its enthusiasm and sense of joyful play. One can't spend much time around folks like James Long or Domenic Denicola without feeling the urge to go out and build something fun.

perfie perf perf perf

But this is a blog about nargery! A lot of people have been speculating about the performance impact of using generators, and I've been meaning to write about it, so perhaps this article will tickle your neuron.

A generator is a function that can suspend. So the first perf question to ask yourself is, does the performance of generators matter at all? If your generator spends more time suspended than active, then probably not. Though it's not the only application of generators, if you are using generators for asynchronous programming, then probably generator performance matters not at all.

But that's not very satisfying, right? Even though it probably doesn't matter, maybe it does, and then you need to make sure your mental model of what is fast and what is slow corresponds to reality.

crankshaft

So, the skinny: as implemented in V8, the primary perf impact of generators is that they do not get optimized by Crankshaft.

As you probably know, Crankshaft is V8's optimizing compiler. There are two ways a function can be optimized: on entry, because the function is called many times, or within a loop, because the loop is taking too long. In the first case it's fairly easy: you kick off a parallel task to recompile the function, reading the type feedback collected by the inline caches from the baseline compiler. Once you've made the optimized function, you swap the function's code pointer, and the next time you call the function you get the optimized version instead of the generic version.

The other way is if you are in a function, in a hot loop, and you decide to optimize the function while you are in it. This is called on-stack replacement (OSR), and is important for functions that are only called once but do have hot loops. (Cough KRAKEN cough.) It's trickier to do parallel compilation with OSR, as the function might have left the loop by the time recompilation finishes, but oh well.

So in summary, when V8 goes to optimize a function it will be in one of two states: inactive, because it hasn't started to run yet, or active, because it's stuck in a tight loop.

Generators introduce a new state for functions: suspended. You can know whether a function is active or inactive, but you can't know how many suspended generator activations are out in the JS heap. So you have multiple potential entry points to the function, which complicates the optimizer as it has to work on graphs with irreducible loops. Perhaps it's still possible to optimize, as OSR is a form of irreducible loops; I suspect though that you would end up compiling as many optimized functions as there are yield points, plus one for the function entry (and possibly another for OSR). Anyway it's a bit complicated.

Also, deoptimization (bailout) becomes more difficult if you can have suspended activations, and as a technical detail, it's tricky for V8 to efficiently capture the state of an activation in a way that the garbage collector can understand.

The upshot is that tight loops in generators won't run fast. If you need speed in a loop in a generator, you will need to call out to some other function (which itself would get optimized).

baseline

On the other hand, I should note that generators are optimized for quick suspend and resume. In a generator function, V8 stores local variables on the heap instead of on the stack. You would think this would make things slow, but that is not the case. Access to locals has the same speed characteristics: both stack and heap locals are accessed by index from a register (the stack pointer or the context pointer).

There is an allocation overhead when you enter a generator to create the heap storage, but it is almost never the case that you need to copy or allocate when suspending a generator. Since the locals are on the heap already, there is nothing to do! You just write the current instruction pointer (something you know at compile-time) into a slot in the generator object and return the result.

Similarly, when resuming you have to push on a few words to rebuild the stack frame, but after that's done you just jump back to where you were and all is good.

The exception to this case is when you yield and there are temporaries on the stack. Recall in my article on V8's baseline compiler that the full-codegen is a stack machine. It allocates slots to named locals, but temporary values go on the stack at run-time, and unfortunately V8's baseline compiler is too naive even to know what the stack height is at compile-time. So each suspension checks the stack height, and if it is nonzero, it calls out to a runtime helper to store the operands.

This run-time save would be avoidable in register machines like JavaScriptCore's baseline compiler, which avoids pushing and popping on the stack. Perhaps this note might spur the competitive urges of some fine JSC hacker, to show up V8's generators performance. I would accept JSC having faster generators if that's what it took to get generators into WebKit, at least for a while anyway :)

abstract musings

Many of you have read about the Futamura projections, in which one compiles a program via partial application of an interpreter with respect to a given input program. Though in the real world this does not appear to be a good strategy for implementing compilers, as so much of compilation is not simply about program structure but also about representation, there is a kernel of deep truth in this observation: the essence of compilation is partial evaluation of a strategy with respect to a particular program.

This observation most often helps me in the form of its converse. Whenever I find myself implementing some sort of generic evaluation strategy, there's a sign in my head that start blinking the word "interpreter". (Kinda like the "on-air" signs in studios.) That means I'm doing something that's probably not as efficient as it could be. I find myself wondering how I can make the strategy specific to a particular program.

In this case, we can think of suspending and resuming not as copying a stack frame out and in, but instead compiling specific stubs to copy out only the values that are needed, in the representations that we know that they have. Instead of looping from the bottom to the top of a frame, you emit code for each element. In this way you get a specific program, and if you manage to get here, you have a program that can be inlined too: the polymorphic "next" reduces to a monomorphic call of a particular continuation.

Anyway, Amdahl's law limits the juice we can squeeze from this orange. For a tight for-of loop with a couple of optimizations that should land soon in V8, I see generator performance that is only 2 times slower that the corresponding hand-written iterators that use stateful closures or objects: 25 nanoseconds per suspend/resume versus 12 for a hand-written iterator.

25 nanoseconds, people. You're using jQuery and asking for data from a server in the next country. It is highly unlikely that generators will be a bottleneck in your program :)

by Andy Wingo at June 11, 2013 01:48 PM

June 10, 2013

GStreamerGStreamer 1.0.7 binaries for Windows, Mac OS X and Android

(GStreamer)

The GStreamer team is pleased to announce binary builds for GStreamer 1.0.7, the plugin modules and all their dependencies. In future the team hopes to update these binary builds shortly after every stable GStreamer release. Builds are currently provided for Windows (32/64 bit), Mac OS X (32/64 bit x86) and Android (ARM). Future releases will include support for iOS.

Check out the release announcement mail for additional information or download the files for Windows, Mac OS X and Android.

June 10, 2013 08:00 PM

June 08, 2013

Jean-François Fortin TamStatus 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.

2013-06-08

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.

by nekohayo at June 08, 2013 09:32 PM

June 07, 2013

Thomas Vander SticheleSo then that happened

(Thomas Vander Stichele)

I’ve been more quiet than usual lately. I guess that’s what happens when you get married.

Oh, yeah, so that happened.

natalia-thomas-060-low

When I first met her years ago at a friend’s birthday drink she sat next to me all night and completely ignored me.

Years later I crashed a women only outing where she happened to be as well.

A random party, a six-o’clock-in-the-morning omelette on a terrace watching the sun come up, a birthday party, a jaunt to the Gentse Feesten and a long Christmas in august later, we were already together for two months before we knew it. I took her to my sister’s wedding, and not even three years later we went to our own, three weeks after I proposed. (Tip for anyone thinking of proposing: maybe the sauna isn’t the best place after all)

Getting married to her ended up being the most natural decision I’ve ever taken. And the answer to the most-asked question? Yes, it does make a difference. No, I didn’t expect it to. But it does.

Thank you to everyone who ever dumped me – I had no idea better things were coming.

by Thomas at June 07, 2013 04:04 PM

June 05, 2013

GStreamerGStreamer Core and Plugins 1.1.1 development release

(GStreamer)

The GStreamer team is pleased to announce a new development release with feature additions for the API and ABI-stable 1.x series of the GStreamer multimedia framework.

Check out the release notes for GStreamer core, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, or gst-libav, or download tarballs for gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, or gst-libav,

Check the release announcement mail for a list of changes.

June 05, 2013 07:00 PM

Andy Wingono master

(Andy Wingo)

It's difficult for anyone with an open heart and a fresh mind to look at the world without shuddering at its injustices: police brutality, obscene gaps between rich and poor, war and bombs and land mines, people without houses and houses without people. So much wrong! It is right and natural not only to feel revulsion, but to revolt as well. Fight the man! Down with the state! No god, no master!

So to those working against foreclosures and evictions of families in your neighborhoods, more power to you. Fight the good fight.

However, revolt is unfortunately not sufficient. We must also think beyond the now and imagine a better world: life after the revolution.

I'm sure I've lost some of you now, and that's OK. We are all at different points of political consciousness, and you can't speak to all at the same time. Some of the words like "revolution" probably bother some people. It sounds strident, right? But if you agree (and perhaps you do not) that there are fundamental problems with the way the world works, and that symptoms like banks kicking families out of houses using riot police are ultimately caused by those problems, then any real change must also be fundamental: at the foundation, where the roots are. Radical problems need radical solutions. Revolution is no more (and no less!) than a radically different world.

For me, one of these roots to dig up is hierarchy. I take as a principle that people should have power over and responsibility for decisions to the extent that they are affected, and hierarchy is all about some people having more power than others. Even if you do away with capitalism, as in the early Soviet Union, if you don't directly address the issue of hierarchy, classes will emerge again. A world in which some people are coordinators and other people are workers will result in a coordinator class that gradually accretes more and more power. Hierarchy is in essence tyrannical, though any specific instance may be more or less so.

On the other side of things, hierarchy deadens those at the bottom: the listless students, the mechanical workers, the passive and cynical voters. The revolution has to come about in a way that leaves people more alive and curious and energetic, and that seems to correspond not only with greater freedom but also with personal responsibility. I think that a world without hierarchy would be a world whose people would be more self-actualized and self-aware, as they would have more responsibility over the situations that affect their lives and those around them.

Well. I don't want to wax too theoretical here, in what I meant to be an introduction. I've been having these thoughts for a while and finally a couple years ago I decided to join in a collective experiment: to practice my chosen craft of computer programming within a cooperative context. I haven't had a boss since then, and I haven't been the boss of anyone. I'm not even my own boss. There are no masters!

I've gotten so used to this way of working that sometimes I forget how unusual it is to work in a cooperative. Also, we're usually too busy hacking to write about it ;) So in the next few articles I'll take a look at the internal structure of our company, Igalia, and try to give some insight into what it's like working in a cooperative.

by Andy Wingo at June 05, 2013 01:35 PM

Gustavo Orrilloac

Yesterday was a very important day for the Processing project, as a new stable version, “the 2.0″, has been released. This release is the result of the hard work of a small team of volunteers over the course of the past two years, plus the fundamental support and contributions from the entire Processing community. For […]

by ac at June 05, 2013 12:24 AM

June 04, 2013

Arun RaghavanPulseAudio 4.0 and more

And we’re back … PulseAudio 4.0 is out! There’s both a short and super-detailed changelog in the release notes. For the lazy, this release brings a bunch of Bluetooth stability updates, better low latency handling, performance improvements, and a whole lot more. :)

One interesting thing is that for this release, we kept a parallel next branch open while master was frozen for stabilising and releasing. As a result, we’re already well on our way to 5.0 with 52 commits since 4.0 already merged into master.

And finally, I’m excited to announce PulseAudio is going to be carrying out two great projects this summer, as part of the Google Summer of Code! We are going to have Alexander Couzens (lynxis) working on a rewrite of module-tunnel using libpulse, mentored by Tanu Kaskinen. In addition to this, Damir Jelić (poljar) working on improvements to resampling, mentored by Peter Meerwald.

That’s just some of the things to look forward to in coming months. I’ve got a few more things I’d like to write about, but I’ll save that for another post.

by Arun at June 04, 2013 02:45 AM

May 21, 2013

GStreamerGStreamer Conference 2013: Registration now open, Call for Papers

(GStreamer)

About the GStreamer Conference

The GStreamer Conference 2013 will take place from 22-23 October 2013 in Edinburgh (UK), and will be co-hosted with the Embedded Linux Conference Europe and the Automotive Linux Summit.

It is a conference for developers, decision-makers, and anyone else interested in the GStreamer multimedia framework and open source multimedia.

Registration now open

You can now register for the GStreamer Conference 2013 on the conference website.

Call for Papers

The initial submission needs to be only a couple of paragraphs describing the talk you want to give and the desired length of your talk (please allow for 5-10 minutes of questions at the end as well).

Talks can be on almost anything multimedia related, ranging from talks about applications to challenges in the lower levels in the stack or hardware.

Please send all proposals to gstreamer-conference@lists.freedesktop.org.

May 21, 2013 11:00 PM

May 18, 2013

Thomas Vander SticheleOrganizing photo libraries

(Thomas Vander Stichele)

The weather’s picking up so it’s time for spring cleaning around the house. When I moved back to Barcelona three years ago I took with me my old analogue photos and negatives, with the idea of sorting through them at some point and getting them digitized. And while I’m at it, maybe it’s time to pull all my various folders of photos together too and organize them.

Well, I finally started. I grouped the negatives, labeled them by year, put them in individual envelopes, and handed them off to a professional lab to scan them after doing a quick test run on one set (which turned out great, but it’s *really* annoying me that they scan to JPEG by default, charge 40% extra for TIFF, and use a non-multiple-of-8 resolution to scan at which means I can’t losslessly rotate the negatives. Yes, I’m anal.)

So now I pulled together all my various folders of photos, and before I start doing tagging and stuff like that, I want to organize them in a decent folder layout. Googling for ideas pretty much suggests that the way to go is

YYYY/MM/DD

with possibly some description together with the DD

I’m not really happy about that, however, because there are certain things I’d like to be able to do:

  • easily see where photos come from – did I make them ? did I get them from someone ? Did I download them from Facebook ?
  • Are these original files from a camera without editing ?
  • Are these the original scans ? From negatives ? From actual photos ? Or are they retouched, rotated, denoised, …
  • Are these photos SFW ? Can I point my media center slideshow to this directory and have it safely show any photos under it ? (What do you mean, you’ve never snowboarded at night in only your underwear, and mooning the photographer ?) Or maybe not even SFW, but simply watchable and reasonable quality or subject material?

I realize some of these issues can not be resolved simply with a directory layout. But I’m sure some of you must have had similar issues or come up with a slightly better layout ?

Point me in the right direction please.

by Thomas at May 18, 2013 11:51 AM

May 15, 2013

Stefan Kost15 May 2013

(Stefan Kost) buzztard is now buzztrax

We applied as an organisation to take part in the Google Summer of Code program, but got rejected mainly due to the project name. As this was not the first time people where uncomfortable with the name, we renamed the project - buzztard is now called buzztrax. The homepage with the wiki and wordpress already got moved. The renamed codebase is online at github. The mailing lists have been migrated to buzztrax.org. A few things still need to be fixed (e.g. file releases).

Besides the renaming there are also some improvements on the code side. I am probably the last one to discover the g_signal_handlers_disconnect_by_* macros. Using these made the code a bit leaner. I also worked on the level-meter features. I did some cleanups on the widget. The syncing code is more efficient as we listen to sync-messages on the gstreamer side to avoid another thread round trip. Song rendering can disabled the level-meters for less noise on the screen and some performance savings. The song-rendering now uses the TOC support in gstreamer-1.0. That means that the labels of a song (intro, chorus, break, ...) will end up in wav and flac files right now. When other formats support toc, this will automatically work for those formats too. The flag in ogg muxing got fixed in upstream and now works for us again.

56 files changed, 715 insertions(+), 631 deletions(-)

May 15, 2013 12:10 PM

May 10, 2013

Thomas Vander Stichelemorituri and Hidden Track One Audio

(Thomas Vander Stichele)

I have tomorrow (saturday) blocked out for a whole day of morituri hacking as I will be home alone.

One of the things a lot of morituri users are puzzled by is its relentless drive to extract every single sample of audio from the CD. Currently, even if it’s a really short pre-gap, and most likely just an inaccurate master or burn, with no useful audio in it.

For me, that was a design goal of morituri – I want to be able to exactly reproduce a CD as is. That is to say, ripping a CD should extract *all* audio from the CD, and it should be possible to make a copy of that CD and then rip that copy, and end up with exactly the same result as from the original CD. (I’m sure there’s a fancy scientific term for that that I can’t remember right now)

To a lot of other people, it seems to be annoying and they don’t like having those small almost empty files lying around.

So I thought I’d do something about that, and that it might be useful as well to analyze my current collection of tracks and figure out what’s in there. Maybe I can find some hidden gems that I hadn’t noticed before?

So I added a quick task to morituri that calculates the maximum sample value (I didn’t want to use my own level element in GStreamer for this as I wanted to make sure it was actual digital zero; this should be done in an element instead though, but I preferred the five minute hack for this one).

And then I ran:

rip debug maxsample /mnt/nas/media/audio/rip/morituri/own/album/*/00*flac

Sadly, that turned up 0 as the biggest sample for all these tracks!

Wait, what? I spent all that time on getting those secret tracks ripped just to get none? That’s not possible! I know some of those tracks!

Maybe the algorithm is wrong. Nope, it works fine on all the regular tracks.

Oh, crap. Maybe morituri has been ripping silence all this time because my CD drive can’t get that data off. Yikes, that would be a bit of egg on my face.

No, it works if I check that Bloc Party track I know about.

Ten minutes of staring at the screen to realize that, while I was outputting names from a variable from the for loop over my arguments, the track I was actually passing to the task was always the first one. Duh. Problem solved.

As for what I found in my collection:

  • a cute radio jingle that brought back memories from a live bootleg I had made myself of Bloem. That’s from over ten years ago, but that must have been around the time I learned about the existence of HTOA and wanted to get one in
  • found unknown HTOA tracks on Art Brut’s Bang Bang Rock & Roll, Mew’s Half the world is watching me; not their best stuff
  • soundscapey or stagesetting tracks on QOTSA’s Songs for the Deaf, Motorpsycho’s Angels and Daemons at play And Blissard; not that worth it (the Blissard track was ok, but really quiet)
  • Pulp hid a single piano chord in a 2 second pre-gap on This is Hardcore; very curious. It’s not an intro to the first track, because it doesn’t fit with the sound at all.
  • Damien Rice hid a demo version of 9 Crimes (the first track) in the pregap; instead of piano and female vocals, he plays guitar and sings all the parts.
  • Got reacquainted with my favourite HTOA tracks: the orchestral quasi-wordless medley on the Luke Haines/Das Capital disc; the first Bloc Party album with a beautiful instrumental (up there with the hidden track at the end of Placebo’s first album; both bands delivering an atypical but stunning moodscape; the beautiful cover of Ben Kenobi’s Theme by Arab Strap on the Cherubs EP (no idea why that landed in my album dir, that needs to be fixed); the silly Soulwax skit for their second album.

Of course, Wikipedia has the last word on everything

I note that they think Pulp recorded a cymbal, not a piano. And now that I see the title of the QOTSA hidden track, I get the joke I think.

In total, on my album collection of 1564 full CD’s, I have 171 HTOA’s ripped, 138 tracks of pure digital silence, and only about 11 are actually useful tracks.

I expected to find more gems in my collection. I’ll go through ep’s, singles and compilations next just to be sure.

But with this code in hand, maybe it’s time to add something to morituri to save the silent HTOA tracks as pure .cue information.

by Thomas at May 10, 2013 08:08 PM

May 08, 2013

Andy Wingogenerators in v8

(Andy Wingo)

Hey y'all, ES6 generators have landed in V8! Excellent!

Many of you know what that means already, but for those of you that don't, a little story.

A few months ago I was talking with Andrew Paprocki over at Bloomberg. They use JavaScript in all kinds of ways over there, and as is usually the case in JS, it often involves communicating with remote machines. This happens on the server side and on the client side. JavaScript has some great implementations, but as a language it doesn't make asynchronous communication particularly easy. Sure, you can do anything you want with node.js, but it's pretty easy to get stuck in callback hell waiting for data from the other side.

Of course if you do a lot of JS you learn ways to deal with it. The eponymous Callback Hell site lists some, and lately many people think of Promises as the answer. But it would be nice if sometimes you could write a function and have it just suspend in the middle, wait for your request to the remote computer to come through, then continue on.

So Andrew asked if me if we could somehow make asynchronous programming easier to write and read, maybe by implementing something like C#'s await operator in the V8 JavaScript engine. I told him that the way into V8 was through standards, but that fortunately the upcoming ECMAScript 6 standard was likely to include an equivalent to await: generators.

ES6 generators

Instead of returning a value, when you first call a generator, it returns an iterator:

// notice: function* instead of function
function* values() {
  for (var i = 0; i < arguments.length; i++) {
    yield arguments[i];
  }
}

var o = values(1, 2, 3);  // => [object Generator]

Calling next on the iterator resumes the generator, lets it run until the next yield or return, and then suspends it again, resulting in a value:

o.next(); // => { value: 1, done: false }
o.next(); // => { value: 2, done: false }
o.next(); // => { value: 3, done: false }
o.next(); // => { value: undefined, done: true }

Maybe you're the kind of person that likes imprecise, incomplete, overly abstract analogies. Yes? Well generators are like functions, with their bodies taken to the first derivative. Calling next integrates between two yield points. Chew on that truthy nugget!

asynchrony

Anyway! Supending execution, waiting for something to happen, then picking up where you left off: put these together and you have a nice facility for asynchronous programming. And happily, it works really well with promises, a tool for asynchrony that lots of JS programmers are using these days.

Q is a popular promises library for JS. There are some 250+ packages that depend on it in NPM, node's package manager. So cool, let's take their example of the "Pyramid of Doom" from the github page:

step1(function (value1) {
    step2(value1, function(value2) {
        step3(value2, function(value3) {
            step4(value3, function(value4) {
                // Do something with value4
            });
        });
    });
});

The promises solution does at least fix the pyramid problem:

Q.fcall(step1)
.then(step2)
.then(step3)
.then(step4)
.then(function (value4) {
    // Do something with value4
}, function (error) {
    // Handle any error from step1 through step4
})
.done();

But to my ignorant eye, some kind of solution involving a straight-line function would be even better. Remember what generators do: they suspend computation, wait for someone to pass back in a result, and then continue on. So whenever you would register a callback, whenever you would chain a then onto your promise, instead you suspend computation by yielding.

Q.async(function* () {
  try {
    var value1 = yield step1();
    var value2 = yield step2(value1);
    var value3 = yield step3(value2);
    var value4 = yield step4(value3);
    // Do something with value4
  } catch (e) {
    // Handle any error from step1 through step4
  }
});

And for a super-mega-bonus, we actually get to use try and catch to handle exceptions, just as Gods and Brendan intended.

Now I know you're a keen reader and there are two things that you probably noticed here. One is, where are the promises, and where are the callbacks? Who's making these promises anyway? Well you probably saw already in the second example that using promises well means that you have functions that return promises instead of functions that take callbacks. The form of functions like step1 and such are different when you use promises. So in a way the comparison between the pyramid and the promise isn't quite fair because the functions aren't quite the same. But we're all reasonable people so we'll deal with it.

Note that it's not actually necessary that any of the stepN functions return promises. The promises library will lift a value to a promise if needed.

The second and bigger question would be, how does the generator resume? Of course you've already seen the answer: the whole generator function is decorated by Q.async, which takes care of resuming the generator when the yielded promises are fulfilled.

You don't have to use generators of course, and using them with Q does mean you have to understand more things: not only standard JavaScript, but newfangled features, and promises to boot. Well, if it's not your thing, that's cool. But it seems to me that the widespread appreciation of await in C# bodes well for generators in JS.

ES6, unevenly distributed

Q.async has been part of Q for a while now, because Firefox has been shipping generators for some time.

Note however that the current ES6 draft specification for generators is slightly different from what Firefox ships: calling next on the iterator returns an object with value and done properties, whereas the SpiderMonkey JS engine used by Firefox uses an exception to indicate that the iterator is finished.

This change was the result of some discussions at the TC39 meeting in March, and hasn't made it into a draft specification or to the harmony:generators page yet. All could change, but there seems to be a consensus.

I made a patch to Q to allow it to work both with the old SpiderMonkey-style generators as well as with the new ES6 style, and something like it should go in soon.

give it to me already!

So yeah, generators in V8! I've been working closely with V8 hackers Michael Starzinger and Andreas Rossberg on the design and implementation of generators in V8, and I'm happy to say that it's all upstream now, modulo yield* which should go in soon. Along with other future ES6 features, it's all behind a runtime flag. Pass --harmony or --harmony-generators to your V8 to enable it.

Barring unforeseen issues, this will probably see the light in Chromium 29, corresponding to V8 3.19. For now though this hack is so hot out of the fire that it hasn't even had time to cool down and make it to the Chrome Canary channel yet. Perhaps within a few weeks; whenever the V8 dependency in Chrome gets updated to the 3.19 tree.

As far as Node goes, they usually track the latest stable V8 release, and so for them it will probably also be a few weeks before it goes in. You'll still have to run Node with the --harmony flag. However if you want a sneak preview of the future, I uploaded a branch of Node with V8 3.19 that you can build from source. It might mulch your cat, but life is not without risk on the bleeding_edge.

Finally for Q, as I said ES6 compatibility should come soon; track the progress or check out your own copy here.

final notes

Thanks to the V8 team for their support in this endeavor, especially to Michael Starzinger for enduring my constant questions. There's lots of interesting things in the V8 pipeline coming out of Munich. Thanks also to Andrew Paprocki and the Bloomberg crew for giving me the opportunity to fill out this missing piece of real-world ES6. The Bloomberg folks really get the web.

This has been a hack from Igalia, your friendly neighborhood browser experts. Have fun with generators, and happy hacking!

by Andy Wingo at May 08, 2013 07:31 PM

May 07, 2013

Thomas Vander SticheleVotes for talks at open source conferences

(Thomas Vander Stichele)

I’ve never been a fan of voting for talks, because it tends to be poorly implemented under the guise of democracy. Of course it’s easy for me to talk, I’ve never organized anything at that scale.

I’ll give two examples on why I feel this way, one of which triggering today’s blog post.

First off, my colleague Marek submitted a talk to Djangocon. The talk was about how to use feat (a toolkit we wrote for livetranscoding) to serve Django pages, but in such a way that they can use Deferreds to remove the concurrency bottleneck of “1 request at a time” per process running Django.

Personally, to me, this is one of the most irritating design choices of Django – from the ground up it was built synchronously (which could have been fine in most places). But the fact that, when you get a request, you have to always synchronously respond to it (and block every other request for that process in the meantime) is a design choice that could have easily been avoided.

In our particular use case, it was really painful. If our website has to do an API request to some other service we don’t control that can easily take 30 seconds, our process throughput suddenly becomes 2 pages per minute. All the while, the server is sitting there waiting.

Yes, you can throw RAM at the problem and start 30 times more processes; or thread out API requests; or farm it out to Celery, and do some back-and-forthing to see when the call’s done. Or do any other number of workarounds for a fundamental design choice.

Since we like Twisted, we preferred to throw Twisted at the problem, and ended up with something that worked.

Anyway, that’s a lot of setup to explain what the talk was about. Marek submitted the talk to DjangoCon, and honestly I didn’t expect it to get much traction because, when you’re inside Django, you think like Django, and you don’t really realize that this is a real problem. Most people who do realize it switch away to something else.

But to my surprise, Marek’s talk was the most-voted talk! I wish I could link to the results, but of course that vote site is no longer online.

I guess I expected that would mean he’d be presenting at DjangoCon this year. So I asked him today when his talk was, and he said “Oh that’s right. I did not get accepted.”

Well, that was a surprise. Of course, the organising committee reserves the right to decide on their own – maybe they just didn’t like the talk. But if you ask your potential visitors to vote, you’d expect the most-voted talk to make it on the schedule no ?

The feedback Marek got from them was surprising too, though. Their first response was that this talk was too similar to another talk, titled “How to combine JavaScript & Django in a smart way”. Now, I’m not a JavaScript expert, but from the title alone I can already tell that it’s very unlikely that these two talks have many similarities beyond the word ‘Django’.

After refuting that point, their second reason was that they wanted more experienced speakers (but they didn’t ask Marek for his experience), and their third reason was that the talk was in previous editions of DjangoCon US/EU (it’s unclear whether they meant his talk or the JavaScript one, but Marek’s definitely wasn’t, and we couldn’t find any mention of the other talk in previous conferences. I’m also not sure why that even matters one way or the other. This email thread was in Polish, so I have to rely on Marek’s interpretation of it)

Personally, my reaction would have been to complain to the organizers or Django maintainers. Marek’s flegmatic attitude was much better though – after such an exchange, he simply doesn’t want to have anything to do with the conference.

He’s probably right – it’s hard to argue with someone who doesn’t want to invite you and is lying about the reasons.

The second example is BCNDevCon, a great conference here in Barcelona, organized by a guy who used to work for Flumotion who I have enormous respect for. I’ve never seen anyone create such a big conference over so little time.

He believes strongly in the democratic aspect, and as far as I can tell constructs the schedule solely based on the votes.

Sadly I didn’t go to the last one, and the reason is simply because I felt that the talks that made it were too obviously corporate. A lot of talks were about Microsoft products, and you could tell that they won votes because people’s coworkers voted on talks. I’m not saying that’s necessarily wrong – given that he worked at our company and has friends here, I’m sure people working here presenting at his conference have also done vote tending. It’s natural to do so. But there should be a way to balance that out.

I think the idea of voting is good, but implementation matters too. Ideally, you would only want people that actually are going to show up to vote. I have no idea how you can ensure that, though. Do you ask people to pre-pay ? Do you ask them to commit to pay if at least 50% of their votes make it in the final schedule, kickstarter-style ?

These two examples are on opposite extremes of voting. One conference simply disregards completely what people vote on. If I had voted or bought a ticket, I would feel lied to. Why waste the time of so many people? The other conference puts so much stock in the vote, that I feel the final result was strongly affected. I seriously doubt all those Windows 8 voters actually showed up.

Does anyone have good experiences with conference voting that did work? Feel free to share!

by Thomas at May 07, 2013 11:53 AM

May 03, 2013

Thomas Vander SticheleIf I was 16 years younger…

(Thomas Vander Stichele)

I’d totally try and be the intern for pinboard.

The money is great for a summer job, but that’s not the important part. pinboard seems interesting, it’s a real service, and it’s (I assume) small enough to understand from top to bottom. Contrary to, say, a Google Summer of Code project, you get to touch a real existing service, and from what I can tell from the blog you get to do it with a smart and funny guy.

You’ve got five weeks left; even if you’re in the middle of exams right now, apply!

(And if you do, why not add the features to merge and rename tags while you’re at it?)

by Thomas at May 03, 2013 09:30 PM

April 28, 2013

Jean-François Fortin TamNo 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:

slap

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:

2013-04-27

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):

2013-04-29

by nekohayo at April 28, 2013 04:19 AM

April 26, 2013

GStreamerGStreamer Core and Plugins 1.0.7 bug-fix release

(GStreamer)

The GStreamer team is pleased to announce another bug-fix release for the new API and ABI-stable 1.x series of the GStreamer multimedia framework.

Check out the release notes for GStreamer core, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, or gst-libav, or download tarballs for gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, or gst-libav,

Improvements include:

  • better support for static plugins
  • streamsynchronizer is now a public element, useful in HLS pipelines for example
  • osxaudio plugin ported to 1.0
  • androidmedia plugin is ported to 1.0
  • internal libav snapshot in gst-libav has been updated to libav 0.8.6
  • Now uses frame based threading if possible and disables slice based threading until libav 0.9.x is used (as is the case in git master already) This provides potentially better performance and fixes some display corruptions caused by bugs in the slice based threading
  • a number of bug fixes

April 26, 2013 02:00 PM

April 19, 2013

Christian SchallerBrno GUADEC Call for Papers!

(Christian Schaller)

I would like to give everyone a friendly reminder that Saturday the 27th of April is the official deadline for the GUADEC 2013 Call for Papers. So make sure to get your proposal submitted.

We hope to have a wide range of talks this year, including talks on related subjects such as Wayland and Multimedia, so don’t automatically assume that you will not get a talk approved because its not ‘pure GNOME’.

GUADEC this year will be in Brno in the Czech Republic, so I hope to see as many of you as possible here.

by uraeus at April 19, 2013 10:29 AM

Michael SheldonErudite now available for Symbian Belle

(Michael Sheldon)

Erudite displaying a book library

Overview

Erudite makes it possible to use Amazon’s Cloud Reader on various mobile platforms which aren’t officially supported by Amazon. You can either read books online, or download them for reading offline. Your progress in a book is then also kept synchronised between your phone and other Kindle devices.

Symbian Belle support

Until recently Erudite only supported MeeGo Harmattan and Mer based phones (such as the Nokia N9), but now it’s also available for Symbian Belle phones as well. I’ll try and put together a build for Symbian Anna phones in the near future.

There’s a fairly comprehensive review of Erudite for Symbian over on All About Symbian: Erudite review.

Upcoming features

In the next release for both Symbian and MeeGo I’ll be focusing on orientation switching support, so users can optionally view their books in landscape mode, as well as investigating some apparent issues with very large books.

Download

  • Symbian Belle version — Nokia 701, Nokia C6-01, Nokia C7-00, Nokia N8-00, Nokia X7-00, Nokia E6-00, Nokia 808 Pureview, Nokia 603, Nokia Oro, Nokia E7-00, and Nokia 700
  • MeeGo Harmattan version — Nokia N9, Nokia N950

by Mike at April 19, 2013 09:51 AM

April 18, 2013

Andy Wingoinside full-codegen, v8's baseline compiler

(Andy Wingo)

Greetings to all. This is another nargish article on the internals of the V8 JavaScript engine. If that's your thing, read on. Otherwise, here's an interesting interview with David Harvey. See you laters!

full-codegen

Today's topic is V8's baseline compiler, called "full-codegen" in the source. To recall, V8 has two compilers: one that does a quick-and-dirty job (full-codegen), and one that focuses on hot spots (Crankshaft).

When you work with V8, most of the attention goes to Crankshaft, and rightly so: Crankshaft is how V8 makes code go fast. But everything goes through full-codegen first, so it's still useful to know how full-codegen works, and necessary if you go to hack on V8 itself.

The goal of this article is to recall the full-codegen to mind, so as to refresh our internal "efficiency model" of how V8 runs your code (cf. Norvig's PAIP retrospective, #20), and to place it in a context of other engines and possible models.

stack machine

All JavaScript code executed by V8 goes through full-codegen, so full-codegen has to be very fast. This means that it doesn't have time to do very much optimization. Even if it did have time to do optimization (which it doesn't), full-codegen lacks the means to do so. Since the code hasn't run yet when full-codegen compiles it, it doesn't know anything about types or shapes of objects. And as in other JS engines, full-codegen only compiles a function at a time, so it can't see very far. (This lets it compile functions lazily, the first time they are executed. Overall syntactic validity is ensured by a quick "pre-parse" over the source.)

I have to admit my surprise however at seeing again how simple full-codegen actually is: it's a stack machine! You don't get much simpler than that. It's shocking in some ways that this is the technology that kicked off the JS performance wars, back in 2008. The article I wrote a couple years ago does mention this, but since then I have spent a lot of time in JSC and forgot how simple things could be.

Full-codegen does have a couple of standard improvements over the basic stack machine model, as I mentioned in the "two compilers" article. One is that the compiler threads a "context" through the compilation process, so that if (say) x++ is processed in "effect" context, it doesn't need to push the initial value of x on the stack as the result value. The other is that if the top-of-stack (ToS) value is cached in a register, so that even if we did need the result of x++, we could get it with a simple mov instruction. Besides these "effect" and "accumulator" (ToS) contexts, there are also contexts for pushing values on the stack, and for processing a value for "control" (as the test of a conditional branch).

and that's it!

That's the whole thing!

Still here?

What about type recording and all that fancy stuff, you say? Well, most of the fancy stuff is in crankshaft. Type recording happens in the inline caches that aren't really part of full-codegen proper.

Full-codegen does keep some counters on loops and function calls and such that it uses to determine when to tier up to Crankshaft, but that's not very interesting. (It is interesting to note that V8 used to determine what to optimizing using a statistical profiler, and that is no longer the case. It seems statistical profiling would be OK in the long run, but as far as I understand it didn't do a great job with really short-running code, and made it difficult to reproduce bugs.)

I think -- and here I'm just giving my impression, but fortunately I have readers that will call my bullshit -- I think that if you broke down basic JavaScript and ignored optimizable hot spots, an engine mostly does variable accesses, property accesses, and allocations. Those are the fundamental things to get right. In a browser you also have DOM operations, which Blink will speed up at some point; and there are some domain-specific things like string operations and regular expressions of course. But ignoring that, there are just variables, properties, and allocations.

We'll start with the last bit. Allocation is a function of your choice of value representation, your use of "hidden classes" ("maps" in V8; all engines do the same thing now), and otherwise it's more a property of the runtime than of the compiler. (Crankshaft can lower allocation cost by using unboxed values and inlining allocations, but that's Crankshaft, not full-codegen.)

Property access is mostly handled by inline caches, which also handle method dispatch and relate to hidden classes.

The only thing left for full-codegen to do is to handle variable accesses: to determine where to store local variables, and how to get at them. In this case, again there's not much magic: either variables are really local and don't need to be looked up by name at runtime, in which case they can be allocated on the stack, or they persist for longer or in more complicated scopes, in which case they go on the heap. Of course if a variable is never referenced, it doesn't need to be allocated at all.

So in summary, full-codegen is quick, and it's dirty. It does its job with the minimum possible effort and gets out of the way, giving Crankshaft a chance to focus on the hot spots.

comparison

How does this architecture compare with what other JS engines are doing, you ask?

I have very little experience with SpiderMonkey, but as far as I can tell, with every release they they get closer and closer to V8's model. Earlier this month Kannan Vijayan wrote about SpiderMonkey's new baseline compiler, which looks to be exactly comparable to full-codegen. It's a stack machine that emits native code. It looks a little different because it operates on bytecode and not the AST, as SpiderMonkey still has an interpreter hanging around.

JavaScriptCore, the WebKit JavaScript engine, is similar on the surface: it also has a baseline compiler and an optimizing compiler. (In fact it's getting another optimizing compiler soon, but that's a story for another article). But if you look deeper, I think JSC has diverged from V8's model in interesting ways.

Besides being a register machine, a model that has inherent advantages over a stack machine, JavaScriptCore also has a low-level interpreter that uses the same calling convention as the optimizing compiler. I don't think JSC is moving in V8's direction in this regard; in fact, they could remove their baseline compiler entirely, relying instead on the interpreter and the optimizing compiler. JSC also has some neat tricks related to scoping (lazy tear-off); again, a topic for some future article.

summary

The field is still a bit open as to what is the best approach to use for cold code. It seems that an interpreter could still be a win, because if not, why would SpiderMonkey keep one around, now that they have a baseline compiler? And why would JSC add a new one?

At the same time, it seems to me that one could do more compile-time analysis at little extra cost, to speed up full-codegen by allocating more temporaries into slots; you would push and pop at compile-time to avoid doing it at run-time. It's unclear whether it would be worth it, though, as that analysis would have to run on all code instead of just the hot spots.

Hopefully someone will embark on the experiment; it should just be a simple matter of programming :) Until next time, happy hacking!

by Andy Wingo at April 18, 2013 03:45 PM

April 11, 2013

Jean-François Fortin TamPiTiVi 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!

by nekohayo at April 11, 2013 07:09 PM

Arun RaghavanPulseAudio in GSoC 2013

That’s right — PulseAudio will be participating in the Google Summer of Code again this year! We had a great set of students and projects last year, and you’ve already seen some their work in the last release.

There are some more details on how to get involved on the mailing list. We’re looking forward to having another set of smart and enthusiastic new contributors this year!

p.s.: Mentors and students from organisations (GStreamer and BlueZ, for example), do feel free to get in touch with us if you have ideas for projects related to PulseAudio that overlap with those other projects.

by Arun at April 11, 2013 11:34 AM

April 09, 2013

Stefan Kost9 Apr 2013

(Stefan Kost) buzztard & gstreamer hackfest

This month I mostly cleaned up small bits and pieces from the gstreamer-1.0 port. Most notably multitrack encoding works again. The handling of EOS and starting of the next track was racy. Speaking of the recording dialog - this one now has some basics for a silent mode implemented. For now it only disables the scrolling in the sequence view. Next thing would be to disable the level meters.

I hacked a bit more on the child-proxy iface. This now turned into utility functions that allows to write:
bt_child_proxy_set(obj, "prop1::prop2::prop3", val, NULL);
So what does this do?
GObject obj1, obj2;
g_object_get(obj, "prop1", &obj1, NULL);
g_object_get(obj1, "prop2", &obj2, NULL);
g_object_set(obj2, "prop3", val, NULL);
g_object_unref (obj2);
g_object_unref (obj1);

This saved quite a few lines of C in buzztard. I wonder if this is something we want to add to glib? If we do I would go for a single ':' as a separator and we might also want to consider starting the property with one:
g_object_set(obj, ":prop1:prop2:prop3", val, NULL);
The leading ':' would help to quickly detect whether we need to split the property name and recurse into child objects. The whole scheme is backwards compatible as property names are not allowed to contain ':'.

In the end of march I attended the GStreamer hackfest in Milano. First I looked into a few tests - both on GStreamer and buzztard side. On the GStreamer side adder has some test fixes. On the buzztard side I improved my encoding tests. Wim gave me the crucial tip that fixed the dynamic adding/removing of analyzers while playing. Maybe I can try that for machines again. I showed the parser for controller-setups to some people and did smaller changes on it. I also discussed what we could do with gst-tracelib for gst-1.0 and started a new design-draft for it.

41 files changed, 871 insertions(+), 816 deletions(-)

April 09, 2013 08:31 PM

Christian SchallerNo GStreamer in this years Google Summer of Code

(Christian Schaller)

Some sad news, GStreamer did not get accepted to the 2013 Google Summer of Code. We don’t know the exact reasons, but all we can do at this point is redouble our efforts to get accepted again next year.

In the meantime not all hope is lost. You can still do a Google Summer of Code involving GStreamer with some of the other organisations that did get approved. For instance if you have an idea for a great multimedia desktop application using GStreamer you can try submitting that to for instance GNOME or KDE depending on your UI toolkit of choice as one example. In the past GNOME has also been open to hosting some pure GStreamer projects so you can always try submitting such too. In general I recommend people to take a look at the list of accepted organisations and see if there are projects which technologies would be relevant to the GSoC project you want to do and the apply with them. Also remember you can submit the same project to multiple organisations if it fits multiple projects.

Also the PiTiVi video editor did get approved so I strongly encourage you to take a look at their wonderful ideas page and submit a proposal to do a PiTiVi project.

by uraeus at April 09, 2013 09:29 AM

April 05, 2013

Jean-François Fortin TamLe nipponophone de l’autobus

Hier dans l’autobus, j’ai eu la chance de tomber sur un homme blanc parlant au téléphone… dans le langage du soleil levant. Après un très long moment de tergiversation mentale après la fin de son appel, j’osai:

«Bonjour monsieur, parlez-vous français? C’est pas tous les jours que j’entends parler japonais dans cet autobus, et vous le parlez très bien! Où l’avez-vous appris?»

«J’ai vécu au Japon pendant cinq ans!»

S’en suit une quinzaine de minutes de discussion où je découvris des choses qui changèrent certaines de mes perceptions, jusque-là biaisées par les ouï-dires.

D’abord, le taux de change entre le peso canadien et le Yen est plutôt désavantageux pour les canadiens en ce moment: l’économie japonaise, bien que mal en point du point de vue intérieur, reste assez forte sur le point de vue international, spécialement en comparaison avec l’Europe en crise depuis 2008-2009. Les investisseurs se replient alors sur une monnaie stable comme le Yen (ça, je dois dire que j’ai du mal à comprendre cette subtilité). Si l’Europe reprenait du poil de la bête, la valeur du Yen se rebalancerait possiblement.

Oui, le coût de la vie au Japon est élevé. C’est pourquoi il est préférable d’y travailler plutôt que d’être touriste, parce que les salaires sont en conséquence.

Surtout, je me demandais comment était l’accueil et l’intégration des étrangers s’établissant au japon. Certains reportages, combinés aux films comme «Stupeur et tremblements» (qui est, admettons-le, un peu dramatisé/comédique) et les opinions des gens autour de moi, me laissaient croire à une société fermée/repliée. Selon cet homme, il n’en est rien; il s’agit strictement du même phénomène que ce que l’on retrouve pratiquement partout dans le monde: si l’immigrant fait des efforts pour apprendre et maîtriser la langue locale, son intégration se fera avec succès alors que «les gens vont se précipiter avec joie pour vous aider», tout comme les Québécois francophones adoptent une attitude positive envers quiconque fait des efforts pour parler le Français.

Et vous? Habitez-vous au Japon ou connaissez-vous quelqu’un qui vous a fait témoignage de l’intégration des immigrants là-bas?

by nekohayo at April 05, 2013 11:08 PM

April 04, 2013

Bastien NoceraGeocluing the desktop, slowly

(Bastien Nocera) Over the past couple of months, Satabdi has been working during her Outreach Program for Women on geocode-glib, and Zeeshan more recently joined us to help with cleaning up some of the code.

As Satabdi's program is now finished (though not her involvement!), and a new GNOME development cycle has started, I'll try to explain where geocode-glib fits in, and answer some questions on the future of Geoclue.

(Reverse-)Geocoding

First and foremost, geocode-glib is a geocoding and reverse geocoding library. It uses Yahoo! web services for this, though we're investigating using Nominatim for this in the future.

This replaces the convoluted implementations for those two services in geoclue (3 if you include Address as a service). The API should be mostly stable now, and we'll soon start porting a few applications to it (Evolution and Empathy come to mind).

The library also includes a GeocodeLocation object. This will be useful later.

GeoIP

geocode-glib, thanks to Satabdi's work, includes a GeoIP server, to be installed on GNOME servers eventually, which uses data from MaxMind to  locate a user connected to the Internet from the IP address. We also have a client library to access this server.

This is usually good enough to locate a user in a city, or a country, which would help us with many integration points in GNOME, such as the upcoming Date and Time panel re-design.

But this code isn't really for you, app developers.

Geoclue

A fine project, but the codebase is showing its age (dbus-glib!), and the decision, well, not to take decisions on which backends to use for various services make it fragile. This is a maintenance problem, both for in terms of making sure all the services are kept working, and that geoclue itself is kept stable.

So we'll start a reimplementation of Geoclue. The goals are:

  • Trimmed down API, just for positioning
  • Smaller, but more integrated, selection of ways to get the positioning (GPS from your integrated WWAN modem, Wi-Fi AP data, IP address, no discrete GPS or manual location)
  • Power-saving, by aggregating requests from all the applications
  • and finally, privacy, where only applications that you allow to request your location can get it, and only with an accuracy as needed for the application.
The code currently in geocode-glib for IP geocoding will likely move there when the project has been kickstarted.

I hope this clears any misconceptions people might have about geocode-glib, or, more likely, about the future of geoclue.

by Bastien Nocera (noreply@blogger.com) at April 04, 2013 02:40 AM

April 03, 2013

Jean-François Fortin TamGStreamer Hackfest 2013: Moving Images

I’m back from this year’s GStreamer hackfest, which was fantastic as usual — an intersection of great minds, big challenges, flaky Wi-Fi and good food. Christian already did a generic summary, so I’ll be narrating from the GNonLin/GES/PiTiVi perspective. See the end of this blog post for a nice video retrospective.

2013-04-02

Edward provided an initial patch to improve the behavior of timestamps and seeking in GNonLin, while Nicolas “Stormer” Dufresne fixed two bugs causing deadlocks. Nicolas spent a lot of time discussing with Wim Taymans, Edward Hervey, Sebastian Dröge and other hackfesters about the architecture of GNonLin in light of GStreamer 1.x. He also fixed looping for the Ogg demuxer in pull mode and, with some help from Mathieu “Forest Ranger” Duponchelle, fleshed out the design for a new tree data structure for GNonLin.

Mathieu the Moustached Avenger worked on implementing keyframes in GES, paving the way for him to create a user interface to animate any effect property in PiTiVi. That user interface will most likely depend on him working on the clutter timeline canvas, so I’m looking forward to improvements in that area.

Thibault “Keyboard Crusher” Saunier finished the implementation of GES Containers and clip groups, then worked on implementing — at long last — audio mixing in GES. This is an essential feature of multitrack audio/video editing, and I’m really happy to see that feature make its comeback for the next release of PiTiVi. This work will also depend on Mathieu’s keyframes UI. A proper reimplementation of video mixing remains to be done, however.

There are lots of outstanding things to solve in GNonLin and GES. Nicolas has a bunch of ideas for things to improve and redesign in GNonLin and I expect much collaboration between Thibault and him to optimize the entire stack for better reliability and performance (for example, adding caps filters to allow realtime downscaling of videos to improve preview performance, configurable downstream buffering for playback to avoid frame drops in CPU-intensive parts of a timeline, etc.). GNonLin and GES have much potential to allow us to be a lot smarter than before.

Personally, I spent most of my time testing, discussing and hacking on some new features for PiTiVi.

    • I added a button in the timeline toolbar that toggles the “gapless mode” (automatic ripple edits), which makes your clips behave like magnets and prevents needing to re-arrange them manually all the time. The feature works and will be merged after a customary code review.
    • I made some progress on the custom effects UI branch. Once it’s complete, you will be able to easily create custom user interfaces for effects that require it, simply by using a glade/gtkbuilder .ui file (or, if you prefer, a set of widgets from your own python module). Of course, for the majority of effects, our automatically generated user interfaces are still good enough, so we can keep using them and avoid unnecessary work.

(See my previous blog post for a situation report on where we stood with PiTiVi before the hackfest)

I also spent a bit of time setting up my film making gear and shooting various interesting moments of the hackfest. Here’s my montage, which will tell the story much better than a long blog post. Hope you’ll like it:

I would like to thank Collabora for allowing many GStreamer contributors to attend the hackfest, which I consider vital to the health of the GStreamer community. I was happy to meet again with many friends and help push the Free multimedia stack forward. Props to Christian Schaller and Alessandro Decina for organizing the whole thing, too!

Aside from Collabora and Fluendo sponsoring two of our dinners (thanks!), I would also like to thank you, PiTiVi supporters, for making it possible for me to spend some money to thank GStreamer contributors with some food and beer — maximum boost to the GStreamer community! Full disclosure: I used 84 euros worth of PiTiVi donations for that purpose.

by nekohayo at April 03, 2013 04:33 PM