[Nice] a Farsight 2 nice transmitter, a git repo and various related thougths

[Olivier Crête]

Hello,

I've written a half-working Farsight 2 transmitter on top of libnice.
I've hit quite a few problems.

First, I imported nice into git. Darcs wouldn't let me push a
no-conflicting branch. I've had enough, darcs is dead to me.
Its at http://git.collabora.co.uk/?p=user/tester/nice.git;a=summary
(master is the darcs master, kai's and kakaroto's branch are imported
as-is and my changes are on the nice-tester branch).

So, the nice transmitter itself is at
http://git.collabora.co.uk/?p=user/tester/farsight2.git in the "nice"
branch (and you need my nice-tester branch from git too).

My unit test creates two pipelines (with two separate agents) with each
one stream and two candidates. Most of the time, only one agent posts
READY, the other one seems to not post state changes... But sometimes,
it works.. And once that agent has posted ready, the data flow works
correctly.

I also added a nice_agent_gather_candidates() method that starts the
candidate gathering. So add_stream() just creates the stream structure
and returns the stream_id. What happened was that signals with the
stream id where emitted before the stream id was returned... Now its two
nicely separated operations (which happens to nicely match the Farsight2
transmitter api..).

If I add more than one stream, I have no way to know to which stream the
"gathering-done" signal relates to, it should probably be a per-stream
signal (emitted on a stream object, more on that later).

There were two structures, NiceCandidate and NiceCandidateDesc to
represent candidates, I removed NiceCandidateDesc and use NiceCandidate
everywhere (they were both exposed in the API in anyway).

The various functions that return lists of candidates do shallow copies,
making it hard to use in a multi-threaded context. They should make real
copies. Same for the function that gets the ufrag/password.

I made the default buffer larger (64k), because they are used to receive
data UDP packets and we don't want them to be truncated. Ideally, we'd
just allocate the memory on demand (that's what all the other gstreamer
sources do anyway).

Youness also added some mutexes in the hope of making it thread-safe.
That said, I'm still hitting some strange problems, probably some kind
of race that will have to be investigated further.

The API would be much nicer if there was a GObject for each stream
(which already exist internally...) and all functions/properties/signals
would be moved to the streams. Maybe except the timeout context.

I'm also a bit lost on what data exactly is shared between streams in an
agent? Shouldn't the result from one stream be used to construct other
streams to the same destination? Or not?

Also, if I have a multi-party conference. Should there be one agent per
peer? Or some other kind of arrangement?

-- 
Olivier Crête
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/nice/attachments/20080426/d08410ee/attachment.pgp