how to separate decode and encode into separate processes

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

how to separate decode and encode into separate processes

ttran
Hi everyone,
I'm a new member here, and I'm also a gstreamer newbie.
So currently I can setup pipeline/bin and then configure some elements to transcode a video stream, like libav, openh264, msdk, x264, and then putting those elements into the pipeline and run the transcoding. what I like to do is separate out the elements into separate processes and have them communicate to each other through some form of ipc, like a socket for example.
for example, let say I have a something like this:

     src ! avdec_h264 ! x264enc ! sink

what I like to do is have each of those elements run as separate processes that communicates through ipc or unix sockets.
some of the things I have though of is creating parallel producer and consumer pipelines, where the decoder would run on one pipe and encoder on the other.
another idea is having multiple instances of gstreamer, still in a producer/consumer fashion.
I'm just gathering ideas to construct something like this, and not really doing any coding at this time, though I eventually will have to test all of them to pick the best performant solution. I haven't explore enough of gstreamer to fully utilize its capability for performance transcoding. And that's my other concern, latency.
At this time, my constraint is the elements can't be in the same process, particularly the encoding and decoding components, and I cant touch any discrete gpu like nvidia or ati stuff.
Thank you for any helpful input you may offer.
Tam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: how to separate decode and encode into separate processes

Sean DuBois
On Fri, Jul 07, 2017 at 04:34:00PM -0700, ttran wrote:

> Hi everyone,
> I'm a new member here, and I'm also a gstreamer newbie.
> So currently I can setup pipeline/bin and then configure some elements to
> transcode a video stream, like libav, openh264, msdk, x264, and then putting
> those elements into the pipeline and run the transcoding. what I like to do
> is separate out the elements into separate processes and have them
> communicate to each other through some form of ipc, like a socket for
> example.
> for example, let say I have a something like this:
>
>      src ! avdec_h264 ! x264enc ! sink
>
> what I like to do is have each of those elements run as separate processes
> that communicates through ipc or unix sockets.
> some of the things I have though of is creating parallel producer and
> consumer pipelines, where the decoder would run on one pipe and encoder on
> the other.
> another idea is having multiple instances of gstreamer, still in a
> producer/consumer fashion.
> I'm just gathering ideas to construct something like this, and not really
> doing any coding at this time, though I eventually will have to test all of
> them to pick the best performant solution. I haven't explore enough of
> gstreamer to fully utilize its capability for performance transcoding. And
> that's my other concern, latency.
> At this time, my constraint is the elements can't be in the same process,
> particularly the encoding and decoding components, and I cant touch any
> discrete gpu like nvidia or ati stuff.
> Thank you for any helpful input you may offer.
> Tam
>
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/how-to-separate-decode-and-encode-into-separate-processes-tp4683736.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

The shmsrc/shmsink will work for this! I currently use them and
send video/x-raw and audio/x-raw across them. The only downside is that the
consumer needs to know the caps (so you will have to do a little extra
communication)

Why the constraint for distinct processes? I do this sometime when
dealing with certain buggy parts of a pipeline (so a SEGV of one part
could be handled gracefully) when I can't control it.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: how to separate decode and encode into separate processes

Yasushi SHOJI-2
In reply to this post by ttran
Hi,

On Sat, Jul 8, 2017 at 8:34 AM, ttran <[hidden email]> wrote:
[...]
> for example, let say I have a something like this:
>
>      src ! avdec_h264 ! x264enc ! sink
>
> what I like to do is have each of those elements run as separate processes
> that communicates through ipc or unix sockets.

Do they have to be in separate processes and use IPC?
Do threads work for you?

    src ! avdec_h264 ! queue ! x264enc ! sink

queue will create another thread.

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-queue.html
--
              yashi

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: how to separate decode and encode into separate processes

ttran
Hi, and thank you for the helpful response. Yes, it definitely needs to be processes. threads wouldn't work.
but I'm still interested in hearing your ideas and approach.

writing a new plugin element is ok, but would prefer to explore every possible venue that's available first.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: how to separate decode and encode into separate processes

ttran
In reply to this post by Sean DuBois
Thank you Sean for the helpful response. looks like shared memory is a wonderful idea!
I'm not sure on the constraint reasons other than to explore the possible venues the approach.
Loading...