Swfdec, GStreamer, Cairo, GNOME, me

Dave, It’s dead simple. FFmpeg developers do not care about you – or anyone else. The only thing they care about is sitting in a cave admiring their awesomeness.

I’d suggest you go and file a bug with VXL and tell them that their ffmpeg handling is wrong (as they linked to and not forked it). While doing this, suggest to them that they might wanna use GStreamer (or Xine or whatever) instead, as those projects provide stable API and are actually more powerful.

In Swfdec I’ve seen the light and removed the ffmpeg option. They don’t care about me, so I won’t care about them.

Or to paraphrase: There’s always the ffmpeg solution to every multimedia problem — neat, plausible and wrong. Or did you pad and align your buffers?

Apparently Aaron had to answer the Why isn’t Phonon useless? question yet again. I guess when something is known for abstractionitis, it deserve that.

What I’m going to rant here though is about abstractions, that claim to be “thin layers” over something else and that makes them “good” because they can switch “backends” easily and then are “more flexible”. In case you don’t know what I’m talking about, here’s some examples: Phonon, XUL, Cairo

The biggest problem abstractions have is the lowest common denominator problem. You need a fallback mechanism if one of your backends doesn’t implement your feature. Most of the time, this fallback mechanism is not implemented, so using it ends up either being a “query capability and only use it if available” dance in applications or it just does nothing and users on weird backends (like BSD ;)) wonder why your application doesn’t work.
And even if you have a fallback mechanism, it often is very suboptimal and behaves wrong when compared to “native” output. Firefox’s awesomebar dropdown still looks totally out of place in GNOME compared to Epiphany’s and sometimes selecting text in cairo-generated PDFs is impossible, because the text was rendered using an image fallback.

Another similar problem is that you have to limit the API you design to the backends. You cannot sensibly make use of a real cool feature if most of your backends don’t support it – or you have to implement it yourself for all the backends. Depending on your choice, you either end up with unhappy users or N times as much work.
In the same vein there’s the problem with additional API burdened upon the user to properly support all backends. Cairo is going to gain the useful feature to mark text as a link or attach the riginal JPEG data to an image, so the PDF and SVG backends can include this information. However, this information is completely useless if you output to the screen.

And finally you’re writing a lot of code – mostly compatibiltiy code matching your API with the backends or fallback mechanisms for their unimplemented features. So you have to ask yourself if the “thin layer” you’re writing is really that thin or if you’d better use the underlying features directly. From my experience the answer usually is to use the underlying feature directly unless the “thin layer” adds some substantial features itself.

I just upgraded my machines to Intrepid, so I could fix Totem’s slow startup speed. And it turns out stuff works better than before. Thank you everybody – in particular Kernel, X and Ubuntu people – for making stuff work so well.

What’s scary about 5 second boot is not that it is possible. What is scary is that Ubuntu, Fedora, Debian, Mandriva, Gentoo and Suse couldn’t do it. Not even close.
And that seems to be a mindset issue: “It’s not about booting faster, it’s about booting in 5 seconds.”

So, lots of talk about sripting engines on Planet GNOME. I was first planning this as an answer to Alex’s GScript introduction, but I thought others might be interested, so here it goes:

Here’s the three things I’d care about in a GNOME scripting environment a lot:

The most important thing is of course the bindability. You need to make it incredibly simple to bind stuff to or from GObject stuff. It looks like GScript already does an awesome job at this with natively marshalling everything and so on.

Another important thing is this: Does GScript ship programming tools and provide a way to do RAD? I’m thinking console, debugger, dnd script installation etc here. Not just for people writing scripts (where I’d want completion and built-in documentation), but also for me when making my application scriptable and having to debug refcounting issues because a script holds on to a GObject that my C code thinks is gone already.

But the most important thing for scripting I think is security. I want to be able to download scripts from untrusted sources (read: the Internet) without fear of them doing anything bad to my computer or its data. This is doubly complicated if exposing stuff is too easy. So if you expose “RemoveSong” in Rhythmbox, you already have a problem.
The reason you want to allow this, is twofold: 1) We are incredibly bad at maintaining a useful set of plugins (or art – same issue for themes). That’s not due to lack of capability, but because it’s booooring. 2) If you would set up a website where everyone can upload/download/vote on scripts and even integrated that site into your application, you would make the application self-improve and lower the barrier of entry for new people incredibly.
Here’s a use example

