FFMpegCore icon indicating copy to clipboard operation
FFMpegCore copied to clipboard

Error operating with streams

Open ornic opened this issue 1 year ago • 4 comments

This code (as far as I understand) should produce two identical outputs, since we analyze the very same file.

UPD: file AFAIK should not produce errors

var analyzerOptions = new FFMpegCore.FFOptions
{
    LogLevel = FFMpegCore.Enums.FFMpegLogLevel.Verbose
};

var jsonSerializationOptions = new JsonSerializerOptions { WriteIndented = true };

using var fileStream = File.OpenRead("BAD.mp4");

var fileAnalysisResult = await FFMpegCore.FFProbe.AnalyseAsync(fileStream, analyzerOptions);
Console.WriteLine($"Analysis STREAM:\n{JsonSerializer.Serialize(fileAnalysisResult, jsonSerializationOptions)}");

fileAnalysisResult = await FFMpegCore.FFProbe.AnalyseAsync("BAD.mp4", analyzerOptions);
Console.WriteLine($"Analysis FILE:\n{JsonSerializer.Serialize(fileAnalysisResult, jsonSerializationOptions)}");

But the first (and only first) result have errors: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x55d9b146d2c0] stream 0, offset 0x81c: partial file

I have an example built using Debian 12, .NET 8, FFMpeg 5.1.6 and FFMpegCore 5.1.0 here: https://github.com/ornic/FFMpegCore-debian-pipe-bug

ornic avatar Dec 17 '24 22:12 ornic

Are you expecting errors (assuming as much from the BAD.mp4 filename)?

tiesont avatar Dec 18 '24 07:12 tiesont

No, this name is just a result of many hours of testing 😿

Console ffmpeg / ffprobe work well with it. All major versions: 5, 6 and 7. Streams on windows (while debugging in Visual studio) also worked. But in swarm we got errors, so I began to dig.

I also tried Ubuntu instead of Debian, but streams not working there as well with ffmpeg 6.x

ornic avatar Dec 18 '24 07:12 ornic

I'm a bit too old school to know for sure what a "swarm" is, but assuming it means there could be multiple processes running the same action, you might be running into the InvalidOperationException generated by the Pre() method here: https://github.com/rosenbjerg/FFMpegCore/blob/main/FFMpegCore/FFMpeg/Arguments/PipeArgument.cs

Basically, the FileStream can't be opened again, since it's already open. Suppose one troubleshooting step would be to copy the stream into a MemoryStream and pass that instead. I know MemoryStream works for me, but I'm also not (yet) dealing with scaling to a server farm / microservices architecture, so...

Pipes are handled differently on Unix-derived OSes: https://github.com/rosenbjerg/FFMpegCore/blob/main/FFMpegCore/FFMpeg/Pipes/PipeHelpers.cs , so that's another possibility - might be helpful to note the version(s) of .NET and/or Mono installed.

(Quick caveat: while the comment headers indicate that I'm a contributor, I've mostly just committed some documentation, so don't take anything I suggest as "this is how FFMpegCore works")

tiesont avatar Dec 18 '24 08:12 tiesont

I'm a bit too old school to know for sure what a "swarm" is

It is a cluster of docker containers. Child version of Kubernetes.

but assuming it means there could be multiple processes running the same action, you might be running into

Nope. Unfortunately.

I tried all sorts of tricks with streams, but even "array stream" of MemoryStream produces the same error.

Pipes are handled differently on Unix-derived OSes

I suppose that is the root of the problem here, but I don't have enough time for self-education and digging this root out. :(

Not all files produce the same problem, so, I suppose, there are some "magic byte sequence" that brokes the pipe.

might be helpful to note the version(s) of .NET and/or Mono installed

Thanks, I add that to the original post. In truth, I specifically made an example repo with one-command run and very simple code to minimize the work of someone with enough attitude to weed the problem out.

ornic avatar Dec 18 '24 08:12 ornic

The problem is most likely that ffprobe needs to seek to the end to read the MOOV atom and then back to the beginning to analyse the videostream content. This is not possible with pipes See https://stackoverflow.com/a/71195764 for more context

rosenbjerg avatar Oct 27 '25 19:10 rosenbjerg

FFmpeg 8.0 don't have this issue, fortunately. May be they worked out the proper way to use pipes :)

ornic avatar Oct 27 '25 19:10 ornic