Octave won't run ffmpeg commands

A former version of RH Enterprise 5 running Octave would allow my program to
create "movie files" such as avi's etc. using ffmpeg. When my admins updated
to a newer version of RH Enterprise octave no longer created the movie
files. I had the admins install ffmpeg but still the problem persists and
the admins are no help. Should I edit my .bashrc or .cshrc files to set the
path for ffmpeg?

B R

Not sure how you are running ffmpeg from Octave. Calling system ("ffmpeg ...")? If so, then yes, adding the location of ffmpeg to your path would be useful if it’s not already there. Or include the path in the system call.

In any case, if you are trying to make animations or videos, look at the video package ( pkg install -forge video; pkg load video ) to see if it can do what you want.

1 Like

Which version of Octave do you use and how was it installed? Is it running inside a container (docker, snap, appimage, …)?

Basically the person who created the code built a function that builds avi files from image files that are created during code execution. While I understand the rest of his code quite well I don’t have any experience with ffmpeg. The lines of code are as follows:

command = sprintf(‘ffmpeg -y -r 5 -i %%03d.%s -vcodec msmpeg4v2 -b 500k -acodec mp3 %s.avi’, image_format, filebase);
system(command);

In any case I’ll take a look at your suggested pakg and see if my admins will allow it on this system. Thanks!

Yes, creating static images with Octave and then running ffmpeg seems to be a pretty common activity. I’ve done that myself but never through a system call. Your command string has enough complexity that any change would cause silent failure. In addition to verifying the location of your ffmpeg, also do the following for defensive programming:

  • Display the command string without running it. Make sure that’s what you want.

  • Make sure that the current version of ffmpeg you have can accept all those arguments provided. Call ffmpeg from your bash prompt with the same arguments and see if it does what you intend.

  • Use [status, output] = system ("...") instead of just a blank call to system. That way you can at least know if something has gone wrong.

  • Read errors from stderr for whatever your calling through system. E.g. you can add 2>&1 or 2>/tmp/errfile and that way you can see error messages for each operation.

1 Like

Initially version 3.03 was installed on RedHat 6 and the ffmpeg avi file worked fine. Again the code was written by someone else and I have no experience using ffmpeg with or without Octave. Recently my admins upgraded to RedHat 7.9 and Octave no longer worked at all. I got them to update Octave to version 5.2.0 which allowed Octave to work properly. However the Octave code I am running no longer created the avi files which uses ffmpeg. I checked and found fthat fmpeg was not installed so I had the admins install it (version 4.4). It appears to be a standalone version installed to my home folder. After installation I rebooted and tried the Octave code but it still wouldn’t create avi files. Thus my question on adding the path in .cshrc to assure Octave “knows” where to find ffmpeg files it needs. Octave is run from the command line on this machine.

Move ffmpeg into $HOME/bin

Thanks. I got my admin to install ffmpeg into the same “bin” folder Octave runs from. That may have fixed it. Unfortunately I have another issue with “gl2ps_print: support for gl2ps was not available when Octave was built” as an error during execution of my program. I got a new Linux box between uses of my program and they may not have installed everything needed on the newer machine for Octave to be able to run my program correctly. My admin installed gl2ps but no effect so far. He may have to rebuild Octave or install a newer version if one exists.

All of my issues have now been resolved. My admin recompiled Octave 5.0.2 (latest version allowed on this machine) with the proper additional gl2ps and gl2ps_print included and now everything works correctly. I am pretty sure putting the ffmpeg executables in the “bin” directory was also required for success.

Thanks to all of you who helped suggest fixes. I couldn’t have had my admin get it corrected without you.