1. I want to remove red eyes in the GIMP. So I open the plugin browser, enter “red eye” and get a list of plugins (note that none of these plugins are installed). I select the highest-rated (or most-installed one) and it launches, asking me to select the red eyes and afterwards removes it.
2. I decide I’m smart and can write code that detects the red eyes automatically, so I select the script, click on “edit” and modify the script. After half an hour (read: 2 weeks) it does what I want. I’m happy.
3. When looking through my scripts, I see the “upload” button next to my red-eye removal tool. So I click it and it’s available for everyone else.
4. Go to 1, replace “I” with “you” and “selecting the area” with “speed”, “accuracy” or whatever other feature.

This gets you the whole bazaar style software evolution without human intervention, automatically and for free. The only people I know that are doing something like this are Userscripts for Greasemonkey, but even that doesn’t look very professional.

Yesterday, when reading the Tracemonkey stuff, I realized this. The question “My code runs slow, how to make it go fast?” has two answers: “Improve the compiler/runtime to make it go fast.” and “Rewrite it in another language that can go fast.” As long as the second option is possible, there’s just no need to spend a huge amount of brain on the other option.

Besides, I’m back from my holidays where I’ve played with Flash 9 scripting in Swfdec. While it won’t make it for Swfdec 0.8, I’m positive 0.10 will play ABC-scripted Flash.

Yay, I’ll be on holidays on Madeira for the next 3 weeks. So if I don’t answer to email, now you know why. (I didn’t break the GNOME build on pourpose, I swear!)

To not leave you without code to break, I did releases of Swfdec: 0.6.8 (stable) and 0.7.4 (unstable) with corresponding swfdec-mozilla and swfdec-gnome releases.

Last but not least, I also uploaded the slides for the talk I gave at LugRadio Live and GUADEC. Of course it’s a Flash file. Navigate using space, left and right arrow. Mouse click (un)fullscreens. Flash is a pretty great presentation creation framework, especially because everybody can just watch the presentation in the browser the same way I did it.

It’s sad when all we have to offer to sexually frustrated people is hate and social exclusion. I’ve started to wonder if the bad reputation of Open Source communities is more related to their unsympathetic behavior than to their photos.

I’m looking for accomodation at LugRadio Live, for 3 nights: arriving on Friday leaving on Monday. So if that sounds interesting to you, and you’re not scared of sharing a room with people that know too much about Flash, get in contact.

Also, it seemed that noone had yet set up a page for arrival times for GUADEC, like last year. So I did it. Please add yourself here.

I finally made it! Swfdec 0.7.2 is out in the wild. And now I don’t know what to blog about, because I haven’t used the stable series for such a long time that I don’t even know what the coolest new features are. I had to read the git log for half an hour to remind myself of what we’ve done in the last 3 months.

The coolest thing for me about Swfdec development was when Youtube released their new player and it just worked. But it also works in the stable release, so for end users that’s boring. What I also found cool was the time we invested into our (de)compilation framework that gets used internally to make Flash files easier to debug. We spent a lot of time on it and now have a vivi-rewrite tool, that can do all sorts of interesting things to Flash files (like remove randomness). And again, it’s a feature that I think is very cool, but it’s absolutely uninteresting for end users.

But there are some user-visible features. Swfdec does fullscreen properly now. That’s good for 3 things. First, it’s awesome to watch videos in fullscreen. When hey are fast enough. That’s the second thing: It’s easy to figure out if your X driver setup has Xrender properly accelerated. Because if you have a stuttering video, it isn’t. And last but not least I hope that these weird guys want to watch videos in fullscreen and therefore accelerate render properly.

We’ve also been working together with Mozilla and Gtk Webkit. So Swfdec is the only plugin on Linux now that is translucent and obeys stacking order.

So now, you can all stop asking what’s happening with Swfdec. We’re well on our way to our next stable release in September.