videoIO Toolbox for Matlab

Did you run videoIoSysInfo after the setenv call, or before it?

Don't worry about the "is not fully compatible" messages right now. It's important information to know as a user, but it's presented poorly in the current version. I'm slowly working on presenting it better. The basic point is that the underlying codecs are not required to be correct...they can do things like guess the right file location when you ask it to seek to a specific frame. They can also decode the exact same same frame differently depending on things like past seeks and its guess as to how much of a hurry you are in.

Did you get any error message from the ffmpegDirect plugin? It would be very helpful. If it's crashing and killing Matlab, you might be able to run Matlab without a GUI so you can still see the messages. On linux, you can launch Matlab via "matlab --nodesktop"

I'll have to try to figure out why videoIoSysInfo is dying. Do you know what version of Matlab you have?

The two plugins have exactly the same backend, but they are built differently and have a different communication protocol with Matlab. ffmpegDirect is built the way one would normally build a MEX function. Matlab calls a specially-named C++ function called "mexFunction", which eventually calls the ffmpeg libraries. Everything is bound up together in a shared library, the MEX function (i.e. the *.mex* files on a Mac are really *.dylib files with renamed extensions). ffmpegDirect is technically the most efficient way to run videoIO.

I created the ffmpegPopen2 plugins a while ago because I kept running into a few issues. First, from time to time, ffmpeg has been buggy and could crash an application, especially when one uses the subversion version instead of the official releases. The other problem is that ffmpeg and libraries it relies on are built with the system's gcc, but Matlab was built with its own version of gcc. Sometimes this causes nasty conflicts when you try to load a shared library built with one version of gcc into an application built with a different version of gcc that's incompatible (gcc makes breaking changes every few years). In both cases, a solution is to have a very thin shared library act as the MEX function and then build a separate full-fledged executable to do the real work. The MEX function launches the backend application and communicates with it through a pair of pipes. Pipes are basically fake file handles...the MEX function writes to a fake file handle and the backend reads commands from that handle whenever they show up. popen2 is the system call to start an executable and grab the pair of pipes (one for reading, one for writing). If a bug in the backend (either my fault or ffmpeg's) causes a crash, then the server app dies, but Matlab keeps on ticking. Also, the two versions of gcc basically only need to be compatible enough to successfully call popen2 and handle read and write operations properly. The downsides of the popen2 architecture are that it's slightly slower (but not enough to notice) and when the backend crashes, it's hard to get error messages out of it...the backend sends them, but sometimes it dies and shuts down the pipes before the MEX function has a chance to read them.