FFmpeg vs. MeGUI? (What's the difference?)

[Altabyte]

Sorry to bring this up, however I've been wondering for a while now and I haven't seemed to find an answer anywhere. All I know is that both software can convert and encode videos. The problem is that I can't tell which is better. I have moderate experience with FFmpeg and it has served me very well, the thing is that I see a bunch of people using MeGUI and I just don't get the difference. Also, I'd like to note that I have no experience with MeGUI. Is one just a command-line tool and the other a gui? Is one better than the other? If there's any reason why I should be using one over the other or if there are any key differences between the two, I'd greatly appreciate it if you could tell me. Thanks.

[KarMa]

Megui is a gui for a bunch of different things, most importantly it's a gui for avisynth which is used to filter video and then served to a video/audio codec. Video codecs Megui supports are x264, x254, Xvid. For audio it supports NeroAAC, QAAC, FLAC, Opus, and some other things. Megui is also a gui for MP4Box and MKVMerge.

My experience with ffmpeg is limited but ffmpeg is a self contained video/audio encoder, muxer, and filter. Best part about it is that it can pretty much take in any video/audio format and output it to anything you want for the most part. Just looked it up, but it seems like ffmpeg supports aivsynth if the compiled version has it enabled.

Is one just a command-line tool and the other a gui?

Both of them seem to use much of the same codecs and muxers. Just one is a self contained cli (ffmpeg) and the other is a gui that can have its pieces swapped out (megui).

[jagabo]

Basically, MeGUI is a GUI for most of the same A/V libraries used by ffmpeg.

[remanyao]

(...) Just looked it up, but it seems like ffmpeg supports aivsynth if the compiled version has it enabled.

Always it's enabled for Windows:

FFmpeg can read AviSynth scripts as input. To enable support, pass --enable-avisynth to configure. The correct headers are included in compat/avisynth/, which allows the user to enable support without needing to search for these headers themselves.

For Windows, supported AviSynth variants are AviSynth 2.6 RC1 or higher for 32-bit builds and AviSynth+ r1718 or higher for 32-bit and 64-bit builds.

https://ffmpeg.org/general.html#AviSynth

[KarMa]

(...) Just looked it up, but it seems like ffmpeg supports aivsynth if the compiled version has it enabled.

Always it's enabled for Windows:

http://forum.doom9.org/showthread.php?p=1673972#post1673972

[poisondeathray]

If you're happy with ffmpeg keep on using it

x264CLI support all switches. ffmpeg libx264 lacks a few but has most of the important ones

2 scenarios where you might prefer to use x264CLI (not necessarily megui, you can use the commandline or another GUI) instead of ffmpeg libx264, is blu-ray and certain full range video cases

--qpfile specifies user override options for frametype placement. A qpfile is commonly used to place IDR frames for chapters in blu-ray, or seekpoints or cue points in interactive flash videos. (EDIT: earlier I wrote --zones , but apparently zones are now supported in ffmpeg libx264)

ffmpeg libx264 doesn't support x264 --range --input-range flags. Instead, full range in ffmpeg is handled upstream by -pix_fmt (e.g. -pix_fmt yuvj420p for 4:2:0 full range, which not only converts to full range but flags as full range in libx264). But some cases where you have unflagged input full range video (ffmpeg "thinks" it's normal range video), this causes the levels to go beyond legal limits, thus wrong output levels . With x264, this is handled properly because no actual Y' range conversion is done when you specify full for input and output.

[remanyao]

(...) Just looked it up, but it seems like ffmpeg supports aivsynth if the compiled version has it enabled.

Always it's enabled for Windows:

http://forum.doom9.org/showthread.php?p=1673972#post1673972

You look to the experts:



https://ffmpeg.zeranoe.com/builds/

Obviously, you must have Avisynth installed on your system and should know how to use and should know how to use FFMPEG command line.
Otherwise, use Megui that does it for you.

[SameSelf]

I have a hard time getting ffmpeg libx264 to max out my cpu while x264 cli never seems to have a problem. Additionally, using a gui, e.g. MeGUI, vs a cli just adds unnecessary overhead to your encodes. When I am s/w encoding to h.264, I want my cpu at or near 100%. Also, it is a cinch downloading the latest builds of x264 to ensure that you are always running the most up to date version. How quickly do the latest builds of libx264/x264 get packaged into the gui's? Can you even be certain which one they are using? There is value in being fluent in a cli. A ton of statistics are reported in the cmd window. Taking the time to read these can point out issues to which you would otherwise be oblivious. Using a gui means you never go any deeper than what is presented to you in the pretty windows. A cli allows you to go as deep as you choose.

