dwmw2 at infradead.org
Mon Oct 2 12:41:03 EDT 2017
On Mon, 2017-10-02 at 17:39 +0200, Jakub Adam wrote:
> David, please check the patch I attached to Pidgin issue #17246, which should deal with
> the missing "cname" property in FsRawParticipant. If it works for you I'll open a PR on
> Bitbucket for that change.
Thanks. Right now I'm having trouble even getting to the point I was
last week where it brings up the call UI and crashes; will keep working
> Hmm, if it's a call, then the PRPL shouldn't produce any audio data on its own, but
> libpurple will automatically add the audio source into the call GStreamer pipeline for you
> when you purple_media_add_stream() with type PURPLE_MEDIA_AUDIO. Usually it will be
> a Pulse or ALSA source element representing your microphone. Encoding of the raw audio
> and any processing specific to your protocol should then IMO be handled in Farstream.
> It's hard to give some meaningful advice without any details about the protocol you're
> implementing. How does it negotiate which codec, IPs and ports the clients should use
> in the call? If you don't use RTP, is the output of the audio codec (I guess you mentioned
> OPUS in previous conversation) transmitted over the network as-is, or is the data
> encapsulated into packets of some custom protocol?
It's encapsulated into packets of the custom protocol — encapsulated
over a DTLS connection (or websocket as fallback) along with a bunch of
other stuff my PRPL handles. That's why I'm already demuxing it and
printing hex bytes — and I can even Opus-decode it and dump it to a
file and play it back later. Right now I'm sending back empty (muted)
frames — I have to send *something* or it kicks me off the call
completely and I stop getting even the other data.
I can make a GStreamer src/sink which are linked into my PRPL. My
users, who have been playing with this while I've been busy for the
last week or so, have that working with it directly hooked up to
mic/speakers and ignoring Pidgin for the call handling entirely.
But connecting it up to Farstream and Pidgin "properly" it not quite so
I'm pondering a FsGstTransmitter, based on FsShmTransmitter except we
just pass in our own Gstreamer elements for source and sink. Does that
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4938 bytes
Desc: not available
More information about the Devel