Transcoding failure using presets

Using the same dev (no reinstall) - same behavior. I see the dev is still dated 12/5 - have you changed it? Should I reinstall? Thanks!

Thanks, heshan - in this case, though, it doesn't look like there's a transcoding issue; the error looks like it has to do with overwriting an mp4 file:

>File 'sites/default/files/videos/converted/[video].mp4' already exists. Overwrite ? [y/N] Not overwriting - exiting

I'm also unsure about enabling multiple presets, either - but I'll experiment more here and start with one.

I'll try encoding via command line tomorrow and see if I can track this down further; thanks for your help!

@charlie836: I think this is actually would be a separate issue: "Video problem with FileField Paths" - I'd open up a separate thread to help keep track of it, but that's just me. I'm therefore reopening the issue, if you don't mind, heshan - there's a lot more going on here, as you'll see.

Getting back to the original topic, I invoked the preset5_mp4 command via command line - here's the issue:

The command uses two-pass encoding, so ffmpeg needs permission to overwrite the mp4 file generated after the first pass in order to generate the final output file. If you run the command manually, all you need to do is hit "y" at the prompt and ffmpeg will complete the transcription successfully.

AFAIK, the module needs to deal with this, or two-pass encoding won't work.

Digging around, I was able to figure out how to modify the FFMPEG command so that it doesn't require the overwrite file confirmation:

Pass 1: ffmpeg -y -i [video_source] -an -pass 1 -vcodec libx264 -vpre slow_firstpass -b 500k -threads 0 -f mp4 /dev/null

Pass 2: ffmpeg -y -i [video_source] -acodec libfaac -ab 128k -pass 2 -vcodec libx264 -vpre slow -b 500k -threads 0 -f mp4 [output_file.mp4]

Via command line, this works great - I generated a 1.9mb output file from 19.5mb h264 mov source... and the results are spectacular. Yowsa!

There's another issue here, though: the two-pass encoding generates a .log and a .log.mbtree on each pass, which the Drupal process doesn't seem to allow. FFMPEG fails with the error message "Cannot read file 'ffmpeg2pass.log': No such file or directory Error reading log file 'ffmpeg2pass.log' for pass-2 encoding"

That's one part of it. The other part is that once the log file generation issue can be solved, you still have all those files hanging around after transcoding - you'd want to delete them. Digging around further, I think there may be a relatively simple solution here:

http://e-mats.org/2009/10/supporting-2-pass-parallel-encoding-with-x264-...

So to sum up, there needs to be a three-step solution to two-pass encoding:

1. Modification of the command as described above

2. Allow generation of the required .log files in the right (temporary) directory

3. Cleanup of the log files afterwards

In the meantime, I'm using '!cmd_path -i !videofile -acodec libfaac -ab 96k -vcodec libx264 -vpre slow -crf 22 -threads 0 !convertfile' in the preset and it seems to work OK.

IMO, getting two-pass encoding to work would be well worth it - the results are excellent. Hope this helps!

UPDATE: Got the above command to work once; I now get a "sites/default/files/temp/[video].mp4: Permission denied" error and mp4 transcoding fails. I don't know why there's a permissions problem; all folders are writable. So I guess it's back to Flash... ugh.

Using one-pass mp4 encoding with latest (12/05) dev build fails with "sh: line 1: sites/default/files/temp/[video].mp4: Permission denied" error. One-pass mp4 encoding with 12/04 dev build is OK.

I'm currently working on two new sites; when one site worked and the other didn't, I was able to track this down to the module version.

Summary (as of 12/08):

• It looks like a change that was introduced between the latest and previous dev builds breaks mp4 encoding.
• Two-pass mp4 encoding fails in any event - modified (one-pass) preset in above post seems to work.

Re: comment #8: I get the same result in the latest dev (12/11) without filefield paths - the video seems to convert successfully in the files/temp folder and when the module tries to move the converted video into the /files/videos/converted folder, the process fails with a "Permission denied" error in the log. This is with one-pass mp4 encoding as described in #9; with two-pass encoding, the process fails almost immediately with a similar error.

This looks like a permissions issue, although I've tried setting permissions wide open on the folders in question. Any ideas?

In my case, Flash hasn't been the problem; I similarly changed the preset to one-pass encoding and it worked fine. (As you'll see in the initial post, I mention that FLV is OK.)

