Present Perfect

Tim pointed me to a bug report about GStreamer. I couldn't resist from commenting on a comment that questioned my mental capacity :)

(In reply to comment #4)
> I still wonder who invented such ugly naming scheme for gstreamer plugins?

I don't think you wondered really hard because it's not that hard to find who
did. It was me.

> Who
> is this completely braindamaged guy, who combines all plugins into several
> packs, which names says nothing about their actual content.

If memory serves, the same guy that you met in person some years ago.

> I still hope, that sometimes there will be a great developer, who will split
> these good/bad/ugly/etc packages into something more suitable for end-users.

And I still hope that some people will not assume everyone else is stupid just
because they're talking on the internet.

Whether or not the GStreamer plugin-split and its naming was a good idea is obviously debatable. I still think that we did the right thing there, and he could have read the explanation.

But regardless, people, seem to think that because it's the Internet, common courtesy isn't necessary. Especially in our communities, people can get abrasive online where they wouldn't be in real life because they have a real person in front of them.

Often, these people emulate people like Linus Torvalds, who is known to have a certain abrasiveness. Linus gets away with it because he's made undeniable and genius contributions to the community. The problem are the disciples, taking him as an example, confusing correlation with causality, and copying his abrasive style thinking it will lead to genius.

I'm extrapolating this particular bug report here - I can't or won't comment on his contributions, which are many as well. I know about a lot of them, since he interviewed here for a job a year ago. I'm mentioning this to make sure you know that the Internet is not always as anonymous or isolated as you think it is. You can't delete stuff from the net, and people will evaluate you by your online presence, for better or worse.

And if the person commenting is really interested in the plugin split, feel free to talk to me, but let's keep the chatter out of the bug report.

Now excuse me, I'm late for my CAT scan. Better safe than sorry!

UPDATE: someone commented that I breached etiquette; so I removed some details like the bug report and a part of the comment. I should have thought it through, I had no idea what I did was considered as such. My excuses.

Tim pointed me to a bug report about GStreamer. I couldn't resist from commenting on a comment that questioned my mental capacity :) (In reply to comment #4) > I...

Linked from the blog of the always excellent Harald Welte is this LIMO paper on the economic value of merging back changes to an open source project.

Quoting from there:

Currently, GStreamer comprises some 911,000 SLOC. Using our $50/SLOC factor, this equates
to an equivalent engineering cost of $45.5 million to develop this technology from scratch.

HFSNW! Surely at least $100K of that is my work. Where is my money?

Linked from the blog of the always excellent Harald Welte is this LIMO paper on the economic value of merging back changes to an open source project. Quoting from there:...

After a visit from the unicode police I'm gearing up for a first morituri release.

If you're on F-11, you can just install my repository and then install the latest snapshot with
yum -y install morituri

After that, pop in a relatively well-known CD, then type:

rip offset find

Hopefully, it will be able to tell you the read offset of your CD drive.

Then do

rip cd rip --offset (the number from above)

and it should proceed to look up the CD on MusicBrainz, rip and verify the tracks to flac, and then do an AccurateRip verification.

Let me know if that works out for you. And if you're not on Fedora 11, you can always check out the source code directly, it's not much harder to get running.

After a visit from the unicode police I'm gearing up for a first morituri release. If you're on F-11, you can just install my repository and then install the latest...

Today I finally had a reason to be happy about GStreamer having switched to GIT.

I added actual encoding support to my CD ripper this weekend. I'm only supporting lossless encoding for now. Sadly, in practice it seems the FFMpeg ALAC encoder crashes, and the wavpack one hangs for me, so I'm left with .wav (meaning no compression) or .flac

And then today I realized that some of my encoded .flac files had a strange bug in them. I wasn't sure where it was coming from, but some of my encoded files didn't play with mplayer, gave an error when using flac -d, but still worked completely fine with GStreamer and totem.

I first tried to find a different file from the GStreamer media testsuite to reproduce the symptom. south.mp3 and benow.mp3 owrked fine, but sugar.ogg reproduced the problem.

I also tried it with my installed version (0.10.8, while git master is at 0.10.15.1) and that worked fine.

So that gave me two points to bisect inbetween.

Then I read up on git bisect, and started playing with it. It isn't particularly nice to do by hand; most checkouts change enough of the autotools files that it has to rerun them most of the times. Then configure changes win32/common/config.h which generates a local change. The common submodule also gets in the way. I got away with just compiling the flac plugin with make -C ext/flac before each test, so that sped up things. But there's definitely potential for human error.

Basically, you start by doing git bisect start; git bisect bad; git checkout (known good commit); git bisect good

This will leave you somewhere in the middle between the bad and the good commit. Rebuild, do your test, then either type git bisect bad or git bisect good based on the test result. Repeat until you're at the last commit.

That helped me find where the bug happened (see the bug report).

Of course I wondered immediately if I could automize this, since I wanted to make sure that the same commit broke my original files and I do not want to do that manual bisection again...

It turns out you can; that's what git bisect run is for.

So, given the following two shell scripts:

test.sh

#!/bin/bash

git submodule update

make -C ext/flac

# rebuilds can touch these files leaving you with local changes
git checkout win32/common/config.h

gst-launch -v filesrc location=/home/thomas/gst/media/medium/sugar.ogg ! oggdemux ! vorbisdec ! audioconvert ! audio/x-raw-int,width=16,depth=16 ! flacenc ! filesink location=test.flac
flac -d test.flac -f
# flac -d exits with 1 when it fails
exit $?

and bisect.sh:

#!/bin/bash

git bisect start
git bisect bad
# 0.10.8 release
git checkout c186d67f40827be349f97d810a45243c874b73f7
git bisect good
git bisect run ./test.sh

I can now just run ./bisect.sh and it will do the whole process automatically.

Try it if you're curious on a checkout of gst-plugins-good. Change test.sh to point to your sugar.ogg file (which you can get from GStreamer's test repository).

