Use Unix-Sockets instead of TCP via localhost

[MaZderMind]

Could save CPU-Cycle and allow a nicer namespace

[fightling]

Has anybody an idea how to configure gstreamer to accept a IPC socket as source?

• replacing the command TCP connection with an IPC socket was easy: I've created IPCSingleConnection and IPCMultiConnection which work mostly like the TCP pendants
• also could manage ffmpeg to send output to ICP sockets with the unix:// prefix in output the URI

The voctocore accepts the ffmpeg output via ICPSingleConnection which forwards the data via fdsrc to the gstreamer pipeline. That seem to work - like before with TCP.

The voctogui however is using tcpclientsrc directly in the gstreamer pipeline which I currently can not replace by a IPC source.

I think I will have to use IPCSingleConnection in voctogui as well and then hand the read data into gstreamer using an fdsrc like the core is doing it.

Any better ideas, any suggestions?

[fightling]

or maybe I use ipcpipeline

[MaZderMind]

I don‘t know if this would be useful at all. As far as I can tell, the TCP Stack on modern Kernels is so efficient (especially when communicating via loopback), that there‘s no gain in using ipc or unix sockets.

I would suggest to just close this issue.

[fightling]

Really? Quite possible, but I would prefer to do a simple test with two pipelines connected via TCP vs. ICP to get some evidence.

[danimo]

This StackOverflow answer indicates that Unix sockets are still superior to a loopback TCP connection. Quote:

66% latency reduction and almost 7X more throughput explain why most performance-critical software has their own IPC custom protocol.

[danimo]

Sidenote: we have seen high levels of interrupts (see itop). While I would be surprised if they went down significantly when switching to Unix sockets, it's also another thing worthy of investigation. The number of interrupts. not CPU usage, seems to be the bottleneck in some scenarioes.

[fightling]

My :fire: CPU :fire: burns when using voctomix! But I'll take a look into itop.

Thinking in long terms: What about a voctogui which starts it's own internal voctocore in a local situation? With a little rearranging of code it should be easy to just implement a complete pipeline from the sources to the outputs without any TCP or ICP between. That may save context switches.

[MaZderMind]

You can reduce the resolution to 192x108 Pixels or even lower. I often do this during development.

I don’t see a benefit from merging the two together, at least not in a c3voc-style setup.

[fightling]

I don’t see a benefit from merging the two together, at least not in a c3voc-style setup.

I see.

[CarlFK]

""" We wanted a small videomixer core-process, whose sourcecode can be read and understand in about a weekend. All Sources (Cameras, Slide-Grabbers) and Sinks (Streaming, Recording) should be separate Processes..... All sources and sinks should be able to die and get restarted without taking the core process down. """ https://github.com/voc/voctomix/tree/master/voctocore#design-goals

Keeping it rock solid is important. More important than running on slower CPUs.

On Wed, Apr 25, 2018 at 8:50 AM, Patrick Hoffmann [email protected] wrote:

I don’t see a benefit from merging the two together, at least not in a c3voc-style setup.

I see.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/voc/voctomix/issues/38#issuecomment-384293971, or mute the thread https://github.com/notifications/unsubscribe-auth/AABauUflcsM0oEV1x0560UHVptbmyF9lks5tsH9AgaJpZM4G8ASP .

-- Carl K

[MaZderMind]

@danimo said Sidenote: we have seen high levels of interrupts (see itop). My theory is that they result from the de-/interleave-elements and the resulting higher number of queue-elements required for the multi-audio setup. I think this might get better when we would incorporate the GstInterpipe-Elements, which can handle multiple audio streams natively. I'll document my current findings in #58 and would encourage to continue this discussion over there.

[SonnyWalkman]

When do you think the RidgeRun Interpipes should replace inter tcpip connections?

[derpeter]

this thread is kind of outdated. The pipline was rewritten in the meantime and we have no interpipes anymore. Currently this also means we have no recoonects on TCP inputs which we hope to address by SRT inputs. Can you describe shortly your usecase for the TCP sources, i would love to have requirements for future dev

[SonnyWalkman]

In my project, i've been successful in implementation the use of the fallbacksrc plugin (from the rust plug-ins). Now on a loss or dropped connection, a video image (uri) is displayed until the source is reestablished. The plugin decodes any URL including http, rstp sources and possibly srt which I'm yet to test. Internally fallbacksrc uses the uridecodebin3 and fallbackswitch plugins with magical pad probe and other pad related switching. Happy to share if your looking at adding less for more to voctomix.

[markvdb]

@SonnyWalkman Thank you for your comment. That fallbacksrc plugin might or might not help our headless tcp source use case at https://fosdem.org !

[SonnyWalkman]

No worries, I can post a code snippet. The only issue I have is when the main source drops and switches to fallback uri, I get warnings to notify that the main source uri is down on my cli from fallbacksrc. I need to workout how to silence the red warnings. I'm using http links on my local network with MuMuDVB as the source streamer. Intention was I could relocate the receiver to anywhere on the planet. I guess if it's a valid uri tcp://192.168.1.xxx:xxxx it should work?

I validate all input uri's that there available before spinning up the pipeline. I added sanity checks for even local files that they exists.. to save broken gstreamer pipeline. Currently, using ffmpeg script to reconnect using maktroska mux with tcpserversink.

I'm pulling in http MP4's from the interwebs which can be on and off and my gstreamer pipeline is yet to EOS. I've also made the queue times between elements/plugins variable as a config setting to adjust internal memory resources. I'm looking to decouple a slave pipelines from the main for streaming restarts.

The rtmp2sink crashes the whole pipeline once the internet connection drops. A reliable method to catch the error before again firing up the stream? (Pad probe?) I'm looking for a reliable way to handle the error, disconnect rtmp2sink from flvmux then reconnect rtmp2sink after checking the domain is ping-able.

I hope for a property like restart-on-error to be added to rtmp2sink one day? Save some code and headache's. Has anyone implemented a reconnect on error for other sinks?