MeGUI - mencoder x264/snow/mpeg4/XviD GUI with AAC encoding and MP4 output

[r0cket]

It's just that black on white looks better than black on gray, and it improves readability.

So you can't have it read only with usual colors in that designer? Well, what can I say...

There are all the x264 options exposed

Then why do people ask for more (additional command line parameters)?

You cannot have all the options in a GUI, or it'll be just as complex as ffdshow

You can if you add another tab with 'Enable advanced options'-or-something-like-that checkbox and if the user leaves it unchecked, use the default values for that options.

And if you read my comment about commandlines again, and really think!!! about it a bit, you'll see that there's a very basic problem when commandline and GUI parameters don't match. Feel free to add a reverse commandline -> GUI fields lookup when I release the sources next week-end.

Not a .NET programmer really. And I wasn't talking about that. I'm against any command line in a GUI (for debugging and preview - it's ok).

But anyways, if you say you have all options exposed... I'll just shut up

[celtic_druid]

Revision 90:
r72 broke B-frames without intra4x4. fixed.

Guess that is the fix?

[JoeBG]

Originally posted by celtic_druid
Revision 90:
r72 broke B-frames without intra4x4. fixed.

Guess that is the fix?

So b-frames are working now? I just have to take your new mencoder? and choose 4x4mv in the GUI? ?

[celtic_druid]

My most recent mencoder compile uses r88/89 of x264 and I have no idea if r90 fixes your problem in particular.

I did put up r90 x264 commandline and VFW though. Not sure when I will do new mplayer compiles.

[Doom9]

So you can't have it read only with usual colors in that designer? Well, what can I say...

Sure you can.. you're reading way too much into this. By default a textbox can be written into. It's easy to see a problem if you can see the commandline that's being executed. That's all there is to it. I didn't plan or not plan to make the commandline editable and use those edited values for encoding, I didn't even think about that, let alone that you can edit the textbox. But just to make this clear I'll make the commandline textbox read-only in the future so that nobody will get any ideas anymore.

Then why do people ask for more (additional command line parameters)?

Those are mencoder and avs2yuv switches.. the GUI exposes every single x264 parameter. And I do not call the GUI an mencoder GUI after all.. it's created for a very specific purpose: enable encoding using open source codecs that I feel do not have a usable GUI. As it so happens, the x264 VfW came around the same time, so basically I could drop x264 support now, but seeing that some people use the GUI I'll just keep it.
There is a GUI that exposes the lavc MPEG-4 encoder (see initial post), though it focuses more on mencoder parameters. I'm an AviSynth -> whatever GUI so I focus purely on codec settings and just use a minimal set of core mencoder switches.

You can if you add another tab with 'Enable advanced options'-or-something-like-that checkbox and if the user leaves it unchecked, use the default values for that options.

Take a look at the mencoder manpage then revise your statement. ffdshow only exposes all codec parameters, it is already way overloaded, add all the mencoder switches to that (there's a lot of input, preprocessing and filtering stuff possible), you have something that's simply not manageable.

So, if you like more codec parameters (lavc mpeg-4 only), more mencoder switches, you either prove to me that it'll improve usability, or you wait for next Sunday and add it on your own.

Here are a few things I will not do:
More codecs (Snow will come, and if mencoder ever gets Theora or Dirac output I'll add those as well but I have no interest in any other codec and XviD already has its own VfW interface)
mencoder input switches (different input types, range selections, resizing, filtering, the works)
all lavc mpeg-4 settings

@akupenguin: are there certain settings you could recommend for a first pass turbo switch?

[JoeBG]

Originally posted by celtic_druid
My most recent mencoder compile uses r88/89 of x264 and I have no idea if r90 fixes your problem in particular.

I did put up r90 x264 commandline and VFW though. Not sure when I will do new mplayer compiles.

First of all I have to wait for a lower traffic on your site to get your newest compiles of nearly everything. But this affords the opportunity to say thanks for your amazing work. Don´t know the right words, hope you´ll understand.

[JoeBG]

Originally posted by Doom9
As it so happens, the x264 VfW came around the same time, so basically I could drop x264 support now, but seeing that some people use the GUI I'll just keep it.[/B]

Please don´t drop this project. I like your GUI very much. In the moment it´s working at home while I´m here at the job. When I come home I have to start the second pass.

[akupenguin]

Originally posted by celtic_druid
Revision 90:
r72 broke B-frames without intra4x4. fixed.
Guess that is the fix?

No, the bug I fixed occurred only if you disable intra4x4 mode. And it didn't just produce block artifacts: all B-frames produced an invalid bitstream, and displayed as pure grey in ffdshow.

The bug you refer to is probably an issue with ratecontrol. I think I have fixed it, but I'm still running some encodes to make sure I didn't degrade other aspects.

[JoeBG]

Originally posted by akupenguin
No, the bug I fixed occurred only if you disable intra4x4 mode. And it didn't just produce block artifacts: all B-frames produced an invalid bitstream, and displayed as pure grey in ffdshow.

The bug you refer to is probably an issue with ratecontrol. I think I have fixed it, but I'm still running some encodes to make sure I didn't degrade other aspects.

And do you see any chance for b-frame support for 2-pass encoding? In the moment it produces horrible blocks

[Doom9]

And do you see any chance for b-frame support for 2-pass encoding? In the moment it produces horrible blocks

It is a bug and it'll be fixed.. what more can you ask for? For now refrain from using b-frames in two pass mode.. that's the only thing you can do (unless you are a programmer and willing to work on x264 by yourself

[JoeBG]

Originally posted by Doom9
It is a bug and it'll be fixed.. what more can you ask for?

I wanted to ask for the period and I wanted to express it gentle and very friendly. Sorry if I missed this.

Originally posted by Doom9
... unless you are a programmer and willing to work on x264 by yourself [/B]

That´s what all are waiting for

[Doom9]

version 0.11 is out.

still no turbo mode for x264 as I don't know which settings can be safely used for a quick first pass. also no queueing yet as this looks like a bit of a challenge if I want to encode job after job rather than write one batch file. However, that means I cannot start the batchfile as I do now (this keeps the command window open so that you can see what's going on and get some stats after encoding). If I redirect stdout, once encoding starts I cannot read line by line as the current line is always overwritten (you see the percentage complete moving up.. always on the same line). I don't quite know yet how I can handle this so if anybody has any ideas, now is the time.

[daveidmx]

Forgive me for replying without having a solid grasp on what you're saying. But here's a thought that might at least be related.

With some command line proggies i've written in the past I send some messages to stdout and others to stderr. That way, I can > the stdout to a file and still view the stderr on the console. or vice versa. So--are there some CRLFs that are getting sent to the wrong io stream, making the console not advance?


Once again, I apologize for answering without either understanding your concern or having used the program in question. At a glance it just sounded like maybe this was related and it might spark some thought. Disregard if not.

Cheers!

[Doom9]

With some command line proggies i've written in the past I send some messages to stdout and others to stderr. That way, I can > the stdout to a file and still view the stderr on the console. or vice versa. So--are there some CRLFs that are getting sent to the wrong io stream, making the console not advance?

the problem is there are not CRLFs.. imagine the cmd window at time X looking like this:

progress - 5% - 1000 frames, fps = 15.07

then at time X + 10

progress - 7% - 1200 frames, fps = 15.07

but, there has been no CRLF in between time X and time X+10, rather the line at time X has been overwritten by the line at time X+10. So, from the program's point of view that's reading lines from the redirected stdout, we're still at the same line. I don't know yet what mencoder sends to stdout and what to stderr.. a quick trial seemed to send everything to stdout.


And here's a quick howto for the profiles:
Enter a profilename in the text are for the profile dropdown (by default it says "Default").
Press new creates a new profile with the name you typed and all the currently active GUI settings.
To change an existing profile, select it, make changes in the GUI, then select another profile from the dropdown.
For now, changes to a selected profile are only stored when you change to another profile.. exiting the program will not change anything.

I'm also wondering whether after selecting a job (perhaps you've noted, it loads all the job's settings in the GUI), you'd want to make changes, then write those changes back to the job (an automatism as for profiles could probably be irritating, but I could add a button "update job" that would overwrite the settings from the currently selected job with the active GUI settings).

[akupenguin]

Originally posted by Doom9
but, there has been no CRLF in between time X and time X+10, rather the line at time X has been overwritten by the line at time X+10. So, from the program's point of view that's reading lines from the redirected stdout, we're still at the same line. I don't know yet what mencoder sends to stdout and what to stderr.. a quick trial seemed to send everything to stdout.

Between each status line, there is a CR without a LF. To a terminal, that means move the cursor to the beginning of the line, so that anything printed afterwards overwrites what's already on the line. To a program reading from a pipe, CR is just another character in the stream, and it does not overwrite anything.

[daveidmx]

@doom9

OK, and are you trying to intercept the stdout from the encoder and display it yourself in the GUI? If so, consider what akupenguin has said. I don't remember for sure, but I think you may need to use a different IO stream handler that isn't line-based.

[Paced]

I've found a small issue in the latest version. It's probably easier explained if you see it for yourself - activate the Snow codec, then head over to the 'Snow Codec' tab. Tick Qpel or V4MV and take note of what it does to the command line.

Additionally, is it just me, or when using the ASP codec, by selecting the Macroblock Decision Algorithm as "VHQ" or "RDO", you get an "Option lavcopts: Unknown suboption mbc" error in the command window, upon encoding (using CD's MEncoder dev-CVS-050110-15:31-3.4.2)? However, when using the Default option, the encoding starts as it should.

[akupenguin]

Originally posted by Paced
"Option lavcopts: Unknown suboption mbc" error in the command window, upon encoding

sounds like a typo. the correct option name is "mbd".

[Doom9]

I don't remember for sure, but I think you may need to use a different IO stream handler that isn't line-based.

Actually, I can read character by character.. now I just need to figure out which character a CR is and see if I can catch that.

@paced: I'll check those when I get home.

[r0cket]

now I just need to figure out which character a CR is

#13 IIRC