[lang]

Present Perfect

Personal
Projects
Packages
Patches
Presents
Linux

Picture Gallery
Present Perfect

elisa and lirc hacking

Filed under: Dave/Dina,Fluendo,Hacking — Thomas @ 00:21

2007-02-20
00:21

So, after waiting for months and months on a DirectFB backend for Elisa so I could use my home Dave/Dina machine with it (It has a venerable Matrox G550 which is the best type of card to use with DirectFB), I caved in last week and joined the dark side by buying an NVidia GeForce FX 5200 card and using the binary-only drivers. It took some tweaking and digging, but I managed to get the card a) output with TV/out, b) look good enough to be comparable to the Matrox video output, and c) avoid any tearing effects by enabling all the VSYNC options the tools provided me.

Loic recommended a higher-numbered card, but all cards in the series he recommended have fans, except for one particular model that you have to mail-order from Asia. I want as few fans as possible in my media box.

I hate saying this, but the NVidia configuration tools actually work pretty damn well once you get the hang of it. Most changes are done on the fly (without restarting X), which is a welcome change from the usual hackery. And when I read the README for these drivers and look at the huge amounts of tweaking you can do with these cards (genlocking 4 cards together ? Are they serious ? Is there any open driver out there that can come close to offering something like this ?) I have some amount of respect for the NVidia Linux engineers. I hope the nouveau guys are going to hang in there and deliver on their mission goals, because they have a lot of work cut out for them.

I'm not advocating closed drivers at all, but for the time being I have decided to be practical about this and start hacking on Elisa and actually use it at home, and the NVidia card I got achieves that for now. I could get an LCD TV to avoid having to mess with TV/out, but I feel that there is still a large group of users that want to use something like Elisa with their existing analog TV.

Ironically enough Julien started hacking on a DirectFB renderer for Elisa a few days after I got the NVidia card :)

After that, I upgraded my base distro from FC4 i386 to FC6 x86_64. Again I reacquainted myself with the painful process of getting LIRC to work. Every time I put some serious effort into getting the media box up to date, I am forced to deal with LIRC, and every time I wonder why this has to be so painful. Here are some of the things about lirc that bother me to no end since I started using it five years ago:

  • Why is this stuff not in the kernel ?
  • Why is it so incredibly hard to set up ?
  • Why do all the configuration files for remotes use different namings for the same keys ? This should be a matter of policy dictated by the project. Why does one config file use "FastForward", another "FWD", and yet another ">>|" to mean the same thing, forcing someone to change the configuration of LIRC to work with their applications when they change the remote they use ?
  • Why is there only a terrible command-line application to "train" for your remote ? Elisa should be able to make a simple graphical remote trainer application that helps you set this up from scratch in a user-friendly way.
  • The worst part for me is the fact that this iMon device being used on my Silverstone media box comes with this dinky remote that has some sort of jogwheel that is able to simulate a mouse. Except the driver in lirc ignores that completely, so where every other remote has at the very least UP/DOWN/LEFT/RIGHT as part of the things it can generate, this one can't. And then you get this forum where some guy put an original patch to make the jog wheel be able to generate up/down/left/right, and then you have a bunch of people modifying this patch, customizing, ripping out bits that fail to compile with later kernels, ... But this stuff never gets upstream
  • A year ago I took one of those patches and fixed the kernel module to be a lot more consistent about the events it generates. The kernel driver actually receives fine-grained x/y coordinates from the jog wheel, and then synthesizes the four directions from this. It was doing so with a pretty bad algorithm, making it really hard to consistently go in a given direction. I had a patch for that. Except it needed updating for the newer 2.6.19 kernel, and apparently some things have changed in the input device layer. Sometimes I don't understand why it's ok for something as basic as the kernel to change their internal API all the time, while something like GStreamer, and pretty much everything in the GNOME stack, is forced to be held up to such high API standards
  • .

    Anyway, after all the hardware hacking and distro updating, I have an elisa running at home, with the remote working, and able to show me Veronica Mars, Heroes and Battlestar Galactica.

    Next tasks: push Fedora Extras packages, look at why subtitle rendering is so slow that a 2GHz Athlon64 cannot play the video fast enough from within Elisa, and taking a look at the music parts.

Cortado 0.2.0 “Broken Record” released

Filed under: Fluendo,Hacking,Releases — Thomas @ 15:17

2006-05-19
15:17

I've got soul
but I'm not a soldier

