Re: telepathy roadmap and media streaming
Jimen Ching <[email protected]> Fri, 29 Sep 2006 12:54:20 -1000 (HST)
| Newsgroups | gmane.comp.gnome.gossip.devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 29 Sep 2006, Robert McQueen wrote: > You need to know whether you're expecting incoming video to know whether > you should display a video output window, whether you have incoming > audio to present a mute button and a volume control. You should show the > user when their audio and their video is being sent, perhaps offering an > outgoing audio mute, and a preview windoiw. You need to know when the > remote end has asked to change an incoming audio stream to an outgoing > one, because otherwise the user could be streaming audio without knowing > it... I think most of these directionality change events are relevant to > the user or to configuring the UI correctly. First, I should clarify my proposed API. This API is for the UI developer, which will translate to an interface to the Gossip end-user. I.e. if there's no API for the UI developer, the Gossip end-user won't have that interface either. I'm making the assumption that any UI developer API that is defined, will be completely exposed to the Gossip end-user. Since this is an application API, I don't see the point in defining an API that doesn't affect both the UI developer and the Gossip end-user. Concerning your scenerios above, I've never considered the use case of initiating an out-going voice call but only 'receiving' audio data (i.e. not generating audio data). Basically, this is like initiating a bi-directional channel, and muting the outgoing stream immediately. I guess this could be useful under a broadcast use case scenerio. I should also note; the API I proposed has inherent directionality. request_voice_chat (establish bi-dir outgoing channel) cancel_voice_chat (cancel the above) accept_voice_chat (complete bi-dir incoming channel) reject_voice_chat (close bi-dir incoming channel) The video channel API has A similar API. The 'publish' API is for outgoing channels. Granted, this does separate the voice and video streams. I guess I made the assuption that we want to do this. Guess that may be a bad assumption. It seems what we need to do first is to define the use cases we want to support. Let's end this thread here, and I'll start another one for discussing what capability we want to support with the media streaming feature. --jc -- Jimen Ching (WH6BRR) [email protected] [email protected]