[pandy]

ffmpeg libx264 doesn't support x264 --range --input-range flags. Instead, full range in ffmpeg is handled upstream by -pix_fmt (e.g. -pix_fmt yuvj420p for 4:2:0 full range, which not only converts to full range but flags as full range in libx264). But some cases where you have unflagged input full range video (ffmpeg "thinks" it's normal range video), this causes the levels to go beyond legal limits, thus wrong output levels . With x264, this is handled properly because no actual Y' range conversion is done when you specify full for input and output.

It is partially correct as yuvj420 seem to be not best way to feed full range with libx264 as libx264 will complain - IMHO better is to use:

ffmpeg.exe -color_range 2 -i filename -vf scale=iw:ih:sws_flags=neighbor:sws_dither=0:in_range=1:out_range=1 -c:v libx264 -x264opts 'fullrange=off' [ or on - depends on used quantization range] -color_range 2 -pix_fmt yuv420p

[poisondeathray]

It is partially correct as yuvj420 seem to be not best way to feed full range with libx264 as libx264 will complain - IMHO better is to use:

ffmpeg.exe -color_range 2 -i filename -vf scale=iw:ih:sws_flags=neighbor:sws_dither=0:in_range=1:out_range=1 -c:v libx264 -x264opts 'fullrange=off' [ or on - depends on used quantization range] -color_range 2 -pix_fmt yuv420p

Yes, this works.

[hello_hello]

Additionally, using a gui, e.g. MeGUI, vs a cli just adds unnecessary overhead to your encodes. When I am s/w encoding to h.264, I want my cpu at or near 100%. Also, it is a cinch downloading the latest builds of x264 to ensure that you are always running the most up to date version. How quickly do the latest builds of libx264/x264 get packaged into the gui's? Can you even be certain which one they are using? There is value in being fluent in a cli. A ton of statistics are reported in the cmd window. Taking the time to read these can point out issues to which you would otherwise be oblivious. Using a gui means you never go any deeper than what is presented to you in the pretty windows. A cli allows you to go as deep as you choose.

You have no idea what you're talking about when it comes to MeGUI.

MeGUI just sends the Avisynth scripts you create to the command line x264 encoder using a command line. How does that add unnecessary overhead to your encodes compared to doing it yourself? If you shut MeGUI down while an encode is running it'll still complete. No GUI overhead required.

MeGUI comes as a package but it's a GUI packaged with individual components. If you set it to update itself via the "development update server" you generally get new components very soon after they are released. It's not like Handbrake where you need to update the entire program to get a newer version of the x264 encoder, and because MeGUI uses individual components such as the standard x264 CLI encoder, as a rule it's easy enough to replace them with any version you want to use. You know which version of a component you're using because MeGUI's updater tells you.

All the encoder statistics (standard error stream) are written to MeGUI's log file. You can read them there quite easily. Along with MediaInfo details and a bunch of other stuff, such as every command line MeGUI uses. Not only does MeGUI not hinder you learning, it can help. Sometimes when I want to create a script but can't remember the best way.... ie to resample audio when re-encoding.... I load an audio file into MeGUI, get it to resample while re-encoding, start the encode, abort it, then check the log file for the script MeGUI created.
MeGUI does help create Avisynth scripts for video encoding and that enables people with no Avisynth experience to encode via Avisynth, but MeGUI also makes it easy to modify scripts, or you can create your own for encoding. Using MeGUI you can go as shallow or deep into the CLI as you like. I tend to load jobs into MeGUI's job queue so I can start it running and walk away, or to ensure there's always two simultaneous encodes running etc, but you could use MeGUI to create a script and send it to the CLI encoder yourself.

The main reason I use MeGUI, is aside from it helping to automate some of the process such as indexing files and creating scripts, is I spend a fair amount of time experimenting with filtering when I encode, and MeGUI's preview is quite handy for previewing that before I start encoding. I prefer it to AvsPMod. Once I've got something I like I save the script and open it with MPC-HC for previewing on the TV before I commit to encoding. I don't open it via a command line.

Please refrain from commenting on a program if you've never used it.

Not that I have any reason to recommend not using ffmpeg or the command line for encoding. In fact I've often wished MeGUI's encoder configurations included a full command line option so it could encode with any command line encoder. Much like foobar2000 can be configured to use any audio command line encoder. You're still using the command line, only via the convenience of a GUI. Currently MeGUI has individual encoder configurations for the video and audio encoders it supports. A "generic" command line encoder configuration would be nice. I might pop over to SourceForge and make that a feature request.

