Vdx – An intuitive CLI for processing video, powered by FFmpeg
github.com
github.com
Ffmpegs documentation on the other hand forces me to feel as though it’s normal to assume knowledge about a point in a video and what it means if my encoders are different from input to output.
ffplay --help
8826 lines $ man ffmpeg-all 2> /dev/null | wc -l
33160anyway, on my system (macOS, ffmpeg 4.3.1 from Homebrew) the situation is even more dire:
$ man ffmpeg-all | wc -l
38738 $ man ffmpeg-all | wc -l
troff: <standard input>:6148: warning [p 42, 3.5i, div 'an-div', 0.0i]: can't break line
troff: <standard input>:6150: warning [p 42, 3.7i, div 'an-div', 0.0i]: can't break line
troff: <standard input>:11396: warning [p 68, 8.7i]: can't break line
troff: <standard input>:11398: warning [p 68, 9.2i]: can't break line
troff: <standard input>:13562: warning [p 79, 6.0i]: can't break line
troff: <standard input>:13564: warning [p 79, 6.5i]: can't break line
troff: <standard input>:26366: warning [p 132, 17.2i]: can't break line
troff: <standard input>:38313: warning [p 174, 27.5i]: can't break line
33160
No idea what it means.For example not the best - re-encoding video or audio tracks when it could just copy them, picking the defaults when their is a better quality option?
Video and audio processing is one of things that if you want good results with wide flexibility you have to learn it and also try things out.
More fundamentally, however, FFmpeg supports both simple and complex operations. This program takes simple operations and does them wrong, and takes complex operations and throws them out. For example, the command to halve the audio volume of an mp4 file containing audio and video would be:
ffmpeg -i infile.mp4 -c:v copy -af volume=.5 outfile.mp4
There are a number of problems with this command. Most importantly, it always encodes audio output with the built-in AAC encoder at 128 kbps. A better command would take into account the input quality and desired output quality and codec, then specify something like "-c:a libopus -b:a 80k" to select the desired result. vdx solves this complexity by simply ignoring it and using the FFmpeg default. A similar problem applies to its video codec settings, which always uses libx264 with the default settings. This is a poor choice. Almost always, either a slow setting (for better quality and smaller file size) or a fast setting (for worse quality and larger file size) is desired. Also, in my experience, either a lower CRF (for high-quality film content) or a higher CRF (for low-quality phone/ripped content) is desired. If you're going to punt on doing it properly and just use the defaults, you might as well just use ffmpeg directly.The issues go far deeper than that, however. The entire design of the program is flawed. It appears to try to process the file twice: once for video, and once for audio. However, the author seems not to know that ffmpeg will re-encode video by default. Therefore, a simple command like "vdx myfile.mp4 --volume 0.5" unnecessarily re-encodes the entire video, twice. It applies operations in what seems to be undefined order, which is a problem when (for example) cropping and also resizing a video.
That being said I need to dig into this library some more to review.
on edit: somehow I posted this twice. but deleted one.
To my knowledge, no project succeeded in doing that. It's not difficult to code a simple reader and a basic encoder, but then you have many cases not supported correctly, as you wrote.
Would be great if vdx learned more "common" ffmpeg features (creating a slideshow from a set of images, speeding up videos, simple drawing, etc.) while maintaining its simplicity!
I'm still all for simpler frontends being available but there's going to be a limit of how many things can be covered before it is just as hard to use as ffmpeg.
https://handbrake.fr/docs/en/1.3.0/technical/source-formats....
I'm currently learning gstreamer and it seems to cover more features than ffmpeg. Its CLI command, gst-launch is fantastic to prototype. Is there a specific reasons why more people choose ffmpeg over gstreamer for go-to media processing library?
By contrast ffmpeg-powered projects tend to just work out of the box with practically any set of files imaginable… much more pleasant.
Plus does gstreamer even have a CLI targeted at users rather than developers? If they do they don't advertise it every well!
"execa": "^4.0.3",
"glob": "^7.1.6",
"mkdirp": "^1.0.4",
"moment": "^2.29.1",
"nopt": "^5.0.0",
"npmlog": "^4.1.2",
"nyc": "^15.1.0",
"p-all": "^3.0.0",
"rimraf": "^3.0.2",
"tape": "^5.0.1",
"unique-slug": "^2.0.2",
"which": "^2.0.2"
Sorry for any basterdized formatting. OMYou can just ignore this if you don't care for how it's built. This kind of comment is just gatekeeping and makes people less likely to listen to you.
If you think there's a better way and you want people to get there, give constructive feedback. That's the only valid option.
npm has a lot of tools that make creating CLI tools a breeze. For example there’s Listr and the more generic Ink (“React for CLI”)