I have several test files (mov and wmv) that transcode correctly when I run them through the ffmpeg_wrapper tester, but not when ffmpeg_converter tries to do them on cron.

When I upload a file into a file field, it is correctly added to the job queue. When I run cron, I get errors. The job is removed from the job queue, but when viewing the node, it still says [filename] is waiting to be converted. The logged errors are always:

* warning: Division by zero in /path/to/drupal/sites/default/modules/ffmpeg_converter/ffmpeg_converter.module on line 1051.
* warning: filesize() [function.filesize]: stat failed for /tmp/india-RH.flv in /path/to/drupal/sites/default/modules/ffmpeg_wrapper/ffmpeg_wrapper.module on line 798.

India-RH starts as a quicktime mov, so the reference to /tmp/india.RH.flv indicates that the code is looking for the output file, but it's not there. Permissions on /tmp are wide open, of course. I'm assuming that the division by zero is due also to the file not being there.

As I mentioned, this file converts correctly (with the same encoding settings) when I process it with the test feature of ffmpeg_wrapper, so I'm a bit baffled why it fails when done by the converter module. Anyone have an idea what's going on here?

Thanks!
G

Comments

zoo33’s picture

zoo33 commented

This is a tricky one. I think you're diagnosis is correct – it probably attempts to convert the file but then for some reason the output file isn't there.

You could try the debug setting at admin/settings/ffmpeg_converter/debug. You should see messages in the log telling you exactly what command was used for the next conversion you run. If you try and run the same command in a terminal, maybe you'll find something.

If it turns out that this isn't some strange irregularity, then perhaps there needs to be better error handling in the conversion code, so you get something friendlier than the messages above.

gnosis’s picture

gnosis commented

Thanks for your quick reply! I didn't see that debug option up there, and it did lead me to a [hack] solution.

Looking at the debug output, I found:

FFmpeg was invoked with these options:
-i 'sites/default/files/media/C4.wmv' -acodec libmp3lame -ar 44100 -ab 64k -s 0x0 -padtop 0 -padbottom 0 -b 250k -r 25 -y '/tmp/C4.flv'

Conversion of /tmp/C4.flv failed unexpectedly. The command was:
-i 'sites/default/files/media/C4.wmv' -acodec libmp3lame -ar 44100 -ab 64k -s 0x0 -padtop 0 -padbottom 0 -b 250k -r 25 -y '/tmp/C4.flv'

Note the "-s 0x0" part of the command. I thought this was because I had checked the "Use advanced settings" for video, but I left the "Video frame (Other) size:" field blank. But when I filled that field in with 320x240, the command run on the next test was unchanged. It still ran with "-s 0x0", rather than "-s 320x240" as I would have expected.

In an attempt to just circumvent this part of the process (I don't want conversion to ever change the size), I simply hacked the ffmpeg_converter_convert function and commented out the lines where -s was added to $options[]. After that, success!

The exact same -s issue happened with the three generated snapshots after successfully converting the video file. I did the same $options hack to the ffmpeg_converter_create_snapshot function and those succeeded as well.

So....I'm not sure what the takeaway from all of this is. Obviously there's something funny going on with the "Video frame (Other) size" field being ignored. But I would also say that this field should be allowed to be blank, or provide a default that does not try to change size.

Thanks again! Even with these issues, this module (together with ffmpeg_wrapper) have surely saved me a lot of time.
-G

zoo33’s picture

zoo33 commented

So when no size is specified, the -s option should definitely be skipped altogether. That's probably something that's simply been overlooked.

Did you say that you tried specifying a size and it still put "0x0" as the -s option? That suggests that ffmpeg_converter_get_padded_size() doesn't do its job properly.

It would be great if you or someone else could determine what cases work and what don't.

* Frame size specified, custom command used
* Frame size empty, custom command used
* Frame size specified, custom command not used
* Frame size empty, custom command not used

Also, is the result consistent between different file types and different setups?