A movie paints a thousand stills, so first of all ...

If you didn't see a hairy movie, there are two possibilities. Either your aggregator strips embed tags, in which case go here to see it. Otherwise, you are probably missing a Java plug-in for your browser.

this video was made from photos during Kristien's stay in China.
Thanks to Jan Schmidt for the idea and the hard work.

Cortado is an implementation of the GStreamer 0.10 design, but completely in Java. It has plug-ins for Ogg, Vorbis, Theora, Mulaw, JPEG, Multipart, HTTP and Audio and Video sinks. It can be used to play live streams and on-demand streams. On-demand streams can be seeked in (as you should be able to test in the applet above).

Cortado is completely free and an open project. We welcome other people trying it out and hacking on it. Several sites are already using it in production today. In short, if you want to producer or serve video, all the tools are available to do so in free formats.

For more information about this release, check out the release notes or go to the Cortado home page.

Christmas presents

Filed under: Fluendo — Thomas @ 16:05

2005-12-24
16:05

Last year we gave away our Cortado Java applet. This year, it's a legal zero-cost mp3 decoder plug-in. You can download it from our new webshop.

What does this mean in practice ? (I am not a lawyer. Check with your army of lawyers. For all we know I may be making shit up).

For end users, they can download our binaries from the shop, and use them to legally play back mp3 files on Linux. Our agreement with Fraunhofer allows this - our patent license we negotiated applies to the product defined as "Fluendo mp3 GStreamer plug-in". Currently, we have i386 and x86_64 Linux builds, and ppc and other platforms will probably follow as soon as one of us gets round to it. If you have an Intel-compatible CPU, we also provide a binary that is built with Intel's optimisation library, which also makes it really fast.

For developers, our source code is available under the MIT. You are free to tinker with it and change it. Normally it is legal for you to run a binary built with your modifications - as long as you are not distributing the binaries you build. The patent license from Fluendo only applies to the binaries we built for you; but it seems Fraunhofer considers building binaries for personal use or research purposes fine.

If you want to get your changes distributed, you simply send us patches, we incorporate it in the source tree, and we build new binaries for the next release. Make no mistake - this is an open source project. Every piece of MIT code out there does not necessarily grant you the right to distribute binaries freely. It is the responsability of the user to make sure he is allowed to run the binary, as far as I can tell.

For distributors, we have a contract available that they can sign with us at zero cost that allows them to also rebuild the source into a binary for which our patent license can be used. Basically, it means that they have the right to build the aforementioned product to which our patent license applies.
Whether distributors want to sign this contract remains to be seen of course - obviously there are strings attached because we need to satisfy our agreement with Fraunhofer. But it does mean that Red Hat Enterprise Linux, Novell Linux Desktop or Linspire could bundle this plug-in with their OS, and we hope some of the Free distributions will consider shipping it as well.

Why are we doing this ? Quite simple. mp3 is a very widespread format, and the fact that Linux could not legally play it out of the box in countries where patents apply is posing a lot of problems for adoption. It is one of the most commonly heard complaints about distros these days. Fluendo still fully supports open formats, and we hope people move to using them. Part of that move is being able to play your legacy formats, where you have no choice over the format. Remember, we are not giving away a free encoder.

Why is this different from before ? Lots of reasons. The current open-source decoders for mp3 are all GPL.
Section 7 of the GPL states, among other things: For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

To me this seems like very clear language, though others (most notably, debian-legal) disagree. To me it reads that if I live in a country where patents apply, and I am able to download GPL mad source code, which I am not allowed to distribute further (because I lack a patent license), it means that either a) the author of mad is not allowed to distribute his GPL source code at all or b) the author is not allowed to distribute his source under the GPL at all.

One of the ways to make money off Free Software and Open Source is to offer your code under a different license for a fee. This is something Fluendo does with Flumotion, and this is also what the mad author does. So it's possible the mad author has chosen the GPL for this reason - it makes sense to do so.

In any case, the MIT license avoids any language about patents. One possible reason for other projects not having chosen this license is because it also does not require you to contribute modifications back. So in some sense, we do incur the risk of people "stealing" the code and modifications we made. But that's fine for us - the advantages outweigh the disadvantages.

