Re: FsAppTransmitter / dummy call in nullprpl

On Mon, 2017-11-06 at 19:40 +0100, Jakub Adam wrote:
> Hi David,
> 
> after commenting out
> 
>   "wait-for-connection", FALSE,
> 
> in g_object_set() of the file sink (which is a property GstFileSink doesn't have)
> Pidgin started saving raw audio into /tmp/pidgin.s16 and I was also able to import
> the file to Audacity and play it back correctly.

Hm... so it looks like I can't actually get Farstream to do any of the
codec work for me. That's in FsRtpConference, not FsRawConference. If I
attempt to set the remote codecs to Opus, it isn't going to work.

So I probably need the "opusenc ! appsink" and "appsrc ! opusdec" parts
to be handled by my new FsTransmitter. It isn't just "FsAppTransmitter".

I'm thinking of following the precedent set by FsShmTransmitter and
abusing the host and username fields of the FsCandidate, except not
with filenames as FsShmTransmitter does it, but with pipeline
descriptions to be handled by gst_parse_launch().

That also resolves the issue of communicating the appsink/appsrc
between the FsTransmitter and the application (which Pidgin in
particular is going to make complex with its abstractions). The
application (the PRPL) can just precreate those, then refer to them as
named elements in the pipeline descriptions it passes in to the
transmitter — something like "opusenc ! chimecallappsink0." and
"chimecallappsrc0. ! opusdec" for "host" and "username" in the
FsCandidate respectively...

Does that seem reasonable? 

_______________________________________________
Farstream-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/farstream-devel