ArgumentOutOfRangeException MacOS

[haichay88]

Hi !
I try combine video and audio with code

string path =PipeHelpers.GetPipePath(PipeHelpers.GetUnqiuePipeName());
Console.WriteLine(path);
//client.DefaultRequestHeaders.TransferEncodingChunked = false;
var VideoStream = await client.GetStreamAsync(videoInfo.UrlVideo);
var AudioStream = await client.GetStreamAsync(videoInfo.UrlAudio);
var outputStream = new MemoryStream();

           await FFMpegArguments
              .FromPipeInput(new StreamPipeSource(VideoStream))
              .AddPipeInput(new StreamPipeSource(AudioStream))
              .OutputToPipe(new StreamPipeSink(outputStream), options => options.CopyChannel(Channel.Video)
       .WithVideoCodec(VideoCodec.LibX264))
      .ProcessAsynchronously(true, new FFOptions(){BinaryFolder="/usr/local/bin",TemporaryFilesFolder=path} );

public static string GetUnqiuePipeName() => $"FFMpegCore_{Guid.NewGuid()}";

    public static string GetPipePath(string pipeName)
    {
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
            return $@"\\.\pipe\{pipeName}";
        else
            return $"unix:/tmp/CoreFxPipe_{pipeName}";
    }

But it has error about path

ArgumentOutOfRangeException: The path '/var/folders/h0/y1h8qd857xx66dkmj685p8300000gn/T/CoreFxPipe_FFMpegCore_7f8ea927-b6d9-416a-9fde-88e685adaf25' is of an invalid length for use with domain sockets on this platform. The length must be between 1 and 104 characters, inclusive. (Parameter 'path')

How can set path is correct ?

many Thanks

[rosenbjerg]

I don't see how this library would come up with that path. Seems really weird to me

[instantiator]

+1, I'm afraid. I'm seeing a very similar issue on OS X Big Sur (M1 Macbook Pro):

The path '/var/folders/1c/wq9ptmb53k50bx9dpmh7j8jw0000gn/T/CoreFxPipe_FFMpegCore_411169d3-75c5-4bd8-a8e7-a2045a25540f' is of an invalid length for use with domain sockets on this platform.  The length must be between 1 and 104 characters, inclusive. (Parameter 'path')
Actual value was /var/folders/1c/wq9ptmb53k50bx9dpmh7j8jw0000gn/T/CoreFxPipe_FFMpegCore_411169d3-75c5-4bd8-a8e7-a2045a25540f.

I'm working with pipe input, as here:

await FFMpegArguments
    .FromPipeInput(videoFramesSource)
    .OutputToFile(path, true, opts => opts.WithVideoCodec(options.Codec))
    .ProcessAsynchronously();

Is there anything more we can do to help debug this?

[rosenbjerg]

Which versions of .NET and this library are you using?
And which platform are you on @haichay88 ?

[instantiator]

Which versions of .NET and this library are you using?

.NET 5.0, and FFMpegCore 4.5.0

[rosenbjerg]

I am suspecting it may be a bug in the dotnet runtime on MacOS, due to something with permissions. But that is just a guess. This library isn't producing that path, as can be easily seen in the snippet, so it seems the dotnet runtime is translating the path. Maybe due to the unix: protocol and/or something with permissions on MacOS.
Since I don't have anything running MacOS, I am unable to debug this issue.
But if either of you are interested and have time, it would would be awesome with a PR that adds an if (<IsMacOS>) block to GetPipePath, which builds a pipe path that dotnet on MacOS is happy with.

But if it is a bug in the dotnet runtime on (M1/ARM) MacOS, it may not make sense to try and support it
I am unsure if this problem is only

[instantiator]

While looking into this, I've identified another issue on my system (MacOS, Big Sur, MacBook Pro M1):

• ProcessStartInfo doesn't seem to be able to find ffmpeg or ffprobe from PATH with UseShellExecute = false.

See: instantiator/process-start-info-testing

I'm not sure why, and it seems more than happy to find other binaries, like docker. I'd like to figure that out as it'll help me to run the FFMpegCore tests without adjusting them all to provide absolute paths. (Perhaps I'm just missing something obvious?)

Once I've figured that out I'll get back to looking into what's wrong with the named pipe path. (From a quick scan of some docs, it seems like maybe named pipe paths can look like regular paths, or even just filenames without paths.)

[rosenbjerg]

Interesting finding. It may be related to whether something is in the user-specific PATH variable, or the system-wide one

[instantiator]

Today I realised that this applies to tests run through VS, but not from the dotnet CLI (which works as expected, and can find the ffmpeg binary).

It could well relate to the PATH from my shell vs. some more ubiquitous system wide PATH.

That would suggest, though, that the VS process that launches the tests doesn't have its origin in my shell, which is a bit unexpected.

I'm using zsh so I guess if VS launches some other default shell (bash maybe?) perhaps it wouldn't get to learn my amendments to PATH. I'll keep poking around.

(Sorry, I know this isn't even about the original issue, and I'm clearly using this thread to rubber duck the new problem. I'll definitely come back to the original path issue soon.)

[rosenbjerg]

@instantiator You could maybe try launching VS from your zsh terminal (if that's not what you're already doing). Maybe it has to do with how the "shortcut" starts VS

[instantiator]

Thanks that was today's TIL! Apparently, Mac GUI applications do not inherit environment variables defined in your shell profile. They can if you launch them with open from the terminal, though, ie.

open -n /Applications/<app-name>.app

Armed with that, I'll get back to thinking about paths. 🙂

[instantiator]

Did some experimentation and created a PR - however, as mentioned this still isn't working. It just clears the issue with the pipe name length: #286

I'm rather hoping you've seen this before, and might have some more ideas.

I couldn't figure out how to link the PR to this issue. That might be something you can do.

[rosenbjerg]

Closing this issue since the discussion continued on the PR