two pass encoding fails if webserver (ffmpeg command line) cannot write to drupal basedir

Perhaps the better solution would be to cd the php env to /tmp, build the file paths to the videos to be transcoded based on their (complete) location.

subscribe

subscribe

I just ran into this error. My ffmpeg commands work via the command line but I am running into this error when using the module. If I can provide any further information, please let me know.

Cheers,

Antoine

I'm not sure what happened, but in debugging this and changing code around, encoding started working. The problem is that when I created a patch file of my changes and reverted the module back so I could apply changes individually to determine which change was the fix, the module continued working with the old code??? I am outlining steps I performed in between code changes and attaching a patch with the changes that I had in place when it first began working.

There are possibly 3 commands being executed that generate the output in the issue; the first pass encode, the second pass encode and the qt-faststart (if you have that enabled). Your commands may also be preceded by the 'nice' command if you have that option enabled as well.

The first thing I noticed is that we are not seeing output from the first command due to a bug in the module.

The second thing I noticed is that even when the first and second commands fail, the qt-faststart command was still being executed on a 0kb file resulting in the 'last atom in file was not a moov atom' section of the output.

The last thing I noticed was an extra whitespace character between the command and the output redirection '2>&1'. This is the only command related fix that I made, and I'm not even sure it affects anything.

All of the above issues are fixed in the attached patch. In addition to these changes, I ran all three commands, first the commands by themselves minus the preceding 'nice' command and succeeding '2>&1' output redirection, and second exactly as they were being run in the module below:

nice -n 19 /usr/local/bin/ffmpeg -i 'sites/default/files/videos/original/test.flv' -an -pass 1 -vcodec libx264 -vpre baseline -b 500k -threads 0 '/tmp/test.mp4'  2>&1
nice -n 19 /usr/local/bin/ffmpeg -y -i 'sites/default/files/videos/original/test.flv' -acodec libfaac -ab 128k -pass 2 -vcodec libx264 -vpre baseline -b 500k -threads 0 '/tmp/test.mp4'  2>&1
nice -n 19 /usr/local/bin/qt-faststart /tmp/test.mp4 sites/default/files/videos/converted/test.mp4  2>&1

Hope this helps resolve this issue.

Cheers,

Antoine

Ok... ignore my post in #4, I have not idea why it decided to start working on that machine.

Problem:
When performing a 2 pass encode, during the first pass, ffmpeg attempts to write log files that it will need for the second pass to the current working directory (Drupal's base directory), but it does not have permission to do this.

Solution:
Temporarily change the working directory to Drupal's temporary directory when running ffmpeg.

Possible issues:
According to some research, some (possibly all) versions of ffmpeg use the same log file when multiple 2 pass encodings are performed simultaneously and the -passlogfile option does not work with the libx264 codec. The only solution I found was to run each ffmpeg command from a separate directory where the log file will be created. If this turns out to be an issue, we could create a temporary folder using the files name to run ffmpeg from.

Patch attached.

Cheers,

Antoine

Patch without the chmod!

Cheers,

Antoine

Patches in #5 and #6 introduce a bug where the converted video's URL was being stored in the database using the real base path, i.e. the machines physical path. A new patch is attached that fixes this.

Cheers,

Antoine

In patch #7 I was changing the current directory too early, so Drupal was referencing relative paths from temp and causing some errors. A new patch is attached that fixes this.

NOTE: The video module stores a relative filepath to the video, which it should in case the Drupal path were ever to change, i.e. if a site was moved to a new server, we don't want videos to break. Because we are changing the current directory before running the ffmpeg command, we need to make sure all paths in the command are absolute. I have fixed the relative paths that were being executed during my conversions, but there may be others we need to fix.

Cheers,

Antoine

Thank you for this patch #8 works for me!

Since I made this changes, my videos gets converted but the thumbnail procedure is brooken now. I can create the thumbs if I change to the website root in the console and manually try the thumbnail command it works, but not if I upload a video. Is this maybe a sideeffekt?

I'll try fixing this bug in 6.x-4.7.

You can just add -passlogfile /tmp/ffmpeg2pass to your ffmpeg command lines to tell ffmpeg where to put the passlogfile.

The problem is that libx264 (used for mp4 encoding) is not respecting that setting and uses its own two pass log file. The location of that file can only be overriden starting from ffmpeg 0.7, if I'm not mistaken.

Could be. I'm running 0.8.5 on Fedora 16 and -passlogfile works for me with libx264.

Can someone specify an example?

I have tried to use -passlogfile tmp/filename in the transcoders/video_ffmpeg.inc

and in all the presets inc files, it just ignores me. I am using ffmpeg 0.8.5 in os x and on redhat and cent os.

I used the webm preset commands which has the passlogfile very early in the command.

The patch above does work for me as well... BUT it does kill the auto thumbnailing which kills the joy for me using the patch, so I'd rather just do this.

I got it, I looked at the actual ffmpeg site's examples... so in the preset files and the transcoder/ffmpeg file I put -passlogfile as near to the end as possible right before the file variable...

so in the video_preset/html5_mp4.inc file:

'!cmd_path -i !videofile -an -pass 1 -vcodec libx264 -vpre slow_firstpass -b 500k -threads 0 -passlogfile /tmp/ffmpeg2pass !convertfile',
'!cmd_path -y -i !videofile -acodec libfaac -ab 128k -pass 2 -vcodec libx264 -vpre slow -b 500k -threads 0 -passlogfile /tmp/ffmpeg2pass !convertfile'

I don't think the position of your passlog file makes a difference but in your first comment you had tmp/ffmpeg2pass instead of /tmp/ffmpeg2pass

I have committed a change to 6.x-4.x so ffmpeg commands are executed in a new temporary directory. There is no need to pass log file paths anymore.