GStreamer API over RPC: does it make sense?

[Sebastian Dröge]

On Mi, 2013-11-06 at 21:28 +0400, Fedor Lyakhov wrote:
> On Wed, Nov 6, 2013 at 3:34 PM, Sebastian Dröge
> <sebastian at centricular.com> wrote:
> > On Di, 2013-11-05 at 22:28 +0400, Fedor Lyakhov wrote:
> >> Hi Sebastian,
> >>
> >> Thanks for your comments! Very encouraging for me.
> >> Are you talking about SoC 2014? Where can I look at the status of this
> >> project? Is it awaiting approval from Google now?
> >
> > It was just an idea I had for 2013 and put on the GStreamer GSoC wiki
> > page. Nobody was interested in doing that :) Also highly irrelevant for
> > your problem AFAIU.
> >
> >> As for what we really need for Spice - I'm not sure I understand your
> >> idea correctly. There are 3 major media-related use cases we want to
> >> optimize:
> >> * playback of a local media resource (local - at VM); this is
> >> addressed at http://www.spice-space.org/page/Features/CodecPassthrough
> >> * playback of a remote media resource
> >> * IP telephony
> >> Last two are addressed at
> >> http://www.spice-space.org/page/Features/MediaRedirection
> >> [...]
> >
> > A complete design for this is not really trivial and you would need to
> > consider all your requirements and constraints carefully. So just some
> > hints here what you could do.
> >
> > One thing you could do is to make GStreamer audio/video sinks that
> > accept compressed data (+ some control data) and send that over the
> > Spice channel. And on the other side these are then decoded and put in
> > the right place. Of course will only work for GStreamer applications
> > that use those sinks (well, and playbin if you do it right). Also the
> > streams would be demuxed and parsed before sent over the Spice channel.
> >
> > The same could be done on the input side with custom sources.
> >
> >
> > Proxying the complete GStreamer API doesn't seem like it would solve
> > your specific problem, other than making everything more complicated :)
> >
> 
> Ok, this sounds like a good approach for Codec Pass-through feature!
> But I still don't understand why do you think remoting GStreamer API
> cannot help with Media Redirection?

It would be quite complicated for your specific use case. It would be
possible though, but I don't think it's the easiest and most performant
solution.

> 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.

-- 
Sebastian Dröge <sebastian at centricular.com>
Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131106/6ddcc3a0/attachment-0001.pgp>