vv libPurple API

Maiku cmaiku at gmail.com
Tue Oct 28 16:21:49 EDT 2008


The libPurple media API for voice and video needs some cleanup and
refactoring. Right now it's a nearly 1 to 1 abstraction of the
Farsight2 API. Therefore, I've come up with the following alternate
structure. I'm be curious to hear what people think.

for functions that could be per conference, session, or stream, a NULL
would be a wildcard

PurpleMediaManager
functions:
*_initiate# Creates a PurpleMedia instance. Probably have a flag
		   as to whether it's the initiator or responder

signals:
init-media 	# Same as the current signal. Is triggered when *_initiate is called
init-video-src# These are all triggered when the corresponding *_get_*
functions are called
init-video-sink	  The one problem I've thought of with them is that
this way it wouldn't
init-audio-src	  be very easy to have multiple srcs or sinks of the same type.
init-audio-sink

get:
*_get		# Returns a global instance of the PurpleMediaManager

*_get_pipeline	# Returns a global pipeline to be used for all
PurpleMedia instances.

*_get_video_src		# These all create their respective types if they don't exist.
*_get_video_sink	  Otherwise they return a src/sink-pad for the
existing src/sink.
*_get_audio_src
*_get_audio_sink

# The next three functions will probably have a type parameter (audio
or video, src or sink)
*_get_plugins	# Return a list of audio/video GStreamer plugins (eg.
v4lsrc, alsasrc)
*_get_devices	# Return a list of devices for a specific plugin
*_get_devices_autodetect # Eventually, return a list of devices
detected for all supported plugins


PurpleMedia
functions:
# All of these functions will have parameters for session_id and participant_id
  NULL for either of these would indicate a wildcard and do this
operation for all
  matching streams

*_add_stream	# Adds a stream/session/participant to the conference,
automatically
		  creates participants and FsSessions as necessary
*_remove_stream # Removes a stream/session/participant from the conference

*_set_direction # Changes the direction of a stream/session/participant
		  (could use *_add_stream to accomplish this)

# The following two could probably be merged into one function
*_mute	# Mutes an audio stream/session/participant (sending and/or receiving?)
*_pause # Pauses a video stream/session/participant (sending and/or receiving?)

*_end	# Ends a stream/session/participant


signals:
# These signals also apply to the wildcard note above
ready	# Waits for both codecs-ready to be TRUE and candidates-prepared
to have fired
connected # signals when a new stream has connected (src-pad-added)
(useful for raw-udp at least)
end	# Signals when a stream/session/participant has ended

# More signals may be necessary for different protocols
  Jingle ice-udp may also need a new-candidate and/or new-candidate-pair
  and a codecs-changed equivalent

get:
# I'm not certain all of these will be necessary
*_codecs	# gets codecs per sessions
*_candidates	# gets candidates per stream
*_streams	# gets stream_ids by session or by participant
*_sessions	# gets session_ids in the conference
*_participants	# gets participant names by conference or by session




More information about the Devel mailing list