Skip navigation

Monthly Archives: September 2008

Part of my allergic reaction to Asiegos post was an undertone which perhaps was not intended-when you state the x was the y of it’s day, you are saying that it’s days are numbered-ie. something else is going to replace it. Although I am not averse in the slightest to some new media framework competing with Gstreamer I just do not see any on the horizon. Helix has not gotten any uptake from the larger community. Xine and friends(ffmpeg, mplayer/mencoder, faac/faad etc.) have proven to be too legally “iffy”  for the commercial corporations spawning around FOSS projects and for commercial corporations which distribute Linux.

The whole legal/corporate politics of this stuff makes everything so damned complicated. All of these headaches because of mp3 royalties, decss, DVD menu navigation patents, h.264 patents etc. Even Helix is in the same boat. If their were no commerical interests in Linux we would all be using Xine and friends. Unfortunately the companies, in the FOSS community,  which hark the most on questions of patents and royalties are the same ones positioned to profit from the sale of such encumbered IP.  They of course are not the cause of the problem, but that they profit from this problems existence just leaves a bad taste in one’s mouth. From my POV I have payed the Frauenhofer Institute and the corporations behind MPEG-LA/MPEG2/CSS etc. over and over again-each time I purchase a device which can play this content the people who created these algorithms have gotten money from me-I fail to see why I must keep paying more and more money to more and more companies to get the right to play back the stuff which I already have bought. I know the legal reasoning but my gut tells me this is just plain wrong. And of course this all conspires to prevent people from freely(both in the sense of code and monetarily)  accessing the media of the world-which they are already paying for-  without paying even more money to corporations to do so legally.

From this perspective I cannot see any other FOSS media frameworks displacing Gstreamer in the foreseeable future. Any future attempts to develop such will end up facing the same BULLSHIT ISSUES again. Gstreamer is not perfect but it is the *only* solution which has proven viable in the FOSS world-ie. that the community embraces, and which is *squeaky clean* enough to enable commercial corporations to invest in it. And although I do have a bitter taste in my mouth about the damned patents and royalties I do not see Gstreamer as being merely the commercial interest of Fluendo(which is selling these codecs) and Collabra-maybe mistakenly, I see Gstreamer as a genuine grass-roots community-based  multimedia framework which has grown in size and capability to enable corporations to offer services and commercial applications based on it.

Advertisements

Guys I found this in one of the comments to Asiego’s blog: http://lwn.net/Articles/183462/

It is from someone named Michael Pyne. And it is the first piece I have read about the Gstreamer vs. Photon issue which is not FUD and appears not to be based on misinformation. According to this text the *real* issue is binary compatibility-ie. that Gstreamer cannot and will not provide the ABI stability that KDE4 needs for the length of KDE4 lifespan, and not through any fault of their own.

According to this text the binary compatibility is the key issue here: in his own words:

“This isn’t to blame the gstreamer developers: Both gstreamer upgrades were a definite change for the better. But the problem is that they were still a definite change. We won’t be able to keep the Qt/KDE gstreamer bindings up to date, not to mention binary compatible, without limiting the scope of the API that we wrap. In fact, Phonon is about the extent of the amount of wrapping we’d be able to do.”

It seems to me that phonon is an extremely thin layer which wraps an abosolute minimum which is equally supported by all backends (directshow, quicktime, gstreamer, xine). It is a convenience API for QT/KDE app developers who do not need to do any real heavy lifting-ie. more demanding audio/video work.

You guys can go on and on about QT vs. Glib dependencies, or  LGPL vs GPL, or about how good gstreamer compatibility is acrosss various OS’s-but if KDE needs binary compatibility for the life of KDE4 and phono fills this bill then it is the best tool for the job.

Of course what would be really cool is if Nokia/trolltech would simply wrap the entirety of gstreamer and place it directly into QT. Then QT/KDE devs would have this amazingly simple abstract API which is pure magic for those devs and they would embrace the media framework developed by and for the FOSS community. Then work could be done to soldify the OS X and Windows gstreamer ports so that really shine.

And of course what would also be really cool is if QT/KDE would wake up and smell the roses and actually address the issues which Pulseaudio is addressing. I want to see support for XDG sound themes in KNOTIFY and I want KNOTIFY not to wreak havoc with other applications vying for access to my sound card. Hey maybe if the KDE community would embrace Pulseaudio there might even end being good ports of Pulseaudio to other OS’s 😉 And I want that when I use a KDE multimedia app that it registers itself with Pulseaudio and lets me redirect my audio to my PC connected to my home surround sound system.

Put another way it simply would not hurt QT/KDE to embrace gstreamer and pulseaudio and to do so publicly. Many act as if these two projects were GNOME projects-the reality is it is the distros which have made their interests clear-gstreamer is *the* FOSS media framework and pulseaudio is *the* FOSS sound server. This is not a GNOME vs. KDE thing-it is a KDE-runs-on-every-platform-under-the-sun-aspiration vs. Linux distributions. The linux community via gstreamer and pulseaudio is finally beginning to really address some its real shortcommings and
KDE is off touting Windows compatibility…major disconnect here…

And in the meantime we will just ignore the fact that most users don’t care about the legal obligations of the commercial corporations involved in gstreamer development and the commercial corporations involved in Linux distribution-us users will simply install xine and mplayer to deal with those things which gstreamer cannot deal with or only deal with by demanding outrageous sums of cash. At least KDE devs give us the choice to use xine-something the GNOME devs don’t do(ok I lied: totem-xine is still around ;)).