Edit: You don't know if you don't ask....... #599 "Generic" command line encoder configuration

[KarMa]

I have a hard time getting ffmpeg libx264 to max out my cpu while x264 cli never seems to have a problem. Additionally, using a gui, e.g. MeGUI, vs a cli just adds unnecessary overhead to your encodes. When I am s/w encoding to h.264, I want my cpu at or near 100%. Also, it is a cinch downloading the latest builds of x264 to ensure that you are always running the most up to date version. How quickly do the latest builds of libx264/x264 get packaged into the gui's? Can you even be certain which one they are using? There is value in being fluent in a cli. A ton of statistics are reported in the cmd window. Taking the time to read these can point out issues to which you would otherwise be oblivious. Using a gui means you never go any deeper than what is presented to you in the pretty windows. A cli allows you to go as deep as you choose.

As long as I don't use anything like QTGMC(single threaded) or of a similar bottleneck in avisynth, I have no problem maxing out my CPU with x264 via Megui. Megui has an automated update system where you can choose to download the latest builds for x264, x265, mkvmerge, qaac, l-smash works, and so on. But they only tend to notify you of updates for "stable" releases. But since Megui is NOT self contained like ffmpeg, you can just go to the installed location of Megui and swap out the cli of x264 for the very latest version if you have it, pretty simple. I did this for x265 as they were pretty slow with the updates on the Megui servers until recently. As far as stats, none of those stats are lost and can be seen in the log tab of Megui.

You seem to think Megui is on the same par as Handbrake.

[hello_hello]

In addition to what KarMa said, I use QTGMC in scripts I create with MeGUI regularly. I don't think there's any reason you couldn't use a multithreaded Avisynth with MeGUI (and as MeGUI lets you create script templates so you could create templates for MT encoding), and I'm pretty sure I did at one stage, but these days I stick with single threaded Avisynth. That's why I mentioned running two encodes simultaneously in my previous post. If scripts with QTGMC or other slow filtering bottleneck the process and only let the CPU run at around 50% (for example), I set MeGUI's job queue to run them two at a time.

The highlighted line shows the massive amount of overhead required by MeGUI for encoding with the CLI x264 encoder.

[SameSelf]

to the OP,this forum is a poisonous, polluted place where a few people rule and work hard to shout down others' experiences. you gotta test stuff yourself to know what works and what doesn't. don't trust anyone. just test stuff yourself. i hate guis. i shared some of the reasons why. don't take my word or anyone's word for it. just test stuff yourself.

[hello_hello]

to the OP,this forum is a poisonous, polluted place where a few people rule and work hard to shout down others' experiences. you gotta test stuff yourself to know what works and what doesn't. don't trust anyone. just test stuff yourself. i hate guis. i shared some of the reasons why. don't take my word or anyone's word for it. just test stuff yourself.

Another off topic rant from the forum "can't be wrong" who's not used the software in question, but decided to accuse others of working hard to shut down his "experience". Not with the software in question though.... must be something else.
Selfie has once again ignored every single point offered by those disputing his nonsense claims to instead have a rant. Don't take the advice of anyone who's used the software in question, if it contradicts sameself who hasn't, further testing must be required. Selfie can't be wrong.

[KarMa]

i hate guis.

Coming from the same guy who hates on non-GUI Avisynth NLE in favor of Vegas, Adobe Premier, or any other expensive GUI based NLE.

[SameSelf]

Coming from the same guy who hates on non-GUI Avisynth NLE in favor of Vegas, Adobe Premier, or any other expensive GUI based NLE.

some people prefer being lawyers than video experts. OK counsel, what I meant to say was I hate guis when all i need to do is encode a final render. A gui is like those who insist on checking a bag when all they need is a carry-on. You all good now?

[hello_hello]

....what I meant to say was I hate guis when all i need to do is encode a final render.

Can you clarify? Are you saying the only thing MeGUI can be used for is a final render, or are you still trying to claim if you use MeGUI for a final render, there's extra overhead when encoding?

"A" final render? What's that like? I currently have 75 scripts sitting in MeGUI's job queue waiting for a turn at being encoded. And what's batch encoding via the command line like? Not that I do much "batch" encoding as such. I create each and every script individually and add them to the queue, generally while there's encodes already running. "A" final render....



It's sad that of all the points made, that's the only one you chose to acknowledge. You still have nothing that's MeGUI specific. Just more meaningless generalisations.

A gui is like those who insist on checking a bag when all they need is a carry-on.

