[HN Gopher] Ffmpeg Buddy
___________________________________________________________________
Ffmpeg Buddy
Author : thunderbong
Score : 328 points
Date : 2022-05-30 11:17 UTC (2 days ago)
(HTM) web link (evanhahn.github.io)
(TXT) w3m dump (evanhahn.github.io)
| soheil wrote:
| Would also love to see a vlc buddy.
| phailhaus wrote:
| Ooh, if this also used ffmpeg-wasm [1], you could then run the
| command itself in the browser!
|
| [1] https://github.com/ffmpegwasm/ffmpeg.wasm
| OzzyB wrote:
| Hmmm... not really, irrc you will be bound by memory limits of
| your browser/wasm context. Small videos would be fine, large
| ones, not so much...
| 0x62 wrote:
| FWIW we've been using ffmpeg-wasm on one of our products [0]
| for a couple months and the main issue is garbage collection.
| You're limited to 4GB memory, but if you don't kill and
| restart the workers every N operations it crashes the browser
| tab (even with proper unlinking of files in the virtual FS).
|
| I suspect you could still make it work with clever usage of
| the File System Access API as a cache, and process larger
| files in chunks. Then you'd mostly be limited by the Blob
| storage limits [1], and memory required to merge processed
| chunks together.
|
| [0] https://nft-inator.com/app
|
| [1] https://chromium.googlesource.com/chromium/src/+/224e43ce
| 1ca...
| marclundgren wrote:
| It works great for audio. Here's a wasm-ffmpeg solution I
| created trim audio.
|
| https://wasm-audio-clipper.netlify.app/
|
| Check the repo: https://github.com/marclundgren/wasm-audio-
| clipper. I ended up lazily registering the context. The
| memory footprint stays lower even after trimming multiple
| clips on the same session.
| eevilspock wrote:
| Isn't the better solution for most users a GUI tool like
| Avidemux?[1] The point being that those who want to use the
| command line are precisely the people who need to understand all
| its complexity.
|
| ---
|
| [1] https://avidemux.org. Avidemux has a "built-in libavcodec
| library from FFmpeg (i.e. Avidemux contains its own copy of
| libavcodec, external FFmpeg is not used)"
| fareesh wrote:
| These are the easy ones. What would be amazing is the arcane
| incantations that mere mortals don't remember.
|
| Another tool that this is nice for is imagemagick. Is there
| something newer than imagemagick for image generation these days?
| I'm having trouble with some non English scripts and draw text
| NegativeLatency wrote:
| Have you tried/considered trying it in an svg and then
| converting to a raster format?
| HellsMaddy wrote:
| For a long time, I've wanted an interactive Imagemagick
| interface that allows you to add/tweak flags and shows an
| immediate preview. The Imagemagick site has something sorta
| like this[0] but it's not very good.
|
| My current workflow is to open the image in a viewer that
| automatically reloads on change, like feh or sxiv, and then in
| my terminal use <M-a> to run the command without clearing the
| command line.
|
| [0]:
| https://magickstudio.imagemagick.org/scripts/MagickStudio.cg...
| ehsankia wrote:
| Indeed, these are very basic stuff, which may be useful for
| some people's workflow, but then by the time I started remember
| this website, I'll probably have already memorized the few
| flags the website profiles anyways.
|
| In my experience, you're just better off searching for what you
| need, in my experience you'll always find a bunch of results
| with the exact ffmpeg incantation you need for your specific
| rare usecase.
| gubneor wrote:
| https://github.com/topics/ffmpeg-gui
|
| https://github.com/MattMcManis/Axiom
| pt_PT_guy wrote:
| all of these I know by head.
|
| the difficult part is to combine vaapi, codecs, re-encode audio
| without re-encode video (and vice versa), codec lists, etc
| donbronson wrote:
| This is excellent. Is there something like this for ImageMagick
| as well?
| Ansil849 wrote:
| The concept of this would be incredibly useful...I use FFmpeg
| every few weeks, which is not often enough to remember all the
| commands I need.
|
| But the execution here is a bit lacking. This only lets you input
| basically 10 parameters.
|
| If this were to be expanded to include all FFmpeg params, it
| would be INCREDIBLY useful.
| kortex wrote:
| Question for the peanut gallery, because it's vaguely topical and
| I've spent hours researching problem to no avail.
|
| How can I mux arbitrary data streams into a container? Let's say
| I have a drone and I want to stream audio, video, and some
| avionics telemetry.
|
| I know FFMPEG can _pass through_ data encoded, and it lists a few
| binary stream formats: ffmpeg -codecs | grep
| '^ ..D' # shows all -c=d codecs ..D... bin_data
| binary data ..D... dvd_nav_packet DVD Nav packet
| ..D... epg Electronic Program Guide
| ..D... klv SMPTE 336M Key-Length-Value (KLV)
| metadata ..D... mpegts raw MPEG-TS stream
| ..D... otf OpenType font ..D... scte_35
| SCTE 35 Message Queue ..D... timed_id3 timed
| ID3 metadata ..D... ttf TrueType font
|
| But I have no idea how to pack some new data stream into the
| filtergraph.
| gyan wrote:
| Is the data packetized and with timestamps?
| kortex wrote:
| The data has temporal component, yes. But how would I
| packetize it in the first place? I have the high-level
| concept that I need to take each of my data chunks and put
| them into some kind of timestamped container/page/atom and
| feed them into the stream, but I have no idea how to actually
| emit those packets. Like let's say each time step I emit a
| binary blob of msgpack-encoded data. How do I wrap that with
| a timestamp/sequence number container?
| nwallin wrote:
| With -map. https://trac.ffmpeg.org/wiki/Map
|
| ffmpeg -i input1.mkv -i input2.mkv -i input3.mkv -map 0:v -map
| 1:a -map 0:d -c copy output.mkv
|
| ...will take the video from input1.mkv, the audio from
| input2.mkv, and the data stream from input3.mkv. If you
| telemetry isn't already packetized, you'll need to do that
| yourself. Converting your drone's telemetry into something that
| ffmpeg likes is generally non-trivial.
|
| At my day job I maintain a tool that takes a .csv file and a
| raw video file and outputs a single file. Which can then be
| viewed, with the data displayed on the map and such.
| https://pro.arcgis.com/en/pro-app/latest/tool-reference/imag...
| kortex wrote:
| Many thanks!
|
| > if you telemetry isn't already packetized, you'll need to
| do that yourself. Converting your drone's telemetry into
| something that ffmpeg likes is generally non-trivial.
|
| Yes, this is exactly the non-trivial step I'm struggling
| with. Let's say I have every time step a msgpack-encoded
| binary blob with a timestamp. I want to packetize it and pack
| it into a data stream of some timestamped/sequenced
| packet/page/atom structures. I might be able to build those
| packets myself manually if I can find a viable format (mkv
| and ogg seem the easiest to reason about).
|
| And ultimately I do want to do this with real-time streams,
| but I'll definitely look at this Video Multiplexer to start
| with! That at least scratches the itch of archiving this
| data.
| nwallin wrote:
| Yup, unfortunately (but fortunately for my employer)
| there's no off the shelf tool that does this. Ultimately
| you just have to write a bunch of code.
|
| There does exist a standardized way to encode the data:
| MISB (Motion Imagery Standards Board) ST 0601:
| https://nsgreg.nga.mil/doc/view?i=5093
| paulmd wrote:
| I say this with the best of intentions: I wish this went a little
| farther. A lot of the complexity comes from transcoding options,
| filters/transformations applied to the video/audio streams, and
| control of how the file gets put back together.
|
| (And sometimes there are oddities about how they interact, or
| there is one option that seems very deprecated. It's like
| Eclipse, it's an engineer's tool, it's extremely powerful but god
| had no hand in the creation of the UX whatsoever, it is the
| unholy amalgamation of hundreds of modules that usually work,
| usually, mostly.)
|
| Give me checkboxes for "resize this video", "convert framerate",
| "decomb filter", "burn hardsubs filter", a reasonable set of x264
| or x265 transcoding options, audio transcoding and downmux, and
| options for controlling how it all gets reassembled.
|
| It might help to list out some simple use-cases and then look at
| the ffmpeg features that would be required to get there, and then
| support those. But again, it's sort of hard to capture everyone's
| use-cases, ffmpeg is such a swiss-army knife.
|
| Personally I use it for:
|
| * to direct-stream cut (no re-encoding) slices of videos for
| memes
|
| * to handle game replay captures (sometimes with re-encoding,
| sometimes not) and combine separate audio tracks into a file for
| youtube
|
| * to handle game replay captures (always with re-encoding) but
| with separate audio tracks preserved
|
| * to cut out audio tracks/subs that I don't want from a given
| movie/show when it becomes annoying
|
| * to transcode a movie/show for archival at the minimum
| size/maximum quality
|
| etc
|
| In particular I'm not sure how to really tell ffmpeg to handle
| multiple audio/sub streams without programmatic interaction - you
| kinda need to know there are 2 audio streams and 4 sub streams,
| because you need to tell it what to do with each stream you want
| included in the output file, even if you do the exact same thing
| to every stream. If you have one show that's a little weird,
| fine, but without some kind of front-end it gets difficult to
| handle _arbitrary_ content that is similar but not quite.
| dylan604 wrote:
| What's crazy is that there are so so many variations of GUI
| options for FFMPEG. Typically, the GUI is limited by what the
| creator's use of FFMPEG tends to be. Which by all means is not
| a knock against it. It serves a purpose, and if it serves a
| purpose for them it probably is useful to others in the same
| way.
|
| Then there are those that want a more generic version that
| allows all the bells & whistles to become available in the GUI.
| However, now you need to have a much better understanding of
| FFMPEG which the vast majority of FFMPEG users don't know (I
| myself learn new things everytime a new task is given).
|
| At the end of the day, give it a go yourself to build a UI on
| top of FFMPEG to expose all of the things you just requested
| and see how painful it can be. I've done it multiple times for
| multiple jobs and not one of them was the same. It gets even
| more fun when you have sources with a combination of discrete
| and interleaved audio streams with high channel counts. Now,
| you have to probe the source and provide that info to the user
| to allow for output audio considerations. Based on those, you
| then need to potentially merge/join/split/map the audio. It's
| maddingly fun to those with those sense of perversions like me.
| paulmd wrote:
| To me the most intuitive and flexible UI would be something
| like Avidemux where you have a picker of filters/transforms
| and you can add them to a box on the right (potentially you
| can add them multiple times, etc) and then configure them.
| That is a very powerful "general" UI flow that works
| reasonably well imo.
|
| But yeah you're right, it's all a question of how much
| capability you want to surface, because the more you surface
| the more quickly it gets complex and inscrutable to anyone
| not in the know.
| DANK_YACHT wrote:
| The issue with FFmpeg is that it's complex, so you need to
| understand what all the options do, but the interface is also
| complex, so you need to understand how to format what you
| want to do, even if you already have a good understanding of
| what you want from FFmpeg. E.g. the order of different
| options matter, applying some options to one stream vs.
| another, chaining filters together, formatting the filters,
| specifying the output options, etc.
| paulmd wrote:
| This is, btw, a great time to plug "bropages". Manpages
| give you in-depth documentation on what each option does,
| bropages the idea is to give you a synthesis of an actual
| task being done with those command options, then you can
| mix-n-match to fit your use-case (if necessary).
|
| http://bropages.org/ffmpeg
|
| The antidote to ffmpeg's arcane command-line has always
| been finding someone else who already did it and seeing
| what they did differently. There are, of course, many ways
| to skin the cat in ffmpeg, but you often just need to see
| some finished, working commands and start from there.
|
| You could of course build that on a wiki somewhere, ffmpeg
| does have various examples in their docs, but bropages is a
| place to curate that sort of stuff.
| thrtythreeforty wrote:
| For even more brevity, there's tldr [1], which is short-
| n-sweet "how do I do the most common things with this
| tool."
|
| You'll need a client for it (tldr itself is just the
| database). I recommend tealdeer [2].
|
| Example: $ tldr tar
| Archiving utility. Often combined with a
| compression method, such as gzip or bzip2. More
| information: <https://www.gnu.org/software/tar>.
| [c]reate an archive and write it to a [f]ile:
| tar cf target.tar file1 file2 file3
| [c]reate a g[z]ipped archive and write it to a [f]ile:
| tar czf target.tar.gz file1 file2 file3
|
| [1]: https://tldr.sh/
|
| [2]: https://github.com/dbrgn/tealdeer
| dylan604 wrote:
| ^An issue with FFMPEG
|
| This isn't THE only issue with FFMPEG. There are many many
| problems with FFMPEG, but it's the best thing we have in
| this area. Warts and all, I would probably, no, definitely
| would not have been able to achieve many of the career
| accomplishments I have without it.
|
| As you start to reveal the multitude of
| switches/options/etc available to FFMPEG via GUI, the GUI
| becomes gnarly and complicated very quickly. This then
| becomes just as daunting to the avg user as trying to build
| the command itself. There are many practical uses for a
| very simplified GUI to achieve a limited set of
| functionality. There's nothing wrong with it. In fact, I'd
| be willing to guess that if a UI came along that exposed
| every single thing that FFMPEG could do, fewer people would
| use it than a much more simplified version.
| DANK_YACHT wrote:
| GStreamer has a much more sane CLI interface. FFmpeg
| generally works better than GStreamer, but it's
| definitely possible to make a better command line
| interface.
| paulmd wrote:
| Yeah "modules that mostly work, usually, mostly" is no
| joke. And it's not that anyone really could do anything
| significantly better than ffmpeg, it is probably one of
| the best examples besides the kernel of an astonishingly
| complex library that is run extremely competently but the
| task space is just maddeningly complex and full of wild
| edge-cases. Especially when dealing with "legacy" formats
| and codecs from the 90s and early 00s - even today, have
| fun transcoding RealVideo or ASF files with some weird
| color space that nobody has used in 20 years.
|
| There are infamously a lot of tasks that "look easy
| upfront but have a lot of underlying complexity" and
| ffmpeg is not one of them. It's a task that looks hard
| upfront and then when you get down into the weeds it's an
| eye-bleeding eldritch monstrosity.
|
| The consensus around MP4 and MKV containers and some
| relatively small number of codecs (H264, H265, VP1, AV1,
| etc) has substantially eased things but video codecs,
| audio codecs, and container files are just complicated
| af.
|
| And believe it or not - this is still way, way better
| than it used to be! Flaskmpeg was never stable,
| Virtualdub was nice but development ended with avi
| container files, there were some forks that added various
| features, etc, but ffmpeg and OBS Studio both actually
| just work incredibly well compared to what came before.
| dylan604 wrote:
| >has substantially eased things
|
| except not everyone has decided to use that easing of the
| things. it seems like they go out of their way to make
| things difficult
|
| My favorite is in how MP4s are not all the same. A video
| captured on a DSLR or other acquisition camera source
| might have +/- in the video/audio sync when imported into
| an NLE. Yes, the container utilizes PTS syncing to
| playback the video/audio streams in sync, but this +/-
| slop in sync is annoying AF to professionals capable of
| seeing the sync slop. Average consumers probably never
| notice. I thank all the gawds in all the heavens that I
| no longer have to edit MP4 source captured content and
| all of the manual slipping in the NLE.
| scottlamb wrote:
| If you want a single tool/library that does all the
| things ffmpeg does, I agree. ffmpeg does lots of things,
| some of them are inherently extremely complex, and it
| puts them together cohesively. That's impressive! I think
| the closest competition is gstreamer, and gstreamer ends
| up calling into ffmpeg for software H.264 decoding...
|
| But...sometimes you want one particular thing, that thing
| is relatively simple (compared to e.g. H.264 decoding),
| and you have needs ffmpeg doesn't meet. Then you probably
| can do better. A couple examples that have come up for
| me:
|
| * specialized .mp4 muxing. My NVR project does this in a
| way where it can do HTTP range serving, so put the moov
| up front, produce the length quickly, and produce a given
| byte range without iterating through all the bytes
| before. ffmpeg can't do that, understandably. Hard to do
| in a general-purpose library; the container muxing input
| interface doesn't expect all the necessary information is
| available up front. But it's not that bad as a one-off.
| As you say, the consensus around a small number of
| containers really helps.
|
| * RTSP. Consistent with your "modules that mostly work,
| usually, mostly", ffmpeg has various long-standing bugs
| in its RTSP handling (e.g.
| https://trac.ffmpeg.org/ticket/5018), has the risk
| associated with protocol handling in a non-memory-safe
| language, doesn't have much of a test framework for this,
| etc. This problem is relatively approachable (though
| hardly trivial), so I had success making my own library.
| [deleted]
| thrdbndndn wrote:
| Agreed. At this point probably just use CLI.
|
| One thing I hate about CLI tool though, is that it's very
| hard to edit long commands in terminal.
|
| For example, to replace the input filename from the
| previous command. I can do it in one second with my
| keyboard + mouse (use the mouse to select the old one, and
| type in the new one which would replace) in editor but you
| can't do so in terminal.
|
| Another example is to change the order of some switches.
| Again very easy in text editor, not so much in terminal.
|
| So, everytime I use FFMPEG for some complex one (especially
| when I need to go through trial and error, I have to write
| the thing in a text editor and them paste them into
| terminal.
| paulmd wrote:
| > One thing I hate about CLI tool though, is that it's
| very hard to edit long commands in terminal.
|
| Apart from the "wrap it in a shell script" advice, I
| would also note that in a bash-like terminal, home and
| end will jump to the start or the end of the current
| command buffer, and ctrl-del (or alt-del maybe?) or ctrl-
| arrow keys usually delete or move the cursor a whole word
| at a time, which makes it somewhat quicker to work rather
| than sitting there holding an arrow key or backspce.
|
| Many here probably already know this, some may not!
| thrdbndndn wrote:
| Thanks, yeah I know these since I use them heavily in
| editor as well.
|
| Now this got me thinking: the main problem with terminal
| is that it doesn't seem to support "cut" (and
| consequently, "paste to replace selection"). So re-
| arranging a command string is _always_ gonna be a pain
| regardless the complexity.
|
| I can see why it was this way historically, but not
| exactly sure why no modern terminal emulator gives this
| feature, even as optional.
| paulmd wrote:
| one analogy might be the "cut and accumulate" feature in
| nano (and probably others) where a line is removed and
| appended to the clipboard, then you can paste and all
| those lines will be pasted off the clipboard at once. You
| could do that at a character level in the shell, if you
| wanted. No idea if any shells do though.
| noir_lord wrote:
| ctrl-x e
|
| > It's a small key sequence: ctrl-x e . What's this do?
| It takes the existing command that you currently have on
| your command line and opens it in your shell's editor
| remram wrote:
| It's ctrl-x ctrl-e
| [deleted]
| dylan604 wrote:
| >One thing I hate about CLI tool though, is that it's
| very hard to edit long commands in terminal.
|
| Only a madman would do this. I don't know anyone that's
| in the middle of R&D that builds directly in the CLI
| that's sane. Everyone tries it, and just at the point of
| losing sanity, does the rational thing of building the
| command in a text editor for a simple copy&paste into the
| CLI later.
| benfrancom wrote:
| Yep, or turn it into a script and use an IDE/Vim/etc and
| test in the terminal.
| res0nat0r wrote:
| I've been using ffmpeg-python recently, and it will do a lot of
| the crazy complex transforms for you, and you can write sane
| python code vs. trying to deal with the crazy default ffmpeg
| syntax.
|
| https://github.com/kkroening/ffmpeg-python
| elesiuta wrote:
| > In particular I'm not sure how to really tell ffmpeg to
| handle multiple audio/sub streams without programmatic
| interaction - you kinda need to know there are 2 audio streams
| and 4 sub streams, because you need to tell it what to do with
| each stream you want included in the output file, even if you
| do the exact same thing to every stream.
|
| I made a script that converts all the videos in a directory
| above a certain bitrate to H.265 to save space and found that
| just using the flags `-map 0` to grab every stream, and `-c:s
| copy` was enough to avoid having to probe the source for every
| stream since subtitles were the most problematic if any streams
| were bitmaps. It then checks if there were any errors before
| replacing the original video. I still get the occasional
| outlier that I either fix by hand or just leave as is.
|
| Also the script was written with python and argparse, so it
| would be relatively easy for me to create a GUI with Gooey[1]
| if there was interest.
|
| [1] https://github.com/chriskiehl/Gooey
| cm2187 wrote:
| A good reason why it cannot be web based, you need to scan the
| source video to be useful, so you know which tracks are
| available (some subtitles aren't supported by ffmpeg). If you
| merge two files the fps or resolution might not be compatible.
| I think this calls more for a (or rather multiple) desktop
| apps.
| SomeHacker44 wrote:
| My most common use case is to make something fit into a certain
| file size. It usually takes a few tries with 2 pass encoding to
| get an audio bitrate/downmix, video bitrate, framerate and
| resizing to find one I like. It would be great to automate
| that.
| paulmd wrote:
| The way I typically approach this personally is to have a
| batch script that kicks off a couple "trial" encodes that run
| with "medium" quality (which will run reasonably fast) and
| then once I've identified an appropriate CRF value then I run
| a final encode with "placebo" quality.
|
| Once I have identified a target CRF then I just apply that
| value to all similar files. I'm personally not concerned
| about exact size, I'm not squeezing them onto discs or
| anything, so having one file be 690mb and the next one be 695
| mb is fine.
|
| Contrary to the name, and contrary to popular belief: yes,
| placebo does still improve quality noticeably even over
| veryslow, when you are squeezing bitrate very hard. Actually
| typically you will get a noticeably smaller file than
| medium/slow (10% reduction is not atypical) and the quality
| will be better than veryslow. This applies less when you are
| giving adequate levels of bandwidth but when you are really
| squeezing the bitrate to the absolute limit (I've been known
| to use values in the CRF 31-37 range at some times to really
| go hard), going deeper into motion search yields more
| benefits. Like, you probably could still benefit from going
| even farther (placebo is just a preset tuning some motion-
| search parameters and you could tune them even higher).
|
| At a minimum, veryslow does produce very significant quality
| gains over medium even if you don't want to go all the way to
| placebo though. Worth it for archival for sure.
|
| And typically, the situation where I'm hand-tuning a file to
| hit an exact file limit... are ones where I'm seriously
| pushing the limits in terms of what I can fit into a given
| attachment-uploader file size limit or something. So when I
| am targeting a fixed file size I am almost always squeezing
| hard.
|
| There's no perfect solution to avoid the trial-and-error
| process though, imo. Automated solutions can produce
| something reasonable but not optimal in terms of exactly
| hitting your filesize limit at the maximum possible quality.
| Tuning it down to the last MB, or deciding to resize a video
| to give a bit more motion bandwidth, isn't something that
| they can generally do.
|
| Personally I don't worry about audio too much - 160kbps AAC
| or MP3 is fine and anything too far below that starts to get
| potentially noticeably poor. If something has DTS or AC3
| yeah, I'm transcoding because nothing will play that on the
| internet, but if it's reasonably close I'll just copy source
| to avoid generational losses fromt anscoding. Yeah, sometimes
| a reduction in resolution can produce big gains with little
| noticeable quality gain... and sometimes (especially with
| anime/cartoons) a high-res file has so little high-frequency
| data that going big barely affects file size at all. Tune
| mode can also help a little bit at the edges.
|
| I never mess with framerate or bit depth/color space unless I
| absolutely have to, though. Too many pitfalls there.
| teh64 wrote:
| Have you had a look at Handbrake (https://handbrake.fr/)?
|
| At least some of your requirements are directly implemented in
| Handbrake, e.g., there are different transcoding presets [0]
| and burning in subs [1]. It uses ffmpeg under the hood as well.
|
| [0] https://handbrake.fr/docs/en/1.5.0/technical/official-
| preset... [1]
| https://handbrake.fr/docs/en/1.5.0/advanced/subtitles.html
| paulmd wrote:
| Yes. I ended up abandoning handbrake for a lot of reasons.
| For a long time its libraries were horrifically out of date
| (it was many many major versions behind the x265 trunk) and I
| don't feel like its "presets"/"batch mode" works properly. I
| always felt like I was second-guessing whether my manual
| settings were getting overridden and replaced by presets when
| inserting a batch.
|
| I could have dived into the log files and looked more closely
| at what it was doing but, eh, I'm at the level where I just
| want a batch script where I can see exactly what it's doing
| upfront. If I want batching/task management that is more
| advanced than a batchfile can do I'll set up SLURM workload
| manager.
| radicality wrote:
| Not op, but I did use Handbrake multiple times, and thinking
| of just going back to cli ffmpeg. I wanted to see the exact
| incantation of ffmpeg that Handbrake issues to more easily
| switch, but from what I saw it doesn't fork into an ffmpeg
| process but probably uses the library, and it's hard to tell
| what the exact params are.
|
| My problem with Handbrake was that it wasn't correctly
| copying creation datetime/makernotes/camera info into the new
| video and I had to manually later on issue bunch of ffmpeg
| commands for copying stream metadata, at which point I might
| as well do the whole conversion directly in ffmpeg.
| cm2187 wrote:
| The thing is depend what you are trying to do. To compress
| DVD/Blurays, I find handbrake invaluable, because it will
| automatically deal all kind of weird corner cases in term
| of pixel format, image ratio, cropping, deinterlacing, etc,
| that I don't have to write in a command line on every new
| file (and every disk seems to be doing something
| different).
|
| But if you are dealing with repeatable, consistent file
| format (like files coming from the same camera), you are
| way better off going the command line route, and chances
| are the command will be pretty simple.
| aidenn0 wrote:
| Something that always frustrated me is how much better avisynth
| is than ffmpeg on pretty much every axis. Some of this is just
| because VFW puts any linux video stack look like a bit of a
| joke, but even something limited to the features internal to
| ffmpeg using the avs language would be better than this crazy
| -map -vf -af -filter_complex bag of command line options.
| motbob wrote:
| Yeah, once you get above a basic level of filter complexity,
| Vapoursynth/Avisynth become much easier to script. The
| problem is that it's hard to do the initial setup of *synth.
| dylan604 wrote:
| >Some of this is just because VFW puts any linux video stack
| look like a bit of a joke
|
| What's the joke? I thought using VFW in 2022 was pretty
| hillarious of a suggestion. Maybe you got the punchline
| confused? ;P
|
| AVISynth died to me long long ago as it was just no longer
| pratical. The work arounds to get 10bit video was never
| stable by the time I dropped it.
|
| I did enjoy the scripting aspect of things like you suggest,
| but that's meh at this point. Now that my brain has been
| rewired to think FFMPEG like, the frustration goes away. It's
| a steep hill to climb without question, but eventually, it
| just goes "click".
| aidenn0 wrote:
| 1. I suspect we have very different needs. I've never
| worked with 10 bit video, for example.
|
| 2. The closest equivalent to VFW in linux is not ffmpeg but
| gstreamer. My experience with the latter is ... not good.
|
| 3. ffmpeg is great _when it does what you need_ but VFW
| lets you draw from a vast ocean of third party plugins that
| do all sorts of niche things.
| urda wrote:
| https://github.com/EvanHahn/ffmpeg-buddy
|
| If ya can maybe help em out and send a pull request? I think
| it's a neat little app and will take a look at it myself.
| pkulak wrote:
| I just use Kden Live for anything at all complicated. It
| basically just generates an ffmpeg command anyway.
| throwaway894345 wrote:
| I'm an FFMPEG newb, but I can't find anything that handles
| subtitles correctly by default. Just leave all of the subtitles
| on (it's not like they take up any appreciable amount of space
| compared to the audio and video streams). If the output format
| requires a different type of subtitle, just convert it (rather
| than omitting the subtitle altogether). It's surprising to me
| that everyone has to learn FFMPEG in all of its complexity to
| do relatively basic things.
| [deleted]
| bambax wrote:
| > _In particular I 'm not sure how to really tell ffmpeg to
| handle multiple audio/sub streams without programmatic
| interaction_
|
| This is what gets me every time. I'm relatively proficient with
| ffmpeg (relatively!) but for the life of me I can never
| remember how to switch audio sub streams or drop some of them,
| etc.
|
| And yes, one first needs to find out what's where, but there
| are many UI tools that can do this (in addition to ffprobe).
| mdre wrote:
| Check out Hybrid, it's the most full featured GUI codec tool I
| know. Amazing tool for video pros.
| dylan604 wrote:
| Hybrid or Hybrik now owned by Dolby?
| sehro wrote:
| https://www.selur.de/ is where Hybrid can be found.
|
| Not associated, just find it easier to link to something
| useful.
| m-p-3 wrote:
| Regarding scaling while maintaining ratio, some codecs will give
| an error if you try to put a size that isn't a multiple of n, for
| example if you put -2 you'll actually have it calculate the
| appropriate multiple of 2.
| clone1018 wrote:
| I ended up making something similar (except in reverse) for the
| x264 options you can pass in:
| http://axxim.net/~clone1018/tools/x264.html
| chungy wrote:
| ffmpeg is a really powerful tool that's well worth learning. It's
| become my go to for almost every video, audio, and still image
| task.
|
| One thing that might help: ffmpeg is, in fact, the Unix
| philosophy of "do one thing and do it well", it just so happens
| that all the commands are prefixed by the ffmpeg command, but you
| can break things down really easily after that. Each codec is
| independent, mappings are independent, filters, etc.
| wingworks wrote:
| Something I don't think many talk about, the fact that ffmpeg
| can input and output images, and does it really quick.
|
| Recently I was working on processing large images (100-200MB
| per jpg) which needed a crop, some added text and "progress
| bar" for a timelapse. I started with imagemagick, it was super
| slow, so tried graphicsmagick, also slow, just somehow I
| thought, why not try ffmpeg. Man, it's night and day
| difference. It processed my images super quick (from ~30
| seconds down to ~1 second), and had surprisingly good
| documentation (compared to IM/GM), and allot of support on
| stackoverflow etc.
| hardwaregeek wrote:
| It's interesting. I've heard apocryphally that FFmpeg is used in
| many production video systems
| (https://twitter.com/id_aa_carmack/status/1258531455220609025).
| However, as far as I can tell, you can either use the quite low
| level libraries like libavfilter, or you can rely on the CLI
| tool. The former seems rather tedious; you have to set up the
| scaffolding yourself, chain all the demuxer to the filters to the
| muxer, etc. The latter is a very weird interface; you have to
| shell out to this CLI tool. Is that really the case?
| the_cat_kittles wrote:
| whats the problem with using the cli in production?
| make3 wrote:
| requires creating a separate process? requires passing the
| memory from one process to the other.. requires a filesystem
| & requires the security analysis for having production
| software interact with the file-system?
| chrisseaton wrote:
| > requires a filesystem
|
| Unix has something called pipes that lets you send data as
| 'files' but they're really supplied as a stream by another
| process.
| bityard wrote:
| Yeah, I don't really see the difference between asking a
| database administrator to be fluent in SQL and asking a video
| processing expert to be fluent in ffmpeg (or similar tools).
| Uehreka wrote:
| I've had some luck with PyAV, which I'm pretty sure is just
| some straight-up Python->C bindings (in case shelling out and
| starting another process feels too weird.
| https://pyav.org/docs/stable/
|
| However, I'd note that in my use case, I ended up going back to
| the shell after running some benchmarks and seeing that for my
| use case, I wasn't saving any performance.
| 01100011 wrote:
| Seems like this would be nice to have an an interactive shell
| script(or compiled, for cross platform support) that ships
| alongside ffmpeg...
| dontbenebby wrote:
| I wanted to make something like this (minus the gui) for a long
| time... thank you very much OP, I am bookmarking this.
| m-p-3 wrote:
| So a TUI?
| alex_duf wrote:
| So if you remove the GUI you'll only have the CLI, so what you
| want is the ffmpeg CLI?
| nvrspyx wrote:
| I'm not the parent, but not necessarily. You can have this
| same exact "GUI" implemented as a TUI, using something like
| Bubble Tea[0], Textual[1], or by hand. You'd get a similar
| experience without having to go back and forth between the
| terminal and a browser.
|
| [0]: https://github.com/charmbracelet/bubbletea
|
| [1]: https://github.com/Textualize/textual
| spinaltap wrote:
| Question: this tool offered start-time and end-time, but no
| toggle about "accurate seek"? I've always been confused about the
| `-noaccurate_seek` flag (when cutting clips with `-c copy`).
|
| I use this flag because I don't need accurate seek, but sometimes
| it works, sometimes it doesn't. When it doesn't work, there will
| be a few seconds of frozen image at the beginning of the cut.
| Don't know how to solve it.
| ThatPlayer wrote:
| Isn't that only relevant because you're using -c copy? Without
| transcoding, ffmpeg will just copy the stream from that start-
| time. But because video codecs store data as incremental
| updates to a keyframe, without transcoding, those first few
| seconds will be useless data. -noaccurate_seek looks for the
| keyframe so you do not have that useless data.
|
| Proper terms are i-frame and p-frame.
| https://en.wikipedia.org/wiki/Video_compression_picture_type...
|
| Though according to the ffmpeg docs on -ss, it should be doing
| noaccurate_seeks if you're doing stream copy.
|
| Also I'm unsure about this, but I think the audio stream can be
| cut at a different location than the video stream, leading to
| the frozen frame, and different video players seem to handle it
| differently. I've got a clip I've made, with transcoded video
| stream but copied audio stream, that is 1:06 on Firefox with
| the extra audio at the beginning, but 1:03 on VLC, MPC, Chrome,
| and desynced in Edge. Extracting the audio with ffmpeg again
| gives a time of 1:04.02 compared to a video stream of 1:03.
| btbuildem wrote:
| Last time I went down the ffmpeg man page rabbit hole was when I
| needed to vertically stack (and temporally align) feeds from
| multiple timelapse cameras to make videos for IG stories.
|
| As soon as the carefully curated string of option configurations
| went into a script, it also evaporated from my brain. Oh well..
| til next time.
| bigdict wrote:
| Looks great, now do the other million available options.
| radicality wrote:
| Kinda related, here's a few ffmpeg commands i've probably spent
| many hours getting to work just right recently (and they might
| not even the right way to do these things), perhaps someone will
| find it helpful. All of these are on a macbook.
|
| - play facetime camera (or any avfoundation camera, like a
| capture card) to mpv ffmpeg -f avfoundation
| -video_size 1920x1080 -framerate 30 -drop_late_frames true -i
| "FaceTime HD Camera" -c:v rawvideo -f matroska -r 30 - | mpv
| -profile=low-latency -untimed -
|
| - play raw video stream from the usb camlink capture card
| ffmpeg -f avfoundation -video_size 3840x2160 -framerate 23.98
| -pixel_format uyvy422 -drop_late_frames true -i "Cam Link 4K"
| -c:v rawvideo -f matroska - | mpv -profile=low-latency -untimed -
|
| - Capture video, and do live HVEC hardware encoding on apple
| hardware and save result. Control quality with q variable. q=85
| is around 250Mb/s: ffmpeg -f avfoundation
| -video_size 3840x2160 -framerate 23.98 -i "Cam Link 4K" -c:v
| hevc_videotoolbox -q:v 85 -r 23.98 -tag:v hvc1
| <filename>_x265.mp4
|
| - Use named pipe with mkfifo to play a stream. Sometimes this
| produces less input lag than other methods.
| mkfifo /tmp/fifo1 cat /tmp/fifo1 | mpv -profile=low-latency
| -untimed - ffmpeg -f avfoundation -video_size 1920x1080
| -framerate 30 -drop_late_frames true -i "FaceTime HD Camera" -c:v
| rawvideo -f matroska -r 30 - > /tmp/fifo1
| Tijdreiziger wrote:
| The first two might be possible with just MPV. Relevant thread
| on /r/GenkiLab:
| https://www.reddit.com/r/GenkiLab/comments/mzw9a2/lower_late...
| kosolam wrote:
| Very cool. I would love to see something like that with more
| ffmoeg options
| dusted wrote:
| Neat tool and a fine introduction to doing very basic things with
| ffmpeg. A tool I'd find interesting and useful is one that lets
| me graphically do everything with the advanced filter graph that
| can be done with the commandline, in an easy and intuitive way
| (spoiler alert: extremely hard to impossible task)
| linesinthesand wrote:
| A nice start, but definitely needs some complex_filter options
| Nathanael_M wrote:
| The first time I heard about ffmpeg was last night when I had to
| concatenate a few hundred thousand videos. So slick, so quick,
| but it took a bit to figure out the command structure. Guess I
| found this 12 hours too late, haha!
| cedricd wrote:
| A few hundred thousand videos? I'm super curious what your use
| case was. I really can't imagine the scenario for this :)
| geraldwhen wrote:
| I'm guessing security camera motion detection footage for
| archive.
| aasasd wrote:
| Pfah, if my wishes were so simple I'd barely need the man page.
| xigency wrote:
| I would use this tool if it had these options:
|
| - x264 settings as well as copy video codec
|
| - aac re-encoding settings
|
| - mixing 5.1 to 2.1 audio
|
| - adding multiple subtitles
|
| - rendering hard subtitles
|
| I was just using ffmpeg to convert videos to watch on the TV
| and I needed all of those.
| victorwestmann wrote:
| This is as simple as revolutionary. Thank you so much for putting
| this together!
| 1970-01-01 wrote:
| See also
|
| https://github.com/FHPythonUtils/Cli2Gui/
|
| It's 2022, shouldn't CLI to GUI conversion be an automatic and
| core feature of every OS by now?
| doersino wrote:
| I see that we're sharing our lists of magical FFmpeg incantations
| - here's mine: https://github.com/doersino/ffmpeg-koraktor
| VyseofArcadia wrote:
| Why is this a webpage? It would be a little more useful as a
| local program that actually just runs the command for you instead
| of having to copy-paste everything to your terminal.
| hbn wrote:
| A webapp is automatically cross-platform, and also installing a
| program requires more buy-in from a user. I wouldn't have
| played around with this if I had to vet whether it was from a
| trustworthy source and install it to my machine.
| Hello71 wrote:
| Selecting both scale and rotate options results in:
| Multiple -filter, -af or -vf options specified for stream 0, only
| the last option '-filter:v transpose=1' will be used.
|
| -vn, -an, -ss, and -to are specified as output rather than input
| options, which are much more efficient.
| dylan604 wrote:
| just from this comment, using -filter_complex seems like a much
| better option. in fact, on past experience, I couldn't see
| myself building an FFMPEG command builder and not use
| filter_complex.
| runlevel1 wrote:
| Some codecs, like h264, require the width and height be divisible
| by 2. Scaling with -1 will sometimes fail because of that.
|
| If you use -2 instead it will adjust so that it is even.[^1]
|
| For example: ffmpeg -i input.mp4 -vf
| scale=720:-2 output.mp4
|
| [1]: https://trac.ffmpeg.org/wiki/Scaling#KeepingtheAspectRatio
| hombre_fatal wrote:
| It reminds me of a similar quirk where scaling by a single
| pixel _extra_ in either dimension can introduce disproportional
| blurriness, so one solution is to pad by a 1px wide border on
| the would-be odd dimension.
|
| This has saved me a lot:
| https://stackoverflow.com/a/53024964/511200
| misil wrote:
| I think I once read a comment on here that the command-line
| parsing logic of ffmpeg is Turing-complete. It's probably telling
| that I can't remember if that was meant as a joke or to be taken
| seriously. And I say this with nothing but admiration for the
| tool.
| gosub wrote:
| Can I have magit for ffmpeg and openssl, please?
| butz wrote:
| What about a decoder, to parse ffmpeg command from my old bash
| file to tell exactly what it is doing, maybe even suggesting some
| optimizations?
___________________________________________________________________
(page generated 2022-06-01 23:00 UTC)