ps.
I use Gstreamer and I am quite impressed with it’s capabilities and the apps which utilize these to their fullest. But I must add that I find it sad that Gstreamer is *still* not capable of dealing with as many, and dealing as well with the formats supported by xine. Gstreamer has improved by leaps and bounds, and it has a tremendous community built up around including a number of commerical companies-a community much larger and more diverse than xine. Yet xine is still the only media lib I have found that religously works with any damn thing I throw at it. Of course on most distros xine is so crippled that it is basically useless-but here I am using xine on 64bit(which means no wincodecs) and the only thing that I find that it could still do better is navigate menus on DVD’s(I am just waiting for libdvdnav to be cleaned up and integrated in xine-the newest version with mplayer allows for flawless DVD playback). Gstreamer still fails to support a number of formats- and of those which it does support it often fails to do things like fast forward/rewind. That phonon can use both gstreamer and xine means that I can playback virtually any kind of media in existance. And it needs to be said that it is the commercial companies and their legal requirements which are the biggest limiting factors in Gstreamer capabilities-and it is this squeaky-clean image of Gstreamer which is driving it’s commerical adoption(3 years ago I could playback DVD’s far better with Totem-gstreamer than I can today, before the commercial interests basically took over gstreamer). Now Ubuntu can offer me gstreamer codecs to playback the contentious formats-$90 or I can simply use xine-which irks me greatly because the DVD drive which I purchased already included a license for DVD playback-just not for Linux-which to me is utterly absurd.

it's me ;)

me

After reading this:

http://blogs.gnome.org/johannes/2008/09/06/30-mockups-part-1-desktop-organisation/

I just wrote down some of my thoughts.

@Markus

Although I do not wish to speak for Johannes, when developers are talking about libraries and in *that* context speak of users they usually mean other developers, not end users. The *user* of a library is an API-consumer, ie. another dev/project which will be using the functionality of the new API. Any time a new version of a library comes out which significantly changes it’s API each and every dev/project making use of this library has to rewrite their code to adapt to the changes. A lot of what was in GNOME prior to GTK+-2.0 took a long time to get ported to the 2.0 API, some code never did. New features which are appealing, offering concrete benefits to the *users* of the API, ease the transition, make it easier to justify the time and labor.  If the new features trigger the “oh now I could finally do X with my app, which I couldn’t do before without great effort” then people rally around the new version and are want to rapidly port their software-this translates to concrete benefits for us end users-our applications make use of the newest features present in the API.

@GTK+-3.0
Personally I hope the devs take their time when it comes to GTk+-3.0. With time and patience 3.0 could be really amazing. Heres is a couple of things I would like to see:
1) Prior to 3.0 release their should be 100% coverage of the new API in all of the GTK bindings (Python, Ruby, Java, etc.)
2) Vala should reach 1.0 with complete stable bindings for GNOME platform-make sure Adjunta is ready to be *the* IDE for new GNOME apps using Vala.
3) Finish gobject-introspection, GTK bindings should autogenerated with each iteration of the new API-no more pygtk <=2.12, rubygtk >=2.14 etc.
4) finish the transition of GTK to Cairo, give our new desktops resolution independence.
5) get the mono/GTK# guys to sync with the new API.
6) document, document, document

If the time was taken to ensure the completion of these things prior to releasing 3.0- a) there would be enough time to smoothly integrate some significant chunk of Clutter into GTK proper b) devs would have a really mature, well documented and easy platform to create GNOME-3.0. If the bar is not set high many of the things listed here will be pushed to the side and get side-lined in the lure of playing with new tech, recreating much of the malaise currently existing. And I still wonder if Clutter will ever offer what a GTK-evas would(there is already a QT-evas port).

Further off I wonder if Tamarin/tracemonkey could provide GNOME with a way to offer javascript as *the* scripting language of the GNOME desktop(ie. create javascript D-Bus bindings, ensure that all GNOME apps expose their functionality via D-BUS and provide a nice jitting sandboxed environment to give end users a powerful scripting language to really take control of their desktop.

@Johannes

I would love to see something like this in a future version of GNOME. A couple of points I see:
1) object persistence- If I plug in a USB stick HAL/gnome-volume-mount should assign a persistent name to that USB stick. When I move the icon on my desktop for it, the next time I insert that USB stick it’s icon should appear exactly where I last placed it’s icon, and it’s name should be persisent- not disk/disk-/disk-2 depending on if it’s sunday, raining, or the wind is blowing.
2) a region of the desktop could be reserved for newly created/downloaded documents. But then again we have directories for this kind of organization. I personally would prefer to have the virtual desktops functionally utilized for this purpose-ie. each virtual desktop can have it’s own background and it’s own regions and allow users to configure which regions and which desktops are used for displaying which objects. Some regions could be defined to be present on all desktops, others for specific ones. Maybe something along the lines asiego talked about here could be inspirational: http://aseigo.blogspot.com/2008/09/plasma-context-and-nepomuk.html.(telepathy/empathy/galago are all tech’s which lead in the direction of contextualization- “presence”)
3. Perhaps some of these regions could be embedded Nautilus windows( I use devilspie to create windowless embedded gnome-terminals on my desktop). If Nautilus was embedded in a region of the desktop without(hidden-accessible via key combo) menus and without window borders but with a scrollbar these regions could correspond to actual directories.
4. What I really would love would be a region for previewing files: ie. drag a file onto the region and preview the file there- drop a PDF there and let Evince show the contents of the PDF(without opening an Evince window)., drop a song there and have Totem play the file(without opening a Totem window), drag a DOC file there and let Abiword display it’s contents(again without opening Abiword)- expose a tiny subset of functionality-it 2 buttons appear above the displayed DOC file- Print and Edit, or for the song, Add to Playlist, or for the PDF simply Print. Can you tell how much I miss bonobo 😉

Keep up the good work-sorry if this is too long 😉