[pulseaudio-discuss] GSoC: Call for project ideas
tanuk at iki.fi
Mon Mar 25 10:22:18 PDT 2013
On Mon, 2013-03-25 at 16:51 +0000, Arun Raghavan wrote:
> On Mon, 2013-03-25 at 18:09 +0200, Tanu Kaskinen wrote:
> > > The simplest idea I can think of to deal with this meaningfully is to
> > > wrap a sink/source around a GStreamer pipeline to offload all that work
> > > that we don't want to duplicate in PulseAudio .
> > >
> > > On the sink side, we'd hook up to an appsrc to feed PCM data to a
> > > pipeline. The pipeline would take care of encoding, RTP packetisation
> > > and possibly a corresponding RTCP stream. This would allow codec
> > > selection to be flexible, and in the distant future, could even support
> > > taking encoded data directly.
> > >
> > > On the source side, we'd hook up to an appsink, receiving PCM data from
> > > the pipeline. The pipeline would take care decoding whatever the format
> > > is, take care of RTCP and maybe more advanced features such as a jitter
> > > buffer and packet-loss concealment (all of this can be plugged in or
> > > not, depending on configuration).
> > >
> > > Doing it this way means you're using a better RTP stack that gets
> > > attention from a number of other use cases (plus assorted related
> > > goodies) and support for multiple codecs.
> > >
> > > Thoughts?
> > I like the idea of offloading stuff to GStreamer very much.
> > Do you follow GStreamer development closely? If I've understood
> Not very closely, but I do some periodically work on stuff in GStreamer
> (and have commit access).
> > correctly, GStreamer hasn't supported rewinding in the past, has there
> > been any talk about that lately? Lack of rewinding support in any part
> > of the audio pipeline causes bigger or smaller problems. I don't think
> > it's a critical problem in this particular case, although rewind support
> > would be useful in this case too. If we would like to use GStreamer for
> > implementing filters, rewind support would be pretty mandatory.
> The idea I have is separate from filters - it's really only about being
> able to use GStreamer for codecs + networking (RTP).
Sure. It's just very tempting to think beyond just that. GStreamer has
so much stuff that PulseAudio could reuse, if only there was rewinding
More information about the pulseaudio-discuss