If all you ever use MeGUI for is previewing the scripts you create yourself (and you told someone in a thread very recently they need to use a GUI such as VirtualDub or AvsPmod to "debug" scripts) and send them to a command line encoder, you're only using MeGUI's "carry-on" abilities. Except it gives you more/easier control over the number of simultaneous encodes and the order in which they run etc. What's to hate about that aside from your ignorance?

[_Al_]

flame!

ffmpeg gui's use ffmeg command line, major advantege is, it just loads files with different formats easy, Megui uses command lines for encoding video, audio, stores those files in temp directory, then at the end there is muxing into a container, and Megui uses avs script for loading file, that could be a problem, it complicates things, but if handled well, suddenly it can turn into an advantage

some two cents:

--command lines prevent mistakes and headaches, because after just looking at the line for 5sec, it is clear what was really set, on the other hand those settings could be hidden in GUI's and sometimes it takes a time realizing that, like in Megui you set interlace flags for one video and forgetting about it, then encoding a progressive content with interlace flag etc. But of course it has a learning curve, not many would go thru that

--very small number of users actually make that switch to a command line because it is quite hard, I remember vividly, long time ago, staring at the avisynth script trying to understand how that could actually be a video ...

--or not realizing tha one can have command lines stored in txt files, make a change, and just pasting this in cmd prompt or creating simple BAT file script, no need to type things all the time. Also if there is a previous background (school, programing etc.) it is pretty easy but 99.9% of folks would not bother to go that way.

--also cmd prompt window supports drag and drop in windows so files have proper paths right away and it could be really long path ...

[hello_hello]

I find AnotherGUI quite handy for use with ffmpeg. In a way it's kind of like a compromise between using the command line yourself and using a GUI. You still have to specify the command line but the GUI stores it for you as a preset and fills in the input and output file names etc as appropriate.

My number one use for AnotherGUI these days is probably remuxing with ffmpeg, because you can drop a bunch of files onto the GUI and click go..... which I find handy because as long as the video and audio are supported by the output container, the source containers can be a mixture of anything ffmpeg supports. Mind you the same would apply when converting too.

It seems logical when using an operating system with GUI support to take advantage of a little GUI help if it's available. Selfie would probably hate it.

[KarMa]

--command lines prevent mistakes and headaches, because after just looking at the line for 5sec, it is clear what was really set, on the other hand those settings could be hidden in GUI's and sometimes it takes a time realizing that, like in Megui you set interlace flags for one video and forgetting about it, then encoding a progressive content with interlace flag etc. But of course it has a learning curve, not many would go thru that

I'm not really sure how you would accidentally deinterlace something. As when you use the avisynth script creator (Ctrl + R shortcut) it starts you off with a blank slate, unless you go out of your way to make a preset that inserts things automatically. So maybe make a deinterlace preset that uses yadif, and then another preset that uses qtgmc. But it will probably take awhile before a new user starts using that, at least that it is how it happened with me.

Probably the biggest gripe I have about the GUI in MeGUI is actually kind of the opposite of your example. Instead of it adding stuff, it will tend to remove stuff in favor of whatever the GUI is set to. So if the video set in the GUI to resize to 1280x720 on the I/O tab, but I decide to change it to 1280x480 in the script tab, then that 1280x480 setting is vulnerable to being changed back to the 1280x720 if I touch any of the settings on the I/O or Filter tabs. So I pretty much use the GUI part to quickly do what I want, then change the script to the final settings last.

[_Al_]

Interlace flag in encoder, not deinterlace in script. Video coming out of avs script could be interlaced or progressive, but that appropriate flag for interlaced or progressive video is buried in Megui settings. Especially when testing, you change things all the time, so it is clickity-clickety using mouse, there is always something forgotten that should be changed ...

Workflows could differ from person to person, for example, I'd feed MeGUI with ready avs script directly. My scripts would be created just by dropping video into BAT file etc. So naturally, next step is creating batch script that encodes it all etc.

[hello_hello]

Probably the biggest gripe I have about the GUI in MeGUI is actually kind of the opposite of your example. Instead of it adding stuff, it will tend to remove stuff in favor of whatever the GUI is set to. So if the video set in the GUI to resize to 1280x720 on the I/O tab, but I decide to change it to 1280x480 in the script tab, then that 1280x480 setting is vulnerable to being changed back to the 1280x720 if I touch any of the settings on the I/O or Filter tabs. So I pretty much use the GUI part to quickly do what I want, then change the script to the final settings last.

I know what you mean, although I'm not sure it wouldn't make sense for MeGUI not to re-write the resizing in the script if you change it in the script creator, however it'd be nice if it could change just that and leave everything else alone (rather than rewrite the entire script every time you change something in the GUI).

