Older blog entries for zeenix (starting at number 155)

New Job

From the start of 2008, I've been promoted to the role of Lead Developer/Architect in a new team (same organisation, same company). Although I need to prove myself before this appointment is made permanent, I am hoping I'll make it through.

Syndicated 2008-01-13 22:29:00 (Updated 2008-01-13 22:30:58) from zeenix

Divide and Conquer

As some of you might have noticed, I've started to divide each one of my blog entries into multiple logical entries. This is to allow the readers of my blog to be able to filter my blog better. For example, some reader might be interesting in my opinion on UPnP but not on the death of Benazir Bhutto.

Syndicated 2008-01-13 22:28:00 (Updated 2008-01-13 22:29:05) from zeenix

Regarding Jeff Waugh

Only wanted to apologise for *unconsciously* creating the impression that I agree with all the points mentioned by Murray Cumming against Jeff. That is not the case and I only agree to what I myself also observed based on my own experience that I described in my blog.

Syndicated 2007-12-11 22:16:00 (Updated 2007-12-11 22:26:19) from zeenix

GUPnP AV CP

They say, a picture is worth a thousand words, so here is the gupnp-av-cp playing a song from my n81 on the coherence media renderer:




Many thanks to Frank Scholz and Visa Smolander for helping me in making sense out of UPnP specs, otherwise I still would have been confused on how to implement them. The CP is not yet ready but I will try to complete it before the end of the year 2007.

I would like to avail this opportunity to make it very clear to everyone that I have nothing against Coherence project and/or python, in fact I have been using Coherence myself extensively to test my GUPnP code. The reason people get the impression that I am against coherence/python is that I express the following reservations of mine regarding python, quite often and I end-up giving a wrong impression:

1. I do not believe that python is ready for embedded systems yet and vice versa. Both python and embedded systems need some time before they can be happily married.

2. There is also the fact that when I would write (or support) a framework, I would like that to be equally attractive for all kinds of developers and the best way to do that would be to write it in C. That way, once I have the framework ready, I can provide wrappers for all kinds of languages, including python. OTOH, when writing an application, I might want to do it in python myself (assuming that I don't expect it to be used on embedded systems).

On a side-note, I have been talking about UPnP so much that Ansku recently had a dream in which someone was talking to her about it. :)

Syndicated 2007-12-11 22:06:00 (Updated 2007-12-11 22:27:49) from zeenix

Thanks to dobey as well

Just writing this blog entry to make my gratitude to dobey for putting my hackergotchie on planet.gnome.org, very public. :)

Syndicated 2007-11-26 22:50:00 (Updated 2007-11-26 22:56:34) from zeenix

Thanks Murray

I couldn't have said it better. What made me really pissed is his lying tactics. I once mentioned on the gnome foundation ml about me waiting for his replies for more than an year (literally) and I got a quick reply from him telling me that he has sent me replies. I believed him (after all he is the director of gnome foundation), assuming that his mails must have ended up in spam folder for some reason but all of a sudden my spam filter started see his mails as not spam. After a little conversation, he promised to put my hackergotchie on the planet and after that I started to receive complete silence from him again. I send him reminders from time to time but I never got any response (it's been 2.5 months now). I am sure, he'll tell me that he has been sending me responses if he reads this blog entry or if I make it an issue on the gnome foundation ml again but I see no reason to believe his word anymore.

P.S. If the 'reply-to' header of an email only contains the addresses of the receivers only, I won't blame my spam filter to treat the email as spam. :) I notified Jeff about this and this was his reply:

>>P.S can you please set the correct reply-to header in your emails.

My client does what it's told to do.

Syndicated 2007-11-26 20:45:00 (Updated 2007-11-26 21:30:51) from zeenix

In search for Bertrand Russell

In search for Bertrand Russell on video.google.com, I found two video clips that I wouldn't have expected, one is a clip from an old bollywood movie where the hero is given an opportunity to conduct an interview with Russell and another is video of the song 'Jihad' by Singing Fools. The former is a bit surprising but I didn't quite catch the jihad song and it's connection with Russell. Also
I knew that americans were supporting Jihad in the 80's but didn't know they were so loude and active in that.

