7 ms·

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 app

by paulmd 4y ago

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 4y ago
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.
- DANK_YACHT 4y ago
  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.
  - dylan604 4y ago
    ^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.
    - deleted 4y ago
      [deleted]
    - DANK_YACHT 4y ago
      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 4y ago
      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.
res0nat0r 4y ago
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 https://github.com/kkroening/ffmpeg-python
teh64 4y ago
Have you had a look at Handbrake (https://handbrake.fr/ 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-presets.html https://handbrake.fr/docs/en/1.5.0/technical/official-preset... [1] https://handbrake.fr/docs/en/1.5.0/advanced/subtitles.html https://handbrake.fr/docs/en/1.5.0/advanced/subtitles.html
- radicality 4y ago
  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 4y ago
    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.
    - orlp 4y ago
      My main gripe with Handbrake is how annoying it is to trim a video. There's no preview of when the trim happens. And for some unknown reason it defaults to a chapter range rather than seconds or frames for trimming...
aidenn0 4y ago
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.
- dylan604 4y ago
  >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 4y ago
    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.
    - dylan604 4y ago
      I didn't mean for anything to come off as snobby/leetish. 1)yes, if you're not needing 10bit, then AVISynth is fun and does some amazing things. Even it's features of doing technical restoration were useful, but once you step into professional, the 8bit only really holds things back and it was time to move on. FYI, a lot of the AVISynth filters are now available in FFMPEG! 2)gstreamer compared to ffmpeg to me personally is like comparing GIMP to Photoshop (dropping commercial vs FOSS). Yes, GIMP can do nice things, but Photoshop does what I need and I know how to make it do it. No questions asked. Muscle memory. I'm at that point with FFMPEG. 3)I'm long past trying to do creative things CLI that those 3rd party plugins allowed. I'm utilitarian with workflows and need to churn it out, so ffmpeg plugs in the holes as if it were designed for it ;-) If I'm going creative, I'm in a nice UI and doing things. However, I'm not afraid to use CLI to generate some content to messing with later in a more interactive environment.
bambax 4y ago
> 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).
SomeHacker44 4y ago
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 4y ago
  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.
pkulak 4y ago
I just use Kden Live for anything at all complicated. It basically just generates an ffmpeg command anyway.
urda 4y ago
https://github.com/EvanHahn/ffmpeg-buddy 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.
cm2187 4y ago
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.
mdre 4y ago
Check out Hybrid, it's the most full featured GUI codec tool I know. Amazing tool for video pros.
- sehro 4y ago
  https://www.selur.de/ https://www.selur.de/ is where Hybrid can be found. Not associated, just find it easier to link to something useful.
- dylan604 4y ago
  Hybrid or Hybrik now owned by Dolby?
elesiuta 4y ago
> 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 https://github.com/chriskiehl/Gooey
throwaway894345 4y ago
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 4y ago
  [deleted]
- giantrobot 4y ago
  Subtitles are not a "basic thing". There's several formats of subtitles and even multiple ways to associate them with a video file. Some formats are embedded and others are sidecar files. Different file containers have different limitations on the subtitle formats they support. Just because a subtitle is ostensibly "text" doesn't automatically make them basic.
  - throwaway894345 4y ago
    I am aware that subtitles aren’t “merely text” and that different container formats constrain the subtitle format and number of tracks and so on. Still, this is simple compared to much of the stuff we use software for. Complexity abounds everywhere and yet lots of software manages to bring order to the chaos. There’s no reason this shouldn’t also apply to subtitles. A trivial example is to try to convert the subtitles rather than defaulting to no subtitles (Handbrake). Another trivial improvement would be warning that the subtitles can’t be brought over to the container format before the 20 hour transcode rather than letting users find out after that their subtitles weren’t converted. This isn’t rocket science.

by paulmd 4y ago

dylan604 4y ago

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.

DANK_YACHT 4y ago
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.
- dylan604 4y ago
  ^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.
  - deleted 4y ago
    [deleted]
  - DANK_YACHT 4y ago
    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 4y ago
    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.

res0nat0r 4y ago

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 https://github.com/kkroening/ffmpeg-python

teh64 4y ago

Have you had a look at Handbrake (https://handbrake.fr/ 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-presets.html https://handbrake.fr/docs/en/1.5.0/technical/official-preset... [1] https://handbrake.fr/docs/en/1.5.0/advanced/subtitles.html https://handbrake.fr/docs/en/1.5.0/advanced/subtitles.html

radicality 4y ago
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 4y ago
  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.
  - orlp 4y ago
    My main gripe with Handbrake is how annoying it is to trim a video. There's no preview of when the trim happens. And for some unknown reason it defaults to a chapter range rather than seconds or frames for trimming...

aidenn0 4y ago

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.

dylan604 4y ago
>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 4y ago
  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.
  - dylan604 4y ago
    I didn't mean for anything to come off as snobby/leetish. 1)yes, if you're not needing 10bit, then AVISynth is fun and does some amazing things. Even it's features of doing technical restoration were useful, but once you step into professional, the 8bit only really holds things back and it was time to move on. FYI, a lot of the AVISynth filters are now available in FFMPEG! 2)gstreamer compared to ffmpeg to me personally is like comparing GIMP to Photoshop (dropping commercial vs FOSS). Yes, GIMP can do nice things, but Photoshop does what I need and I know how to make it do it. No questions asked. Muscle memory. I'm at that point with FFMPEG. 3)I'm long past trying to do creative things CLI that those 3rd party plugins allowed. I'm utilitarian with workflows and need to churn it out, so ffmpeg plugs in the holes as if it were designed for it ;-) If I'm going creative, I'm in a nice UI and doing things. However, I'm not afraid to use CLI to generate some content to messing with later in a more interactive environment.

bambax 4y ago

> 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).

SomeHacker44 4y ago

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 4y ago
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.

pkulak 4y ago

I just use Kden Live for anything at all complicated. It basically just generates an ffmpeg command anyway.

urda 4y ago

https://github.com/EvanHahn/ffmpeg-buddy 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.

cm2187 4y ago

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.

mdre 4y ago

Check out Hybrid, it's the most full featured GUI codec tool I know. Amazing tool for video pros.

sehro 4y ago
https://www.selur.de/ https://www.selur.de/ is where Hybrid can be found. Not associated, just find it easier to link to something useful.
dylan604 4y ago
Hybrid or Hybrik now owned by Dolby?

elesiuta 4y ago

> 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 https://github.com/chriskiehl/Gooey

throwaway894345 4y ago

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 4y ago
[deleted]
giantrobot 4y ago
Subtitles are not a "basic thing". There's several formats of subtitles and even multiple ways to associate them with a video file. Some formats are embedded and others are sidecar files. Different file containers have different limitations on the subtitle formats they support. Just because a subtitle is ostensibly "text" doesn't automatically make them basic.
- throwaway894345 4y ago
  I am aware that subtitles aren’t “merely text” and that different container formats constrain the subtitle format and number of tracks and so on. Still, this is simple compared to much of the stuff we use software for. Complexity abounds everywhere and yet lots of software manages to bring order to the chaos. There’s no reason this shouldn’t also apply to subtitles. A trivial example is to try to convert the subtitles rather than defaulting to no subtitles (Handbrake). Another trivial improvement would be warning that the subtitles can’t be brought over to the container format before the 20 hour transcode rather than letting users find out after that their subtitles weren’t converted. This isn’t rocket science.