I think the only way around the problem would be to create a script template that prevents MeGUI from adding anything to the script. You could still use the script creator to calculate cropping and resizing etc but you'd have to manually write the script. I don't know if there's a simple solution for that one.... aside copying the script contents to clipboard before changing anything with the GUI so you can paste them back again. I'm pretty much in the habit of doing that.

My biggest script creator annoyance is the video in the preview displaying according to frame number. That means whenever you add anything to a script that changes the frame count (ie IVTC) and refresh the preview it jumps to a different location in time, and that goes hand in hand with your gripe relating to making changes in the GUI. It drives me nuts so I use MPC-HC for previewing more than I otherwise would. After opening a script with MPC-HC, Ctrl+E reopens it to the same moment in time again no matter how much the total frame count changed. I added a feature request for that one a little while back. You can only hope..... https://sourceforge.net/p/megui/feature-requests/584/

[KarMa]

this forum is a poisonous, polluted place where a few people rule and work hard to shout down others' experiences.

Megui just crashed on me while encoding with x265, which reminds me. x265/x264 will continue to run, along with the avisynth filters, with Megui completely closed. However when it's done encoding it won't be muxed into an MKV or MP4, as the GUI won't be there to drive that action. But easy to do yourself.

If you closed Handbrake or Handbrake crashed on you, that encoding would be halted.

[hello_hello]

Megui just crashed on me while encoding with x265, which reminds me. x265/x264 will continue to run, along with the avisynth filters, with Megui completely closed. However when it's done encoding it won't be muxed into an MKV or MP4, as the GUI won't be there to drive that action. But easy to do yourself.

If you closed Handbrake or Handbrake crashed on you, that encoding would be halted.

I have MeGUI running 24/7 for lengthy periods, during which time I create new scripts and add them to the job queue etc. As a result, I tend to cause MeGUI to crash while an encode is running fairly regularly.... almost daily.... no that's probably not accurate. Sometimes I can cause it to crash several times a day.
MeGUI won't let you close it if it's running an encode (I have to use the three finger salute to end the MeGUI.exe process on XP). Which I find a tad ironic, because when MeGUI thinks it's crashed, there's no "continue anyway" option in the error message pop-up. I submitted a feature request to add a "continue anyway" option, because in my experience most of the time MeGUI says it's crashed it's still running normally, but there's currently no way to get rid of the "MeGUI needs to close" error message without closing MeGUI. It's always on top and can't be minimised.

KarMa... I had some thoughts regarding custom Avisynth filters, in respect to adding them to a script more easily and preventing them from being erased when MeGUI re-writes the script because you've changed something in the GUI. The idea involves the script creator having drop down lists for custom filtering, and to enable/disable them as you can with the current filters. They'd probably have to be added in a way similar to how StaxRip does it.

I submitted a fairly lengthy feature request. I don't know if it'll ever happen, but I thought you might might be able to think of some additional ideas, or a better way to implement parts of it etc. https://sourceforge.net/p/megui/feature-requests/604/

Do use Trim() in scripts regularly for using different filtering in sections of the script. I tend to use it that fairly regularly. The script I created today includes this:

Trim(2045,2314).rm_logo(logomask="D:\HS 5.bmp", loc="BR", mode="Both", cutwidth=272, cutheight=144, percent=100, AlphaToRepair=220)\
++Trim(2315,2935).crop(132, 0, -132, -148).Spline36Resize(1280,720)\
++Trim(2936,22561).rm_logo(logomask="D:\HS 5.bmp", loc="BR", mode="Both", cutwidth=272, cutheight=144, percent=100, AlphaToRepair=220)\
++Trim(22562,22748).crop(204, 0, -202, -228).Spline36Resize(1280,720)\
++Trim(22749,67959)

The problem is, it gets pretty fiddly when you're adding lots of Trims(). AvsPMod slows to a crawl as the size of the script increases to it's not at option. My current record is a little over 100 Trim()s in a script in order to pan and scan a 4:3 video to 16:9. I won't do that again in a hurry, but there's got to be an easier way.
Often I create a basic script to encode, then open it with the AVS Cutter and set the "Cut points" where I know the filtering will change. When it's done I add the appropriate filtering to each Trim() manually. It can get messy very quickly with lots of Trim()s in a script if you're not careful.
The best method I've thought of so far would be to give MeGUI the ability to add custom stuff to each Trim(). You'd have to type that in as you go, but at least itt cuts down on a step. MeGUI can currently add fades/disolves to Trim()s so I assume custom things wouldn't be a huge leap, but do you have any better ideas?