Syndicated 2007-11-23 13:52:00 (Updated 2007-11-23 13:53:46) from zeenix

clutter-gst

After I was informed about the existence of ClutterGstVideoSink, I quickly modified my super-video application to make it use that. But as soon as i did that, i stopped getting even the static image. After careful analysis for days, I figured that I was supposed to call gst_bus_add_signal_watch() on the pipeline bus since ClutterGstVideoSink uses messages on the bus combined with signal handlers to render the frames in the application thread. This is obviously a 'dirty' hack; a hack because gst elements are supposed to do all the media processing in the pipeline thread, dirty because gst bus is not meant for media transport.

After this realization, I had been working on it from time to time. First I tried to make the actual rendering happen in the gst pipeline thread by using the clutter's thread safety primitives and that worked quite nicely in the end except for one minor problem: The call to clutters rendering thread blocks if it happens after the clutter main loop has been exited and that is exactly when you set the pipeline to NULL state. If anyone have any clue on how to solve this problem, do let me know. In the meanwhile, I have made the hack non-dirty (or should I say, less dirty) by replacing 1. pipeline bus usage with an internal async queue and 2. bus signal handlers with idle functions (read g_idle_add()). This one was way easier to implement and it worked without any problems with all the test applications I have. I've submitted the patches upstream via a bug. If you are interested, please try them out and report your observations to the bug.

UPDATE: Just tried the 'rendering in the pipeline thread' changes again and now I remember that there is another critical problem with that: the whole application hangs (both app and gst pipeline) when I seek and/or play and pause very quickly. :(

Syndicated 2007-11-23 13:50:00 (Updated 2007-11-23 16:52:33) from zeenix

Playing video on ClutterTexture

I thought this would be an easy task and should be doable in a weekend but seems I wasn't completely correct in my assumption. What I did was to try to modify the super-oh example application to make it render frames from videotestsrc element of gstreamer, instead of the OH logo (no offense OH guys). For some reason the animation stops after I render the first frame. All I get is a static image like this:



My hunch is that I am just missing something small here so if anyone have a clue, please let me know. Here is the source.

I know that using fakesink's handoff signal isn't the recommended way to do this but I'll concider writing a cluttersink after I get this simple app. working.


UPDATE: I've been informed about the existance of ClutterGstVideoTexture and ClutterGstVideoSink by Emmanuele and Ross. Looking at the sources, I think I'll need to hack on it to support YUV (if it's available). That shouldn't be a problem but I would also want to try to implement this trick to bring hope to poor ATI grahics card users like me.

Syndicated 2007-11-12 10:17:00 (Updated 2007-11-12 14:04:19) from zeenix

From 28M to 2.7M

As some of you already know, I've been working on a simple AV-specific control-point as part of gupnp-tools. While at it, I've been trying to keep the UPnP AV parts as separate and generic as possible so that they could be move to a separate library later on. One of the first things that everyone wanted to create a nice wrapper for is the ugly DIDL-Lite. Jorn tried his best to convince me and others to not create a GObject for representing each DIDL-Lite object but I didn't listen and ended-up writing a very resource hungry API. To see what i mean, please look at memory usage of gupnp-av-cp after populating it's treeview with the content hierarchy exported by coherence:



I was quite sure that most of this 28M is taken by xmlDoc and I was right. Now that I have got rid of xmlDoc usage and replaced the gobjects with an API to deal with xmlNodes, here is how the memory usage looks like:




For people who are curious on how this simple AV control-point would look like, here is a screenshot:



One reason why the development of GUPnP might seem much slower compared to that of other UPnP projects out there is that we (especially Jorn) are trying our best to provide a nice and simple API while making sure that no part of the project is resource hungry as we are targeting embedded systems where saving bytes is more impotant than providing lots of features. Jorn already have a plan and some half-baked code for the handling of DIDL-Lite xml and contents on the server-side (ContentDirectory implementation) without wasting lots of memory and CPU.

Syndicated 2007-10-28 22:51:00 (Updated 2007-10-28 23:10:47) from zeenix