jpeg/jpg output format using mjpeg codec

I added support for %file_name in the 6.2.x branch. In reality, I should really add token support for this, but I just haven't gotten there....

It actually does have the test converter- you need to attach a file to a node to use it.

Yes. Also make sure to enable the ffmpeg_wrapper_ui module which contains all of the interface functions

The new version of ffmpeg wrapper only works on drupal's upload function (not sure if you're using cck or not). Go to the node/X/edit screen and you should see a link on your file if ffmpeg can transcode it.

I haven't had time to support cck yet. You need to use the drupal upload module.

you should use media mover if you want to do batch processing

Media Mover doesn't allow you to upload- you just need to create your content types that can handle your uploads. Media Mover can then grab those files and transcode them and what not.

if your swfupload module uploads to a filefiled (cck) media mover can harvest from that.

Ffmpeg is completely capable of making a jpg file, and ffmpeg_wrapper should be able to do it as well.

Unfortunately it does not completely fit into the current ffmpeg_wrapper approach. On the "test convert file" page there is no 'jpg' file type. You have to use a custom command, and output file extension is either end up being a .mjpeg (which not many browsers can handle as an image file, even if it is binary the same as .jpg), or you have to specify it in the custom command explicitly.

One complication is that ffmpeg_converter module uses the settings form from ffmpeg_wrapper, and it inherits the limitation of having no 'jpg' file type on the list. As a result it is quite difficult to add a "thumbnail" feature to ffmpeg_converter.

Fortunately, the fix is quite simple. At a minimum, ffmpeg_wrapper can add 'jpg' to the list of file types (it can be conditional on mjpeg format). To go all the way, ffmpeg_wrapper "test convert file" can be also modified to create jpg files. Attached is a patch that does both things. It looks bigger, as it needs to indent existing code into a new else block.

Please review and commit, it is needed to unblock ffmpeg_converter's #973110: FFMPEG Thumbnail Errors.

While I definitely understand the desire to have a setting for image conversion I think this is getting overly specific for what ffmpeg wrapper is supposed to be. Creating an image from video requires multiple parameters (codec, frame position at a minimum) which is in my opinion beyond the scope of the pull down even if the values for frame position are taken from another field. I think it's trying to do more than what the current interface can handle- which is a fault of the interface, not the idea. I guess I'd like to reframe this issue around what should the workflow in this case look like?

FFmpeg wrapper was built for media mover- this form is pulled into a specific video conversion form. Media mover has a completely separate interface for handling image derivatives from video which I thought made it easier to handle the general task vs. the specific task.

Is there a way that we look at the need for image derivatives via ffmpeg converter this way?

All this being said, I think there is also a good argument that the "file type" selection is insufficient and really should have an option for "other" which would provide a text box to allow the person to enter their file extension.

@arthurf
I agree with your arguments. I think ffmpeg_wrapper should be a clean-cut API. It should provide all necessary means to invoke ffmpeg, and nothing more. Debate starts on the conversion function as it is one layer up above that functionality, and having it in ffmpeg_wrapper may be a mistake, as it is tied to $params that originate in a form from another module. You can't update one without the other.

On the argument of 'other' file format it may work better than a set of hard-coded types, but without code dealing with thumbnail case it will be pointless. Somewhere in the conversion function you need a branch that does -ss and -vframes arguments for ffmpeg.

At the same time the ffmpeg_wrapper_ui's mission is not that clear. It moves into conversion territory, and the border between it and ffmpeg_converter becomes blurred as a result. Having no profiles in ffmpeg_wrapper_ui is an issue, and it creates structural tensions with other modules.

Few decisions have to be made:
1. Who provides conversion profiles?
2. Who provides conversion function that uses the profiles?
3. Who is responsible for maintaining this functionality and expanding it for new features?

As long as this functionality is distributed among many modules (as a result of a non-decision), there will be mess and nobody will benefit. I see few approaches:

A. Declare that other modules have to create their own profiles. This should result in ffmpeg_converter making its own settings form, not stealing it from ffmpeg_wrapper_ui.
B. Declare that ffmpeg_wrapper is responsible for profiles (it can be ffmpeg_wrapper_ui, or new ffmpeg_wrapper_profiles module)
C. Stay undecided to the detriment of the ffmpeg-based features.

Profiles are tightly coupled to what ffmpeg can and cannot do, so I vote for A. This will probably need more work in short term than B, but the end result will be less maintenance across all involved modules.