Long transcode fails on last preset

As we can see, the files table thinks the video file is in the files/video/original directory

mysql> select * from files where fid=122039;
+--------+-----+---------------+-------------------------------------+-----------+-----------+--------+------------+
| fid    | uid | filename      | filepath                            | filemime  | filesize  | status | timestamp  |
+--------+-----+---------------+-------------------------------------+-----------+-----------+--------+------------+
| 122039 |   1 | vwfl-2011.mp4 | files/videos/original/vwfl-2011.mp4 | video/mp4 | 658217696 |      1 | 1325028562 |
+--------+-----+---------------+-------------------------------------+-----------+-----------+--------+------------+

There is 49G free on / and 683G free on /home the drupal file system /usr/share/drupal6/files is on /

One thing I'm curious about is that the output from ffmpeg is being captured into memory. It will generate a lot of output since ffmpeg continuously spews out a line for frames that it is processing. I'm doing another test with -nostats command line option in the presets.

It looks like something did go wrong with the last transcode:

sh: line 1: 18177 Segmentation fault nice -n 19 /usr/bin/ffmpeg -y -i '/usr/share/drupal6/files/videos/original/vwfl-2011.mp4' -b 384k -vcodec mpeg4 -acodec libfaac -ac 2 -ar 44100 -ab 64k -vf "scale=gte(dar\,480/320)*480+lt(dar\,480/320)*(320*dar):-1,setsar=1:1,pad=480:320:(ow-iw)/2:(oh-ih)/2" -crf 22 '/tmp/vwfl-2011.mov' 2>&1

and the following file was left behind

# ls -lhrt /tmp/vwfl-2011.mov 
-rw-r--r-- 1 apache apache 189M Dec 28 04:28 /tmp/vwfl-2011.mov

The file should be about 334M when transcoded with this preset. I'll do some investigating on the transcode failure.

However, my system seems to be in an inconsistent state:
1. The status is set to 5 and not to the error state
2. The files table has the wrong file name
3. No watchdog entries were written for this preset

Also it looks like video_ffmpeg.inc checks to see if the output file exists with a filesize != 0 to determine if ffmpeg was successful. This doesn't seem safe if either ffmpeg or qt-faststart fail after partially writing their output files.

The video being moved back is weird but there are no errors logged by drupal and not even the debug letting us know that we're running the ffmpeg for the preset that is failing.

Cron is invoked via
/usr/bin/wget -O - -q http://mydomain.com/cron.php

I tried using drush video-scheduler but as I pointed out in a different bug, that isn't working.

I ran the exact ffmpeg from the command line on the same machine and it completed without segfaulting.

I ran the test with "-nostats" on my ffmpeg commands and it transcoded all three presets. The files were left in the original and converted directory but the database was not updated. I wonder if the database connection is getting disconnected after such a long period (10+ hours) without any activity?

I ran the wget by hand and it returned long before the transcode failed.

I'm using mysql with the default timeouts which are 8 hours for wait_timeout and interactive_timeout

Variable_name	Value
connect_timeout	10
delayed_insert_timeout	300
innodb_lock_wait_timeout	50
innodb_rollback_on_timeout	OFF
interactive_timeout	28800
lock_wait_timeout	31536000
net_read_timeout	30
net_write_timeout	60
slave_net_timeout	3600
wait_timeout	28800

ffmpeg 0.9.2

I'm uploading mp4's that are in the format I want so I'm avoiding lengthy transcode by just doing
'!cmd_path -y -nostats -i !videofile -vcodec copy -acodec copy !convertfile'

Next up is webm

        '!cmd_path -y -nostats -i !videofile -pass 1 -passlogfile /tmp/ffmpeg2pass -threads 8 -vcodec libvpx -b 720k -g 120 -level 216 -profile 0 -qmax 42 -qmin 10 -rc_buf_aggressivity 0.95 -vf "scale=min(iw\,!width):ow/dar,setsar=1:1" -an -f webm /dev/null',
         '!cmd_path -y -nostats -i !videofile -pass 2 -passlogfile /tmp/ffmpeg2pass -threads 8 -vcodec libvpx -b 720k -g 120 -level 216 -profile 0 -qmax 42 -qmin 10 -rc_buf_aggressivity 0.95 -vf "scale=min(iw\,!width):ow/dar,setsar=1:1" -acodec libvorbis -ac 2 -ab 96k -ar 44100 -f webm !convertfile'

And finally mov
'!cmd_path -y -nostats -i !videofile -b:v 384k -vcodec mpeg4 -acodec libfaac -ac 2 -ar 44100 -ab 64k -vf "scale=gte(dar\,480/320)*480+lt(dar\,480/320)*(320*dar):-1,setsar=1:1,pad=480:320:(ow-iw)/2:(oh-ih)/2" -crf 22 !convertfile'

The mp4 of course is fast because its just doing a copy. The webm is where the time is spent. My server is really old and is running on an AMD Athlon XP 3200+.