My problem is with mp4 encoding, which consistently fails as described above. iPhones and iPads will not read Flash and mp4 x264 seems the most likely option to use a single file that will play across all major platforms.

Checking back in on this - to be succinct, the process fails when the system tries to move the processed mp4 file from files/temp (in my case) to the converted folder. The encoding process works fine (with one-pass), but when the system tries to move the file, it throws the "Permission denied" error (in the log) and the processed file (in sites/temp) is deleted.

BD video works fine encoding mp4, so it's not an FFMPEG thing. Been going nuts trying to solve this - any ideas? Thanks...

@bcobin, do you have permissions set to that folder for Apache user?

Thanks for checking in, heshan. Permissions are wide open (for testing purposes) on files, files/temp, files/videos, etc. All files/folders here are "user owned" (not www). I've been able to get one-pass encoding to work (with Alpha2, not with dev) - the big problem right now is HTML5, which is turning into a real adventure. See http://drupal.org/node/987236.

Once I can get videos to play across multiple platforms, I'll revisit the two-pass encoding issue, which is secondary for me at the moment, now that I can get files to successfully transcode. After HTML5 would be the file management issue in not properly deleting files, which may be related somehow to the two-pass issue. (?)

Working with latest dev (1/25) and this issue still isn't solved. I'll save the space of the full FFMPEG output, but here's the end:

[libx264 @ 0x1b412f00]kb/s:2536.46 sh: sites/default/files/temp/test_vid.mp4: Permission denied

I will take a moment, if I may:

The site is now on a production server, so it's nothing to do with my development sandbox. The fact that I'm seeing this now on two different, well-configured systems means that it's not me - there's something seriously wrong that has yet to be addressed.

I don't mean to sound unappreciative here; I'm aware that the Video project represents an enormous amount of work, from which the entire community will benefit. And I also realize that most of the work has been going into a D7 version, which will then be backported, as I understand it. But I've been trying now for nigh on two months to try to get Video to work as advertised, without success.

I'd have to say that at this point, the Video project looks to me more like an effort to find co-developers more than a real solution; see a post like http://drupal.org/node/989266 which is clearly an appeal for development help. Regarding the post I'm referring to, deleting the associated video when the node is deleted is very basic (and expected) functionality, not something that should be handled down the line at some point. I'm not harping on this specifically; I merely bring it up because I believe it's demonstrative of the fact that the project is very incomplete at this point and that, in it's current stage, is unlikely to work unless a user has the coding skills to get into some serious development.

Reaching out for collaboration is great, and is what the Drupal community is all about. And I applaud heshan.lk for doing it, and for all the work he's doing here.

However, representing Video as a working project at this point, I feel, is off the mark. It should be more like, "If you have coding skills and want to assist in the development of Video, jump in - otherwise, keep your eye out for the new release version, expected in _____." I am aware that the project is in "Alpha," and what that means, but many if not most users will end up tearing their hair out if they try to use it as the project curerntly stands.

I don't believe it's too much to ask of a developer to verify that a module actually works before posting it. And if certain functionality is lacking, hey, that's OK too, as long as it's well-documented. But 8,543 installs at this point for something that doesn't really work represents a mind-boggling amount of wasted time by a lot of people in verifying that they're not doing something wrong.

I am happy to help in any way I can. And, again, I realize what an enormous task this is and that we owe heshan.lk massive gratitude for taking it on. I would only ask for more responsiveness here on the development side, especially when it comes to major issues like the permissions thing, which is a total show-stopper.

Please take this in the right spirit - I am really only trying to help. I wish I had the coding skills to help out more, but we all do what we can... Hoping that all this can get resolved soon and, once again, a big (if moderated) "thank you!"

Just to stay on topic, this is a file permissions issue when it comes to mp4 encoding - Flash does you no good if you want your videos to play on iPhone or iPad. Two-pass encoding works fine with Blue Droplet Video, so this isn't something generic to FFMPEG or my installations; it's likely something in the module code that's not properly setting file/folder ownership and/or permissions. As such, I think it shouldn't be too difficult to track down - I just wish that I could, and get on with it.

For us Drupalistas, having videos be unable to play in Apple devices is pretty embarrassing, IMO - hoping heshan.lk can help save our bacon here!