Kamoso is alive!

After months of being almost a dead-zombie project now the Kamoso development has been resumed, we can say that it is in better shape than ever! Motivated by the QtGstreamer project, Aleix and I decided to port Kamoso to it and see how it goes (it has been the perfect excuse to revive the project). So far we didn’t regret the change. Besides the technology switch (we we’re kind of ok with libvlc), the change has given to us new forces to work on the project, let’s see what we’ve got so far:

Current features:
  • Take pictures
  • Upload pictures to facebook (kipi plugins export interface)
  • Record video
  • Upload videos to youtube
  • Burst mode
  • Smoother thumbnails view
  • Fancy overlay icons to indicate what files are being uploaded
Work in progress:
  • Add some logic to decide what microphone to use (depending on platform).
  • Facebook video support
  • Choose webcam
  • Twitpic support
The application is quite stable right now, so we’re open for feedback, to compile it you have to:
1-Have gstreamer installed (base and good plugins are needed)
3-Get Kamoso sources from git.kde.org:kamoso
Well make a release shortly, for the waiting here comes a Kamoso2 funny video:
The video’s recorded in the screencast are uploaded Ereslibre Sexy and Ereslibre Monkey.

Cya and Happy Hacking!
  • Ian Monroe

    What do you think of QtGstreamer?

    The biggest pain of gstreamer has always been doing even simple things with its API, so a Qt binding is appealing…

  • the_madman

    The issue I have with this is that it depends on GStreamer. If I’m running the rest of my system (using Phonon) with Xine or VLC, then it would mean pulling in GStreamer and tons of GStreamer plug-ins for one application.

    Ideally, camera/microphone capture would be put into Phonon and Phonon would abstract away the differences between the various multimedia systems on Linux.

    • http://www.afiestas.org afiestas

      that won’t be enough to have a good user experience (in kamoso), so pretty much forget about it :/

  • Bugsbane

    Sounds great. So, uh, what is the Kamoso project actually supposed to do? There’s no description or link in the post…

  • dracko

    @the_madman
    Phonon is broken software. I hope the all kde software will stop using Phonon, and start using Gstreamer by QtGstreamer. And we will be have one multimedia standard in Linux. Telepathy-kde will also using Gstreamer, and Nokia also will using Gstreamer in MeeGo. Phonon will be forgotten, i hope so.

    • http://www.afiestas.org afiestas

      Well, I don’t think that Phonon is broken software, but right now it is not an option for us.

  • yoda

    yep… gstreamer is bad way to do this! it’s little app and it should be light and fun, kde4 need web cam software, the best way would be xine which is default and jump to vlc backend which will be default

    • http://www.afiestas.org afiestas

      why gstreamer is bad ?

  • Fri13

    @Bugsbane

    There is the link to the video showing the new features of the Kamoso.

  • dracko

    @afiestas

    “why gstreamer is bad ?”

    For me one thing – depency of GNOME packages in gstreamer-plugins-good. Rest is the best way for multimedia in GNU/Linux. New application using Gstreamer, almost nobody uses Phonon, olny KDE guys. Problems with Phonon? Look at kde forum – so many problems…

    • http://www.afiestas.org afiestas

      About the dependency, is something to talk with the gstreamer guys, I’m sure that we can find a solution. About Phonon, I never had any problems, I guess that all the problems relay on the backends (since phonon is a thin layer above them).

  • dracko

    One more thing – if using Phonon application will be depency od good shape of Phonon, Phonon-backend, and multimedia liberary (xine/gstreamer/vlc).
    With good Qtgstreamer blindings is olny dependancy of good shape Gstreamer.
    For me choice is obvious.

  • jospoortvliet

    I must agree that it would be great if Phonon was up to the job. Mostly because some things simply don’t work with gstreamer, no matter how nice it is according to many people – VLC just works better, even xine works better with many media files I have. Not even talking about the much higher CPU usage of gstreamer compared to VLC and Xine.

    And having xine as default then having to use a gstreamer app – big screwup. Frankly I wish the energy spend on gstreamer would be put in phonon to make sure it would be a proper abstraction layer for basic app needs – something like Kamoso shouldn’t need anything else than Phonon.

    But hey, if the gstreamer dev’s re-write gstreamer (and/or it’s API) again, screwing both users and developers, maybe ppl realise there was a reason why Phonon was written. Of course it’d be even more fun if Gstreamer goes unmaintained because a better multimedia framework comes around.

    • http://www.afiestas.org afiestas

      I must agree that it would be great if Phonon was up to the job.

      But It won’t for us, an application like kamoso is not the target of Phonon (not even of QtMultimedia which is lower level)

      Mostly because some things simply don’t work with gstreamer, no matter how nice it is according to many people – VLC just works better, even xine works better with many media files I have.

      Well, I’m sure of that, but Kamoso is not a video player so we don’t are affected by that part (BTW I’m using gstreamer to play files and so far it works well).

      Not even talking about the much higher CPU usage of gstreamer compared to VLC and Xine.

      I never saw a benchmark between them, can you point me to one? at least in Kamoso we’re glad to see how well it scales, for example finally we’ve get rid of the lag we had (I’m sure that the lag can be avoided using vlc, I just never managed to do it).

      And having xine as default then having to use a gstreamer app – big screwup.

      Agreed, but as it happens in the source version control world, there are many options and we have just to choose one, KDE chose Git, we chose gstreamer.

      Frankly I wish the energy spend on gstreamer would be put in phonon to make sure it would be a proper abstraction layer for basic app needs

      It is already (using experimental), but Kamoso is not a basic app

      – something like Kamoso shouldn’t need anything else than Phonon.

      Well, I think that you’re out of line here, you don’t know what Kamoso developers want to accomplish, and you don’t know even the current needs, so please do not talk about what you don’t know.

      Just to give you one reason, Phonon is designed to be an abstraction layer above backends, its features depends on its backends offering no consistency between them, only because of that use Phonon in Kamoso is not an option since we need consistency (for example to be sure that X effect will be available), this is why we chose VLC before. Of course we can extend Phonon until it meets our needs, but Kamoso is a pet project and we’re not willing to do it, and even if we do it expect the same behavior between backends when doing more than just “Play, record” is almost impossible.

      But hey, if the gstreamer dev’s re-write gstreamer (and/or it’s API) again, screwing both users and developers, maybe ppl realize there was a reason why Phonon was written. Of course it’d be even more fun if Gstreamer goes unmaintained because a better multimedia framework comes around.

      If one day Phonon offers all the API we need, then create a plugin for Phonon will require as much effort as port to the new created API, but for a Player of course Phonon is what I will chose.

  • iria

    Everybody complain about Gstreamer in here. But if this is true – http://www.qtcentre.org/threads/13896-v4l2-video-capture-input-in-Phonon

    Gstreamer is the best choice in this situation. Phonon in this time is limited.

  • Pingback: Last week in QtGStreamer – week 7 | Code diary()

  • yuri

    @dracko
    I agree: I don’t like (and I don’t want) GNOME dependency in gstreamer-plugins-good.

  • Tim

    @drack, yuri: GStreamer doesn’t have any hard dependencies on GNOME libraries (other than GLib). gst-plugins-good does among many other things contain plugins for things like gconf (in the process of being deprecated, btw) or libsoup (souphttpsrc), but also plugins using e.g. taglib. It is up to distros to decide how they package these things. There is no reason they can’t package gst-plugins-good so that there’s a separate gstreamer0.10-plugins-gconf binary package for example. At the source code level you can enable/disable plugins individually as you like, and e.g. the gconf plugin won’t be built if gconf headers aren’t available.

    In short: get in touch with your distro if they package things in a way that makes gst-plugins-good depend on things that aren’t required for KDE apps/users.