Despite different settings for format and different commands, I can't get ffmpeg_converter to create a thumbnail from a file field with a video (sourced from filefield_sources) in one CCK field and store in another CCK filefield. The error is always the same, below.
Conversion of /tmp/[filename].image2 failed unexpectedly. The command was: -i sites/default/files/[path to file field file]/[filename].mp4 -ss 12 -vframes 1 -s 640x480 /tmp/[filename].image2.jpg
I've tried mjpeg and doing explicit -f and -vcodec commands as well.
The input file is correct, the output doesn't seem to reattach to the field. Video conversion when uploading then storing to cck was fine after the last patch but this doesn't work. Thumbnails seem necessary.
/tmp is wide open.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | ffmpeg_converter.1-spaces.20111003.patch | 18.52 KB | iva2k |
| #11 | ffmpeg_converter.2-fixes.20111003.patch | 4.62 KB | iva2k |
| #11 | ffmpeg_converter.3-jpg.20111003.patch | 3.12 KB | iva2k |
| #8 | ffmpeg_converter-thumbnails-973110-8.patch | 1.64 KB | osopolar |
| #4 | ffmpeg_converter_973110_thumbnails.patch | 1.63 KB | zoo33 |
Comments
Comment #1
zoo33 commentedThere needs to be a way to create thumbnails, but I haven't actually tested that yet in 2.x. I'm not sure what may be wrong with the command above, but if possible you could do some testing on the command line and see if you can figure out a command that works. Then compare that to what FFmpeg Converter generates and report back.
For the record, there is a working implementation of thumbnail generation in
ffmpeg_converter_create_snapshot()in the 1.x version of ffmpeg_converter.module, but the idea in 2.x is that we shouldn't need a special function for this. That code might give some clues as to what options to use though.Once we figure this out, we should create a default preset for thumbnails.
Comment #2
mjvesper commentedI had used the 1.x branch, but since it entered the end-of-life area with no active maintenance and the 2.x branch became preferred I switched. Why commit to a dead horse.
But, that's the thing... Using the same commands from the command line work fine. It's the reason I submitted this issue.
There seems to be something in the code that is affecting the usage... Whether in this module or ffmpeg_wrapper. I'm not sure which since one piggybacks the other.
In terms of a default command to package on install, I can say that the size should default to the video size but be able to be customized, the amount should default to one (with the option of have multiple like the 1.x branch for views or carousel type styling) and the default time should be about 5-10 seconds (some videos are short). Imagefield support for using image cache would be ideal as well.
I did notice that the %filename wildcard seemed to not have any effect, hence the image2.jpg double extension.
Unrelated, the preset for H264 seems to be odd. It gives the revert option after install and when clicked does nothing.
Honestly, I would use media mover for a lot of this conversion and moving if I could, but there seem to be issues with PHP5.3 that make it unusable to me now. With a similar situation of one branch not stable and another branch started, I'm sure the development time is running lean.
Comment #3
zoo33 commentedThank you for the info. Let's consider this a bug then.
Comment #4
zoo33 commentedOK, so the problem is that it's not possible to select "jpg" as the output format. The list of available output formats that you can see on preset edit pages is built by FFmpeg Wrapper by sending a specific command to the ffmpeg executable. Apparently jpeg is not among those, although ffmpeg actually can convert to that format.
I worked around the problem by providing a default preset for thumbnails. That way I was able to specify "jpg" as destination format manually. Only problem is, if you edit this preset, you'll destroy the format setting since it's not in the select menu.
Also, I changed the file extension on the default H264 preset to "mp4" and bumped the frame size to 640x360.
Comment #5
mjvesper commentedI'll take a look at this patch, however from the sound of it I don't think such a fragile solution or forced hack is a good route. People's ffmpeg builds will be different. Parsing the ffmpeg binary for supported formats is the correct approach and building the format select boxes from that is fine. If you select mjpeg or image2 and add an additional extension in the custom command of jpg, it works fine from the command line aside from having a double extension. The filename token should get around that but it seems like it is misconfigured.
I have a feeling the bug lies elsewhere... Maybe more in the reattachment to a filefield. The queue and conversion from an uploaded file worked with video files uploaded to mp4. But doing the same with a rule to queue these ffmpeg image commands didn't. It had the input path correct but the output was reported from /tmp. This was using Rules to create the thumbnail from an existing video in another filefield. Really, it shouldn't matter the format... I could strip audio from a video file and attach it using your module theoretically.
Comment #6
zoo33 commentedThe format selector in the UI is what effectively becomes the output file extension in the command, so the way I see it you should be able to choose "jpg" since that is actually a format that ffmpeg can write to. You're right that the available formats differ depending on how ffmpeg is compiled etc., but I think jpg would be supported almost always. Adding "jpg" to the list could also be done conditionally depending on the existence of the "mjpeg" codec. This is probably something that should happen in FFmpeg Wrapper however.
The above patch tests this idea without actually changing the settings interface, which I don't see as a permanent solution (it's very fragile as you say). But since I got the thumbnail generation working that way it suggests that adding "jpg" to the available output formats is what's necessary to make thumbnail generation work. (I didn't have any luck with "mjpeg" or "image2", but I didn't actually try to add .jpg to the custom command.)
Does the default thumbnail preset work for you? Looking back at the command in your original post, I think that probably should have worked too if you added the -vcodec option, which you say you did, so I'm not sure...
Comment #7
osopolarDon't forget to to pass the "-y" option to ffmpeg to "overwrite output files". It took me a while to figure out, why my cron was hanging ... sometimes and only on jpegs. There was already an output file with the same name. ... The last words of ffmpeg were:
Comment #8
osopolarComment #9
iva2k commentedI patched ffmpeg_wrapper to support conditional jpg file format if mjpeg is available. Together with a patch to ffmpeg_converter to modify the ffmpeg command appropriately, thumbnails are created and attached to cck field properly.
One remaining obstacle is configuring the time position. I hacked the ffmpeg_wrapper configuration form (changed time limit from select input to textfield, so it can be typed into). It works, but UI becomes not evident. Also it needs some javascript to change labels on the fly. And I don't like solutions spanning two modules, even as simple as this one.
Let me know if any of the maintainers are interested in the above patches.
Comment #10
zoo33 commentedI'd say the two patches to get 'jpg' into the format selector sound interesting. If you haven't done so already, I'd suggest posting to FFmpeg Wrapper first.
The time position is a whole other issue, and that too should be solved in -wrapper first.
Comment #11
iva2k commentedSounds good. I've posted a patch to ffmpeg_wrapper in #817480: jpeg/jpg output format using mjpeg codec (see http://drupal.org/node/817480#comment-5071184) that is required for jpg thumbnails support.
When (if?) the ffmpeg_wrapper patch gets committed, then the patch attached here can use the benefit and provide simple support for jpg thumbnails.
When generating the jpg thumbnail patch I found few issues with ffmpeg_converter code (that I solved before) and coding conventions.
1. whitespaces at the end of lines (not conforming to Drupal coding conventions) in few files - they pollute patches with tons of "changes" that are not relevant (I was guilty of those in my modules before I tuned my editor's settings).
2. there are some minor to major issues not related to jpg thumbnails that I fixed on my installation (Drupal queue is using 'worker callback' instead of 'function', error handling of queue->createItem, ffmpeg_wrapper_run_command() returns an object, also some useful additions to messages, like a link to run cron manually).
3. adds the jpg support of interest.
So I've split it into 3 patches here to facilitate review (I recognize that fixes in patch 2 perhaps need separate issues for each, but I don't have enough time to break that into pieces and post individually). They need to be applied sequentially, though I believe it is possible to apply them independently (some line numbers flexibility/fuzz in "patch" command may allow that).
I also have additional code that utilizes 'source' bitrate setting for audio/video streams. It also involves a patch to ffmpeg_wrapper, and beyond the scope of this issue. I stripped that out to lighten up the complexity of this changeset. If this goes in smoothly, I can follow up with the remaining changeset.