Posted
about 24 hours
ago
by
justin
Voice (and video) chat is a feature we’ve wanted in Psi for a long time. However, implementing voice/video chat is not straightforward, and this is partly due to all of the new concepts that have to be introduced into the application in order
... [More]
to make it happen. Cameras, microphones, codecs, and RTP are all just very foreign to Psi. The code necessary to handle a multimedia “stack” could easily exceed the amount of code in our own IM stack! Fortunately, there are libraries out there to handle the task.
In 2004, we considered RealNetworks’ Helix framework. For receiving content, we found this framework to be quite mature. However, for transmitting content, it was clearly not designed for end-user desktop applications and was even GPL-incompatible in that scenario. Quite some work went into the Psi Helix effort, but ultimately it was abandoned.
In 2005, we considered Google’s libjingle. We managed to get voice chat working with it, but the code never went beyond the experimental stage. This was due to the limited platform support at the time (Linux audio only at first, though Remko managed to add in Mac audio support) and libjingle’s lack of maintenance. Libjingle works as a black box, handling not only multimedia but also the Jingle protocol. Unfortunately, this meant that as the Jingle protocol changed, libjingle fell out of spec. We also felt it was a tad intrusive for libjingle to be handling XMPP stuff.
In 2006, we investigated GStreamer. This framework has proved to be the most interesting thus far, for a number of reasons. Unlike the limited libjingle black-box, GStreamer is a comprehensive and flexible multimedia framework, similar in nature to Helix. It goes further than Helix though, by offering a better API for transmitting, by being GPL-compatible throughout, and by being easier to extend. I feel confident we can accomplish everything we need with GStreamer.
Today there is Phonon, however it lacks input and transmission facilities at this time. We will keep an eye on it for the future. There is also Farsight, which integrates with GStreamer. We may make use of Farsight, depending on our needs.
In any case, I’ve started a new “wrapper” project called PsiMedia. The goal of PsiMedia is to offer an API designed for the purpose of adding voice and video chat to Psi or a Psi-like client. All of the details the client does not care about will be hidden behind PsiMedia. It solves only the multimedia aspects, and not Jingle/XMPP, as I consider these two problems to be orthogonal. Currently PsiMedia wraps GStreamer, but the requirements are abstract enough that the client should not care what is actually wrapped. PsiMedia can be considered the successor of the old “Media” module I started in 2004, to wrap Helix.
Below are the requirements of the system.
What PsiMedia does:
Tell you what audio and video devices are available.
Tell you what audio/video modes are possible (codecs, sample rates, video resolutions, etc).
Allow you to specify your desired modes, and the modes of the remote party, to arrive at a list if common modes.
Capture audio/video and encode as RTP into a series of QByteArrays.
Accept QByteArrays containing RTP, and playback any audio/video contained within.
Play back video in a QWidget.
Allow displaying video currently being captured (preview of yourself).
Volume controls.
Ability to separate the backend into a plugin, so that no new compile-time dependencies are introduced to Psi.
(RTP, by the way, is a standard packet format for transporting multimedia data in real-time. It is used by SIP, Jingle, and, well, everybody.)
What PsiMedia does not do:
Use the network.
Implement Jingle or anything XMPP.
Expose anything more than very basic multimedia details. There are no filters, no pipelines, etc.
In short, PsiMedia should make implementing voice/video chat in Psi straightforward. [Less]
Posted
1 day
ago
by
Adam Czachorowski
Another GSoC week passed, here’s a late, very short report on progress.
Things done:
further UI improvements, including status messages and basic tooltips,
drag & drop support with move and copy contact
... [More]
actions
more context menu items
resources displayed on roster under contact (when expanded)
Things to be done this week:
We’re moving a little bit lower to data layer and right now me and Remko are trying to agree on how this layer should look like. When we’re done with that, I’ll implement building roster, joining multiple accounts into one and joining contacts with same names into metacontacts.
I promise to write something more next week [Less]
Posted
3 days
ago
by
nos...@example.com (Paweł Wiejacha)
Yesterday I finished first release of my Summer of Code project. I did what I had wanted to do and now I'm on my schedule.
There is:
MessageValidator that removes malicious tags/attributes from XHTML-IM messages. For example, we
... [More]
don't want to get messages with <script> document.location="buy.viagra.com"</script>. Today I'll try to finish CSS validation. I have to create more unit tests. Oh, and I have to get through XHTML/XHTML-IM specification/XEP to complete allowed tag lists.
You can create new HTMLChatView with chosen theme and variant. But all messages are cleared after selecting new theme.
You can add Messages and Events (Status, FileTransfer).
My plans for next mini-release (Thursday) is to make standalone ChatView working "almost perfect" :D (clean up, unit tests, refactorization, better error handling, CSS validation)
After midterm evaluations I'll start integrating ChatView with Psi.
Here is a new screenshot:
> [Less]
Posted
8 days
ago
by
Remko Tronçon
Although Psi has had a fair number of succesful Google Summer of Code projects so far, we have experienced some failures as well: the summer before last, 3 out of 6 projects didn’t make the final deadline. A project’s failure was
... [More]
typically due to not having anything really usable at the end of the summer, regardless of the good work that was done during the past months. To reduce the risk of such surprises, I decided to take an Agile Development approach for this year’s ‘Roster improvement‘ project.
Here are some of the principles of Agile software development (as written down in the Agile Manifesto), and how we apply them to Adam’s GSoC project:
The developer frequently delivers working software to the customer. In our case, Adam sends me a working roster every monday, which I can play around with. I then tell him what I do and don’t like about it, and he processes my feedback during the next iteration (i.e. the next week). Of course, since the roster is made from scratch, the backend of the roster is completely mocked up during the first weeks. As the project progresses, the backend will become more ‘real’.
Working software is the primary measure of progress. This avoids the kind of surprises we had before, where both student and mentor believed everything was going fine during the project, but where nothing could be delivered at the end of the project.
Code is kept as simple as possible: if you don’t need something, leave it out. By initially focusing on the roster frontend (while keeping the backend framework mocked up), we ensure that our backend will only be as complex as we actually need it to be. Moreover, we can constantly change our mind about the requirements throughout the whole project without having to throw away the complete backend. This contrasts with the previous attempts we had at reworking the Psi roster, where we started by working out a complex roster backend, but never got to the point where we had something working with this (over-)designed framework, and had to start over all again.
Code is written with testability in mind. In principle, all new code needs to be tested (and preferably even unit tested before it’s written), which allows you to quickly refactor while remaining sure that your code still works as before. However, given the very strict time constraints, I’m not sure yet that we’re going to apply this Test-driven Development approach (although some claim that the extra time you spend in tests will even pay off in the short term).
Good designs make sure that you can easily adapt your code to changing requirements. For example, a Model-View-Controller-based design seems to lend itself well to the roster, making the (rather complex) roster logic both testable, extensible, and easy to understand.
I’m convinced that these principles will ensure that both Adam and me (and of course all Psi users) will have a succesful result at the end of the project, and that we’ll have had a fun time during these 3 months. [Less]
Posted
9 days
ago
by
nos...@example.com (Paweł Wiejacha)
Yesterday I had my last exam. I think the Google Summer of Code schedule is too American - in the States, school finishes in May. Here in Poland we have end-of-term examinations in June.
I am a bit behind my schedule, so this report will
... [More]
short :)
What have done:
I set up git repository. You can find it on github
I created standalone ChatView widget prototype.
you can append (consecutive or not) chat messages to it.
there's only one fixed chat theme
My plans for next week:
appending ChatEvents (FileTransferChatEvent, StatusChatEvent)
simple theme selection
reading themes from filesystem
simple theme dialog
validation XHTML-IM messages
Here is how it looks: [Less]
qt4 linux instant client unix chatting xmpp_client messaging x11 psi qt instant_messenger jabber xmpp instant_messaging c++ chat windows mac_os_x im jabber_client messenger communication mac osx internet
|
edit tags
