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