As an update of ffmpegGUI effected a discussion on the HaikuDepot announcement thread, I moved the relevant comments to this new thread.
As an introduction:
ffmpegGUI is a graphical interface to help constructing the commandline for ffmpeg to encode/convert video files. You can also encode files directly with ffmpegGUI and avoid having to open Terminal to paste the assembled ffmpeg commandline. You can also create encoding jobs to process them all in a batch later.
FWIW, the current maintainers of the app - @BlueSky and I - do not plan to extend ffmpegGUI to support each and every feature of the ffmpeg suit. ffmpeg is extremely powerful and there are few things video it cannot do in some way.
However, trying to cram it all into one app will explode the GUI and make the app less usable. Better create dedicated little tools that concentrate on few features.
(At least that’s what I got from reading @BlueSky’s comments on things. He’ll correct me if I misrepresented his opinions.
This doesn’t mean that no new features will be added, but we have to limit ourselves to what fits without adding too much complexity to the GUI.
You mean creating a video from multiple images, right?
I don’t want to rule it out completely but most likely not. We have an unwritten rule we go by, which is that we don’t want ffmpegGUI to become a video editor (mainly because we already have a native video editor with Medo). Of course it’s not always clear where the line is to be drawn.
For this feature to be useful we would need at least some kind of timeline in the gui to place the images and set the durations. This is clearly video editor territory if you ask me If you don’t agree with this and have some general ideas how the GUI for this feature should look like, please let us know.
I’ve made a screen capture tool with yab in the past, here I’m doing the same thing, taking screenshots and then connecting them with ffmpeg. So if you have the opportunity to list the pictures, you can make a video out of it.
A video editor edits existing videos and you can add something. A GUI for a tool can and should contain all the useful functions that are possible. So I don’t see what’s wrong with that. And if the function only involves selecting a folder from the contents of which the video will then be created, it’s still easier than dealing long time with a video editor.
In theory - and without having looked at it in detail - this might be possible. We wouldn’t need GUI changes even. The user sets the framerate with the existing BSpinner and off we go.
The one tricky thing is how to select the source images. Easiest, but not super user friendly, would be to make the user put’em all in a folder and have it selected just like you select a video file. The app would check if the selected folder only holds images and goes into image2video mode. Relatively easy, but not intuitive, people would need to read the docs to find out how it’s done.
Better would be to have the user just select all images. Depends how those are fed to ffmpeg…
Anyway, it seems possible without much/any additions to the GUI. Though, the devil usually lurks in the details…
Recent ffmpeg can be built with avisynth support, and that would move the complexity into the script creation (incidentally, it would also open possibilities for almost unlimited video pre-processing). Is the ffmpeg in haikudepot built with avisynth support?
[I really think EVERY video encoding/manipulating/transcoding application should AT LEAST support avisynth input, but anyway…]
No, you can create new videos in a video editor, as well as mix in still images, or create a video from still images. I tried with Medo today, it’s very easy and straightforward. And all of that with a nice timeline where you can select how long every picture is display, use blend-over effects etc. If you ask me, it’s the much better tool for this job.
Sorry for having to contradict you again, but that is decidedly not the goal for ffmpegGUI. If we make every option in ffmpeg available the gui becomes so cluttered that it’s almost as complicated as using ffmpeg on the commandline. A good example of what we don’t want is https://github.com/cdgriffith/FastFlix/raw/master/docs/gui_preview.png.
We want to provide a rather simple GUI for the most common operations that non-experts will want to do with ffmpeg. And for the advanced users, the commandline can be edited and enhanced before running.
Perhaps a name like “Simple Video Converter” would fit the project better. A name like ffmpegGUI will make people think that it can do what ffmpeg can do.
In linux world, it’s indeed more or less the rule to provide all options of the command line tool in GUIs and one GUI for each desktop environment. That’s because there, GUI is built over command line and people are opposing both. On one hand, you have people that are so in love with command line that you’re wondering why they’re installing a X server, they also are great fans of keyboard shortcuts; while on the other hand, you have people, usually more comfortable with mouse navigation, thinking that command line should disappear. For them it’s a barbaric tool of torture inherited from dark ages. Of, course, I’m exaggerating but in that world, communities tend to divide as soon as a new thing is appearing.
On Haiku, this is totally different because the graphic server is integrated, there are no desktop environment, and Terminal is only a tool among others. There is also a philosophy, that software must be simple to use, easy to learn. Instead of a single over-complicated graphic app containing each and every options of the command line tool, there will be several simple apps focusing each on the different tasks. In short, here, we prefer to divide software than community.
I´ve already explained why we don´t want to expose every ffmpeg feature through the GUI. ffmpegGUI might not be the most creative name choice but it describes pretty accurately what the app does, and makes it clear that ffmpeg is used to do the hard work. Also it is the name picked by the original author.
That’s why I wrote “should contain all the useful functions that are possible”. Means all functions that are useful. As o especially those that are helpful for the normal user. So you don’t have to disagree
I see it a bit differently, because a project has to start first. I have the same with my Imagemagick GUI and Ghostscript GUI. First you build in everything you know about the possibilities and over the years the program is then constantly expanded/improved. Not everyone knows everything and I’d rather build in fewer functions sensibly than integrate everything half-heartedly.
Every project also becomes much more interesting as soon as others get involved. Could learn a lot when dealing with ImageMagick. Unfortunately, that didn’t work with the GhostScript GUI. That’s how it is sometimes. One project is expanded, another freezes. But then it is still a GUI of the respective command
But ffmpeg is not a video editor and would restrict the project, because then you would always think, is this function that I would like to add now compatible with the program name?
But I also know this way from the Linux world. Luckily we are not linux
Definitely true. I´ve learned so much about ffmpeg while working on ffmpegGUI that I now use it on the commandline for my own needs most of the time, instead of using the GUI.
That´s also true of course. It all comes down the word “useful” that´s where the opinions start to differ.
And I have the same problem with my “Mass Picture Converter”, it uses imagemagick and to create a video from the imported images I would have to use ffmpeg. That would actually be too many dependencies for a small tool. Therefore, I hope that this function will flow into you.
