The VideoLAN Forums

Hi Folks.
I have an app which is built with libVLC, accessing the standard installed libvlc-dev libraries, plug ins, headers etc on Ubuntu Linux.
My app generally works perfectly, and its mostly there to receive UDP streams and convert to something else.

However, I am having a really weird issue in a specific mode, and so far I have invested around 30 development hours in trial and error trying to solve it - and I am hoping some VLC genius here can unlock the puzzle.

It revolves around http:// based URL sources. Typically for HLS, but the same issue happens with any http based source.

IMPORTANT: If I launch my app in terminal, *everything* works perfectly (including http streams). However, if I 'sublaunch' the same app with the same launch parameters from my parent process using fork() and then execv(), it fails to play any http based streams (although things like UDP do still work perfectly).

I have checked the obvious things like ensuring the VLC_PLUGIN_PATH is set correctly, and I have exhaustively compared all other environment variables in the 2 launch states, without finding anything obviously related.
After enabling full logging, I can see there is a glaring difference during the url opening process - and it seems something is amiss when evaluating plug in suitability.

In Terminal Launch:
looking for access_demux module matching "http": 20 candidates
no access_demux modules matched
creating access: http://...snip....myfeed.m3u8
looking for access module matching "http": 28 candidates
resolving ..snip....myfeed
outgoing request:
and the stream plays fine

However, when forked, and execv, I see the following:
looking for access_demux module matching "http": 40 candidates
no access_demux modules matched
creating access: http://...snip....myfeed.m3u8
looking for access module matching "http": 56 candidates
and it sticks right there and does not ever even make an http call out.

Of course the odd thing which I hope may be a clue is that the forked environment finds twice as many candidates when matching. However, it fails to complete the http access stage, and goes no further.

This is driving me crazy, and I have given up 5 times so far, only to come back for another try. However, I have exhausted what I can discover via logging, and I am really hopeful a VLC developer here might be able to point me in the right direction.

Many thanks for any ideas, tips, gut instincts or whatever.

Thanks !

Stating the obvious here, but fork-then-exec is essentially the only way to start LibVLC. Typically the shell or the launcher does it, rather than the LibVLC application, but that's all.

So the distinction that you're making does not make much sense. In turn, it's impossible to say anything about it other than that you're probably looking at the wrong thing.

Thanks for your comment Remi. I too am baffled, but I have presented the evidence as found, after an exhaustive analysis - clearly there *is* another variable and that is what I seek.

To help here -Could you speculate on what in the launch style / environment could account for one style yielding :
looking for access module matching "http": 28 candidates
and another yielding :
looking for access module matching "http": 56 candidates

This is the only clue I have to follow, so some visibility on what drives this process would be enormously helpful to finding the answer

Many thanks for any constructive input you can offer

Please share an MCV as well as full logs

Please share an MCV as well as full logs

Thank you mfkl

With the possibility of analysis of the issue by VLC developers, we would be very happy to do this. Will work on this today

SOLVED:
Whilst preparing an MCV of the problem, we found work/nowork conditions which eventually led to the discovery of the problem:

In the parent app, we happen to be calling:
signal(SIGCHLD,SIG_IGN);
at some point before the fork(). (so this is inherited by the child presumably)

In this condition when forked and execved libVLC cannot work with http sources. There must be some behaviour which relies on SIGCHLD in VLC's http handling.

We could solve the problem either by removing
signal(SIGCHLD,SIG_IGN); from the parent,
or by adding
signal(SIGCHLD, SIG_DFL); to the child libVLC app.

Once we do this, libVLC behaves as expected.
Many thanks for your feedback.

Geez. The third paragraph of the libvlc_new() documentation literally starts with

On POSIX systems, the SIGCHLD signal must not be ignored,