The log says (several times):

C:/wwwroot/wamp/www/terra/assets/video_thumbnails/section1.jpg [2009-10-20 13:06:36] 'ffmpeg' is not recognized as an internal or external command, operable program or batch file.

BUT as I said, FLV::echo_ffmpeg_test() returns true.

The echo_ffmpeg_test() function is certainly not airtight. All I can do is check for termination codes from the command, and I don't know how reliable that is. So you're sure you can run ffmpeg commands from your command line? If that's true, I have seen something like this before.

What I have had to do before, when a user can execute from the command line successfully, but PHP cannot, is provide an absolute path to the ffmpeg executable. You'll see in the FLV class there's a method (i think) called set_ffmpeg_root(). You can set that to /var/dir/dir -- wherever your ffmpeg executable file lives. I have seen that work with pretty good success.

You're on the right track, though, if you can see the results of your commands in the ffmpeg_log.txt. Only a matter of trial and error before you get those running right and that should fix all of your issues.

All right. Yes, I can run commands from the text file on the server; but I am getting PERMISSIONING errors! For example, the following command:

/usr/home/gfisher/assets/Uploads/section1.flv -an -s 640x480 -ss 1 -an -r 1 -vframes 1 -y -vcodec mjpeg -f mjpeg

...Resulted in a "Permission denied error". The people maintaining this server said they will not support ffmpeg so I'm not sure I'm going to be able to get this changed. I also asked them for the root path where it is installed so that I can try set_ffmpeg_root().

That's a drag! There are a lot of shared hosting providers that allow you to use it. If it's economy hosting, I can understand their position. It is fairly taxing on a CPU.

It does prompt me to come up with some better logic for determining whether ffmpeg is installed, because if the has_ffmpeg() command were running correctly, you would have at least known about it, rather than wondering why you're not getting thumbnails.

Regardless of the permissioning issue moving forward, I did a locate on ffmpeg and took a whack at where it is installed, and added the following to my _config.php:

FLV::set_ffmpeg_root("/usr/ports/multimedia/ffmpeg");

Then I ran the command again:

ffmpeg -y -i /usr/home/gfisher/assets/Uploads/section1.flv -an -s 640x480 -ss 1 -an -r 1 -vframes 1 -y -vcodec mjpeg -f mjpeg

And this is what I got:

$ ffmpeg -y -i /usr/home/gfisher/assets/Uploads/section1.flv -an -s 640x480 -ss 1 -an -r 1 -vframes 1 -y -vcodec mjpeg -f mjpeg
ffmpeg version 0.4.9-pre1, build 4718, Copyright (c) 2000-2004 Fabrice Bellard
  built on Oct 20 2009 12:23:28, gcc: 3.4.4 [FreeBSD] 20050518
[flv @ 0x280d2008]skipping flv packet: type 18, size 224, flags 0
[flv @ 0x280d2008]skipping flv packet: type 18, size 4121, flags 0
Input #0, flv, from '/usr/home/gfisher/assets/Uploads/section1.flv':
  Duration: N/A, bitrate: N/A
  Stream #0.0: Audio: mp3, 44100 Hz, stereo
  Stream #0.1: Video: 
ffmpeg: unrecognized option '-vframes'

Are we getting anywhere??

It appears we are. Can you research it and find out if that's only an option in some distributions or versions? if there's a different flag I should be using, let me know and I'll patch up the code. I know FFMPEG behaves differently depending on the linux distribution it's running on in some cases.

Hey UC.

Well we have some more information. I heard back from the tech at the hosting company. This is what he wrote to me:

"Is that the command you are attempting to run or is that the arguments that you are appending to an invocation of ffmpeg?  If the former is the case, that simply wouldn't work since section1.flv isn't executable which would return a Permission denied error.  

If the latter, this file appears to have been uploaded as the www user is the owner of the file.  If ffmpeg is attempting to manipulate the existing file in place, current permissions won't allow it since initial permissions on the file are only writable by the owner.  Obviously this will be an issue with all files uploaded via a php script to this directory."

Ever run into this one?

He continues:

"To fix it, the recommend solution would be to update the php script that uploads the document to change the permissions on the file to allow writing by the group, which would include the gfisher user(or change the umask before the file is writen in the script).  The other method would be to change the umask globally where needed to set permissions on files created when uploaded with the group write permissions.  If you prefer this method, let me know and I'll determine where this will need to be setup.  It would most likely include changing the class of the www user and/or setting the umask during the startup of Apache."

As far as OS, I am running FreeBSD 6.1-RELEASE-p3.

Thanks for stayin' with me here.

//Garrett

Seems promising. I'm just wondering why he thinks that an unrecognized flag error is resulting from a permissions problem. That doesn't make much sense. What happens if you set everything to 777? Can you run it then?