GStreamer API over RPC: does it make sense?

[Fedor Lyakhov]

On Wed, Nov 6, 2013 at 10:02 PM, Sebastian Dröge
<sebastian at centricular.com> wrote:
> On Mi, 2013-11-06 at 21:28 +0400, Fedor Lyakhov wrote:
[...]
>
>> I want to understand your point - probably it can save quite some of
>> my time in case I'd be trying to implement a wrong thing in vain...
>> Looks like while I'm lacking GStreamer knowledge, you're missing an
>> important part as well: for Media Redirection there is another
>> requirement - media streams must not pass through virtual machine. It
>> is a must, if it isn't met this isn't going to work for IP telephony
>> (I'm coming from that field actually...). So we cannot have 2
>> GStreamer instances (at virtual machine and at client) and send a
>> stream between them over Spice. We can only have single GStreamer at
>> the client side - and we need to handle in/out streams of various
>> kinds (e.g. G.711 RTP for audio IP call). At the same time, the logic
>> of where the stream needs to be sent, or when it needs to be
>> paused/resumed - it all stays at the application running at the
>> virtual machine...
>
> Ah I see. In that case I doubt you will be able to implement something
> that works transparently for the applications but instead need specific
> support for that in the communication software to have everything done
> on the client instead and have your custom protocol for the
> communication.
> I don't see how you could abstract that in a way that applications don't
> have to know about this.
>

Good point, I also doubt this :) Moreover, specific support in
communication software is how it is done by some enterprise UC vendors
nowadays - and this is custom implementation by each vendor
reinventing the wheel over and over.

So we have two "polar" approaches here:
a) Try making GStreamer API work over RPC verbatim, so applications
don't notice it
b) Design a new RPC-optimized API for applications, implement it at
the client side using e.g. GStreamer

Both are flawed: first one probably won't work for anything complex
i.e. real-world applications. Second is a new API - so it would be
suitable for new applications only, or require major porting work...
Also applications would want to support both local and remote use
case...

As I see it, something in-between can be tried out: optimize GStreamer
API for RPC, add missing parts for such RPC-aware applications... Of
course, this must be done in a backwards-compatible manner and so on.
A long-term and really hard goal - as any API change must be
justified.

For a short-term, I hope we can get something that will allow
applications to support our use case with minimal changes in their
code. I'll start with a proof of concept and see how it goes... Hope
this makes sense :)


> --
> Sebastian Dröge <sebastian at centricular.com>
> Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>



-- 
Best regards,
Fedor