views:

94

answers:

4

when i do the following command into dos it will work fine

ffmpeg -f image2 -i frame%d.jpg -vcodec mpeg4 -b 800k video.avi

When I try to use the process class in c#, without the arguments, it loads ffmpeg in a console window then dissapears like usual. However, when I try to use the argument as I do above, formatted exactly the same...it doesn't work! ffmpeg still loads, however since the console window closes so fast I cannot determine what the error is :/

Process ffmpeg = new Process();
ffmpeg.StartInfo.FileName = path + "//" + "ffmpeg.exe";
ffmpeg.StartInfo.Arguments = " -f image2 -i frame%d.jpg -vcodec mpeg4 -b 800k video.avi";
ffmpeg.Start();

Any one know why this is? Why would the command work from dos and then fail to work using c# even when the arguments are exactly the same? I've used this method before for many things and never encountered this.

+6  A: 

Try fully qualifying the filenames in the arguments - I notice you're specifying the path in the FileName part, so it's possible that the process is being started elsewhere, then not finding the arguments and causing an error.

If that works, then setting the WorkingDirectory property on the StartInfo may be of use.

Actually, according to the link

The WorkingDirectory property must be set if UserName and Password are provided. If the property is not set, the default working directory is %SYSTEMROOT%\system32.

cristobalito
thank you, i set the workingdirectory property to match the same path as ffmpeg and works now
brux
+2  A: 

To diagnose better, you can capture the standard output and standard error streams of the external program, in order to see what output was generated and why it might not be running as expected.

Look up:

If you set each of those to true, then you can later call process.StandardOutput.ReadToEnd() and process.StandardError.ReadToEnd() to get the output into string variables, which you can easily inspect under the debugger, or output to trace or your log file.

Chris W. Rea
ye got my head stuck in this now...will keep ya'll posted
brux
+1  A: 

Make sure to use full paths, e.g. not only "video.avi" but the full path to that file.

A simple trick for debugging would be to start a command window using cmd /k <command>instead:

string ffmpegPath = Path.Combine(path, "ffmpeg.exe");
string ffmpegParams = @"-f image2 -i frame%d.jpg -vcodec"
    + @" mpeg4 -b 800k C:\myFolder\video.avi"

Process ffmpeg = new Process();
ffmpeg.StartInfo.FileName = "cmd.exe";
ffmpeg.StartInfo.Arguments = "/k " + ffmpegPath + " " + ffmpegParams
ffmpeg.Start();

This will leave the command window open so that you can easily check the output.

0xA3
ok im gonna try this it sounds like the way forward
brux
A: 

Not really a direct answer, but I'd highly recommend using LINQPad for this kind of "exploratory" C# programming.

I have the following as a saved "query" in LINQPad:

var p = new System.Diagnostics.Process();
p.StartInfo.FileName = "cmd.exe";
p.StartInfo.Arguments = "/c echo Foo && echo Bar";
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.UseShellExecute = false;
p.StartInfo.CreateNoWindow = true;
p.Start();
p.StandardOutput.ReadToEnd().Dump();

Feel free to adapt as needed.

Daniel Pryden
@Daniel: don't forget to add p.StandardError.ReadToEnd().Dump(); for those (rare) apps that write to stderr as well.
Tergiver
@Tergiver: Except that due to buffeting, calling ReadToEnd on one stream before the other can lead to a deadlock. Sure, it's unlikely to be an issue with most programs, but I figured that, for example code, it's better to leave something out than implement it incorrectly.
Daniel Pryden
I hadn't ever tried it that way, I asynchronously read both streams when redirecting a process. I see why you would give that simple example instead of a complete (asynchronous) one.
Tergiver