Fri, 30 Aug 2024 19:33:36 -0500
Update the plugins page for the new process
This includes defining the process and providing a template for a new issue to
add new plugins. I did go through and audit `No IRC /WHO` so we had at least
one validated entry.
Testing Done:
Ran `npm run hugo:server` locally and verified the page worked and checked the new links.
Bugs closed: NEST-53
Reviewed at https://reviews.imfreedom.org/r/3450/
--- title: Voice and Video API date: 2019-03-17T23:11:17.000Z replaces: - developer.pidgin.im/wiki/vvAPI lastmod: 2019-08-21T04:05:48.000Z --- For functions that could be per conference, session, participant, or stream, they would have a session and a participant parameter. A NULL for either of these 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 *_add_candidate # Adds a single candidate to the stream (May not be necessary. Could alternately add a list) *_set_candidates # Sets a list of candidates for the stream *_set_codecs # Sets a list of codecs for the stream *_set_direction # Changes the direction of a stream/session/participant (could use *_add_stream to accomplish this) *_accept # Accept a session (User clicked the accept button) # 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/conference ``` #### 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 (possibly also wait for the user to click accept if they are the responder otherwise we'll probably need an "accepted" signal) state-changed # Has an enum state (containing such states as connected, end, and ice-specific values) Signals for stream/session/participant/conference ``` 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 ```