The practical difference may not matter to you as an end user. You may be living in a country where patents do not apply, have gotten a copy of the mad source code, and be running a plug-in linked against it, and it's not your concern whether it was legal for someone else to distribute this. Or, you think that the patents that are claimed to apply to mp3 are not valid, and thus you do not need to have a patent license. Or, you ignore patents altogether, and just install a plugin to play mp3, no matter which it is. So you could say, big deal, why should I care ?

Maybe you shouldn't. It's just that as far as we can tell, this is the first time you can install mp3 decoding on your Linux box, legally everywhere - without question - yet still see the source code to it and contribute to the community around it. We think this is as good as it can get within the limits of our agreement with Fraunhofer. If you care about the legality, or you are forced to care because you deal with installations for companies, schools or govermnents, this makes all the difference.

There's been some interesting discussion as a result of this, and I still haven't figured out what I want to see happen in the end. For example, in the case of Fedora, I am not sure I actually want this plug-in shipped by default. I think in the end I would prefer a distro like Fedora to openly and actively support open formats, and make the choice to not ship this mp3 plug-in on principle. Before, the reason was that there was no legal way to do so. I am happy that our plug-in gives distributions something to consider, and might bring each of them to clarify their point of view.

So, are there any drawbacks. Yes. To make a long discussion short (and you should reread the LGPL and GPL if you care about this, and possibly GStreamer's licensing advisory), our understanding is that a distributor cannot distribute the combination of:

  1. the LGPL GStreamer framework
  2. a binary plug-in that is not GPL-compatible in license (such as ours)
  3. a GPL application linked against GStreamer

because at runtime, the first becomes GPL, all three run in the same memory space, and the GPL does not allow linking to GPL-incompatible code. (Remember - the GPL is a license that covers distribution, imposing some restrictions based on what could happen at runtime) Shipping any two out of these three is fine, as a distributor. Running all three together is fine as well, as a user - if at least one of these three was distributed to you through someone else than the original distributor. (Is your brain hurting yet ?)

Applications can choose to add a simple exception clause (or possibly, it's even a "this is how I interpret the GPL" clause, I'm not sure) to their GPL license, allowing for proprietary GStreamer plug-ins to be used with their application. Totem has done this. Sound-juicer is going to add this, I've been told. We've discussed it with RhythmBox developers as well at some point, though I don't know if that got decided upon.

Personally, I think every application writer should decide on this for themselves - and if they make an informed decision to not allow proprietary plug-ins, I think that's a brave decision to make and I support them, because it sends a clear message. People should realize what their choice of license means.

The other drawback is that our code is probably not yet of the same end quality as mad's. The mad author invested a lot of time and resources into his decoding quality. This plug-in was written by Jan based on the reference code, and massaged into a nice typical GStreamer project, gotten some optimization done in the DCT and other places, and received some hooks into Intel's IPP libraries for speed. But there's still lots left to do, and we hope to build a community around it. Most notably, we hope someone takes on the challenge of using liboil to speed up the reference implementation.

if you see this man
thank him for legal free mp3 decoding
then inform the authorities
he was last spotted in Brugge, Belgium

In any case, I look forward to what will happen, and I hope it can make a difference. In the end what it boils down to is that we are offering you more possibilities: the possibility of legally playing back mp3 content, the possibility to distribute mp3 playback capability legally, the possibility to hack on an open-source project and legally use the result of your contributions.

Merry Christmas to you all from Fluendo.

foo

Filed under: Fluendo,GStreamer — Thomas @ 11:09

2005-04-08
11:09

and the talking leads to touching
and the touching leads to sex
and then there is no mystery left

Alunya

So, Kristien went to get the cat yesterday. He's about five weeks old, has grey-whitish stripes and a few cute gingery spots on the top of his head. He's more active than we expected - in one night he's eaten three times already (out of the zero times projected by the woman handing over the cat) and he was already sleeping happily on our belly while people were being shot on TV in the Sopranos. Pictures up soon.

How not to do it
Yesterday some guy came into the #gstreamer channel. This was the start of the discussion:

<NickWithheldToProtectTheInnocent> I'm almost finished reading the documentation,
and I must say that the terminology of gstreamer is very lousy, much better metaphor names
could be used that would map to better real world object. Like the ones used in home theater
example. Don't you guys think so ?
<thomasvs> NickWithheldToProtectTheInnocent: no, I don't think so.
<thomasvs> NickWithheldToProtectTheInnocent: but feel free to write some documentation
that uses home theater terminology.
<NickWithheldToProtectTheInnocent> how does "bin" and "sink" make sense to you
without reading the documentation.
<thomasvs> NickWithheldToProtectTheInnocent: how do you pee cleanly without
your daddy telling you ?
<thomasvs> NickWithheldToProtectTheInnocent: how do you learn that it's not
acceptable to poo in public ?

Now, suppose you're having an open house day, and someone walks in, walks over to the group of people standing in your living room talking to each other, and then says loud enough for everyone to hear "This room is very ugly, it could look a lot better. And who puts a fishtank in the living room when everyone can see a pool table would be a much better fit for this room ?"

It's one thing to deliberately start off on the wrong foot with people you don't know at all. If you do, you'd better have a personality that can make up for it. Now later on, this guy goes on to say that he would use "metaphors that could map to real world objects, that would ease the learning process obviously. Like signals and slots of Qt. something that you can connect other thing to."

Now, I had before not taken a look at exactly what slots were in Qt, but I always wondered what they would be, since the only real-world image I had of slots was "some opening you can slide a wide and thin object into". Like, a slot machine, or a letterbox. So he starts off by saying that our terminology is not real-world enough (though to me, a bin is something you put stuff in, and a sink is something in which a stream disappears - I have one of those in my kitchen and bathroom), but a slot is fine.

It might be possible that Vegas has slot machines connected to the ground somehow to prevent from getting stolen, but in the end, a slot being basically the absence of something in something else makes it really hard to *connect* something to it.(1)

Anyway, if you're new to a project:
- be nice when you get in
- if you're not nice, but think you have a valid point, defend your point when people question it
- make sure you use a valid example to make your point. be prepared to back up if you chose an invalid example
- don't call one of the project people "stereotypical" when they challenge your point's validity. It's very stereotypical.
- don't tell them to stop wasting your time. you just came in and wasted theirs *without* having a history of good will on your side.
- don't expect to not have to read *any* documentation. Saying that "bin" and "element" should mean something to you without reading any docs is just dumb. How do you know that these concepts exist in first place ?

On a related note, I hope the cat will learn about the acceptability of pooing in public.

kernel

I got fed up about the fact that both our FC3 kernels and matthias's production kernels cause a kernel fault every time you start or stop capturing from firewire, and sometimes they even lock up hard. It keeps us from hacking on nice Flumotion bits related to Firewire. So I decided it was time for me to do the hard work and start kernel debugging. Boy, what a world of pain :)

I managed to get a serial cable linked up between the test box (which sadly is also our firewall and svn repository) and the workstation. After some tweaking, kernels started spewing all sorts of info to my other machine. But apparently firewire dies without an oops or anything. The machine just locks up and that's it.

So I started hunting for info, similarities in bug reports, kernel patches, ... I also managed to rebuild Fedora Core kernels with my own patches in a fairly sane way, but it's still painful. Yesterday night I tweaked the config a little to give me more debug info, and this morning I will bother my co-workers again with on-off internet. So if you see us go under ...

(1) This is no attack on Qt. It's a fine framework afaict. The guy gave "slot" as an example, and it just happens to be a Qt thing.

when the loneliness leads to bad dreams
and the bad dreams lead me to calling you
and I call you and say "COME HERE"

Flumotion hacking

Filed under: Fluendo,Hacking — Thomas @ 21:10

2005-04-01
21:10

Progressing at a steady pace. At PyCon I fixed all problems between our Flumotion tree and the newly released Twisted 2.0 (yay guys !). Not too much work actually.

A customer ran into some issues with a bouncer not expiring connections properly. Since we don't actually have a bouncer that expires clients in the basic version, I proceeded to write a simple component view for bouncers allowing me to expire any keycard issued. That uncovered some subtle bugs in various places, which allowed me to increase the code coverage a little (It now reports 68% covered, but it's not entirely fair - we're currently not regression-testing actual components because we haven't figured out a nice way yet to test them separately from the whole process architecture).

So it's 68% against about 6000 lines of code, and the whole tree is now at 16.000 lines according to sloccount. So it seems to be worth about $500.000. Check please.

Today I was trying to figure out some nasty reload() bug with our nasty bundling code we have while integrating a patch from Zaheer. Sometimes hacking Python can still be pretty frustrating. Anyway, deferred until Monday.

I have switched to using KDE so you will see my blog on Planet KDE from now on. Really, having your desktop in C and not in C++ and thus being faster to compile really doesn't matter one iota when you're using packages anyway.

« Previous PageNext Page »
picture