At the end, the output should show something like:
df707c666433a78d3878af6f055698d5756226c4 is first bad commit
commit df707c666433a78d3878af6f055698d5756226c4
Author: (HIDDEN TO PROTECT THE GUILTY)

The 'run' command really is what makes the bisection useful for me. Now, back to bug fixing....

Today I finally had a reason to be happy about GStreamer having switched to GIT. I added actual encoding support to my CD ripper this weekend. I'm only supporting lossless...

While working on morituri I provided some patches to pycdio, the python bindings for libcdio, to handle CD-Text. I was assuming it was the only library or program capable of reading it (turns out I was wrong, cdrdao also extracts it). But those functions weren't wrapped, so I added them. Upstream was using git, so that was another opportunity to test my git workflow across my 3 computers.

Anyway, it was nice to get feedback that said:

Your code has been checked into pycdio. Looks very competently done and is very thorough. Thanks.

For various reasons I won't get into I don't always enjoy the results of coding contributions at work to Flumotion, the project I started. And just as much in the open source world, my contributions aren't necessarily always valued, or treated with the respect I would think they deserve :)

That usually isn't that big of a deal to me, because that's not why I do it, but getting this succint positive remark reminds me that being nice invites being nice. Something I need to remind myself of once in a while to make sure I try and act the same way.

Anyways, a roundabout way of saying I can add another project to my list of projects I've touched.

Meanwhile, on my last plane trip I took the time to autotool morituri. I've finally caved in and went with the familiar, adding a simple frontend command using my python Command class
Another tree is born. Here's the first command's output:
[morituri-trunk] [gst-git] [thomas@ana trunk]$ rip offset find
Trying read offset 0 ...
Trying read offset 6 ...
Trying read offset 12 ...
Trying read offset 48 ...
Offset of device is likely 48, confirming ...

Read offset of device is: 48.

Now, on to ripping and drive selection and TOC caching and such niceties. Someday soon I should be able to actually use this...

While working on morituri I provided some patches to pycdio, the python bindings for libcdio, to handle CD-Text. I was assuming it was the only library or program capable of...