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

[ivan_alias]

The 'Snow' option was a big tease!!


Oh, and pretty sure there is a (small) bug when you select CQ for MPEG4, the default is CQ=800 ! Looks like it's taking the default bitrate from CBR mode - for x264 it changes to CQ26, so that works fine.

Cheers

Ivan

[Doom9]

- you might want to add something like "1-", "2-" to the subpixel refinement options, so its clearer for newbies which one is the highest aso...

I don't follow.. could you elaborate this a bit?

- you might want to name mpeg-4, something like mpeg-4 (lavc), as mencoder also offers xvid encoding (actually you also call it "lavc options", but still...). and "x264" something like mpeg-4 avc (x264) or h.264 (x264)

Yeah, I've been thinking about that. Might be done in a future version (though priority right now is on the job queue.. I've also been thinking about adding an automatic twopass, the main reason for it not being in right now is that I initially started without queueing.. once that is done, it'll be much easier for me to have an automatic twopass done).

- the values look somehow moved too close to the left (maybe moving them to the right might look better?)

Right align all the input fields?

- someone proposed this for x264 too and i think its done that way in nero already: only offer one deblocking option (eg named "strength") for alpha and beta and set both to the same value

I didn't know if it makes sense to separate the two options or not.. might be useful to have aku's input on this as well.

- more input options would be nice (eg direct dvd reading, .vob and .avi input), so that newbies can indeed do "one click" dvd transcoding with your tool (still there would be the resizing issue, but well )

Well, here we're entering GKnot territory and I don't feel the need to duplicate that work.. I basically want something that takes an avs and goes from there (so perhaps one day I'll add those mp4 output options after all).. what comes prior to the avs really is no problem to me. My main motivation for doing this is that I don't see a GUI offering enough options for lavc MPEG-4 and x264 (well, now there's syskin's VfW so things have changed a bit), and I don't want to mess around on the commandline. But I already have my tool to get from DVD to AviSynth. What you're asking for is way beyond what I ever wanted, and also way beyond the amount of time I can afford to invest.. keep in mind that I still run this place and have a site to take care of. But, since the thing is GPL, somebody else could add it (I'll be away for 3 weeks starting next Monday, before I'll comment my code and make another source release)

Oh, and pretty sure there is a (small) bug when you select CQ for MPEG4, the default is CQ=800 ! Looks like it's taking the default bitrate from CBR mode - for x264 it changes to CQ26, so that works fine.

Hehe, I know where that's from.

[hellfred]

Originally posted by Doom9

I didn't know if it makes sense to separate the two options or not.. might be useful to have aku's input on this as well.

I have once read that akupenguin never sets a differenc between the two deblocking parameters huger than one and suggested to set them always to the same value. He states this some days ago in one of the threads here on doom9, but just now i have no time for searching. Is it even necessary to provide you with a link, or will you believe me right away?

Hellfred

EDIT: Spelling, oh i hate it that much!

[Doom9]

The 'Snow' option was a big tease!!

It'll come as soon as I find a comprehensive list of all the codec parameters, their value ranges and default values.

Is it even necessary to provide you with a link, or will you believe me right away?

Well, now that I have somebody to blame it won't be necessary. And it's not a big deal merging the two either.

[akupenguin]

Yes, I suggested that sysKin merge the two settings in his interface. But then, I'm quite happy leaving both on 0, whereas I hear many people think 0 blurs too much. So if you think you can effectively use them separately, feel free to experiment (I haven't heard of any such study). Suggestions include alpha=0, beta=negative, i.e. full strength but avoids areas with much detail.

[akupenguin]

Originally posted by Doom9
[B]It'll come as soon as I find a comprehensive list of all the codec parameters, their value ranges and default values./B]

Options obeyed by snow:

vqscale: range 0.01 .. 255, sane range 1 .. 10. (A given quality in snow needs somewhat lower qscale than the same quality in mpeg4.) default: 0 (lossless). Note that 0 may not be specified; if you want lossless encoding, you must leave out vqscale. (Yes, quantizer can be fractional.)
There is no ratecontrol. Constant quantizer is the only mode.

pred: 0 => 9/7 wavelet (default). 1 => 5/3 wavelet. 2 => 13/7 wavelet. The different wavelets have slightly different characteristic artifacts. I think 9/7 usually looks best.

cmp: full pixel motion comparison function
subcmp: hpel/qpel comparison function
mbcmp: MB type comparison function
Choices that work for snow: 0 (SAD), 1 (SSD), 11 (5/3 wavelet), 12 (9/7 wavelet). Defaults: SAD. While you might think that the wavelet comparators would have an advantage, I find that SSD is usually best (for all 3), with SAD slightly better the remainder of the time.
You can add 256 to any of the options to enable chroma_me for that comparison (e.g. mbcmp=257 for SSD with chroma), but I haven't found it to help.

qpel: default=off. Always helps.

v4mv: default=off. Allows smaller motion partitions. The current MB decision algorithm doesn't make very good use of this: it improves quality, but also increases bitrate. (and you could get more quality per bitrate by reducing quantizer instead.)

last_pred: range=0-3, default=0. Tries a few extra predicted motion vectors before doing EPZS search. This option has negligible effect on both speed and quality of snow, so just leave it off. (it does, however, help mpeg4.)


In short: the best options in almost all cases are
vcodec=snow:vstrict=-1:vqscale=$N:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel

[bond]

Originally posted by Doom9
I don't follow.. could you elaborate this a bit?

i mean call the options something like "1 - Hpel only", "2 - Qpel 1 iteration"...

Right align all the input fields?

might be better

[bond]

Originally posted by akupenguin
Suggestions include alpha=0, beta=negative, i.e. full strength but avoids areas with much detail

hm thats interesting
so beta defines what areas get affected by the deblocking and alpha the strength?

if yes, than it might be indeed a good idea to NOT combine them to one option.

[JoeBG]

Originally posted by bond
hm thats interesting
so beta defines what areas get affected by the deblocking and alpha the strength?

if yes, than it might be indeed a good idea to NOT combine them to one option.

I hope noone will kill me for the following questions:
- when alpha is the strenght, then +1 is a stronger deblocking than 0? I mean is positive deblocking and negative sharpening?
- when beta is the area, then 0 means the same effects to the whole picture, negative means only backgrounds get blurred and positive means more blurring to the main parts of the picture.

[akupenguin]

Deblocking always smooths, never sharpens.
The strength and threshold are always adaptive based on quantizer.
alpha=0,beta=0 is tuned for optimal PSNR on most sources.
Other values tell it to use the strength and threshold tables from a different quantizer. So qp=25,alpha=-5,beta=-5 uses the same deblocking as qp=20,alpha=0,beta=0.
Since higher quantizer => more artifacts => more deblocking needed, higher values of alpha & beta do stronger deblocking.
(Note that since h264 uses a logarithmic quantizer, adding/subtracting N from it has the same effect independent of what the original quant was.)
If qp+alpha <= 15 or qp+beta <= 15, deblocking is completely disabled for that frame.

As for what exactly the parameters do:
Consider each potential vertical/horizontal edge in the picture (between macroblocks, or between motion partitions within a macroblock). Derive a threshold (based on qp, beta, and type of block) and strength (based on qp, alpha, and type of block). If the variation within the adjacent blocks is less than threshold, and the difference across the edge is less than strength, then filter this edge. Filter means apply a 6tap blur perpendicular to the edge, but limit the amount of change to any one pixel based on strength.
The effect of block type: Edges between non-coded blocks of similar MV are not filtered (because they were deblocked in the previous frame). Non-coded blocks that differ by more than 1 pixel worth of MV are filtered weakly. Normal inter blocks are filtered more. Intra blocks are filtered most.

edit: I got alpha and beta swapped.

[Doom9]

v0.1 is out. stay tuned for more

[hellfred]

Hi Doom9
Thanks for this great tool to make handling encoding with mencoder under win32 so much easier. Before I had to use a hand-written batchfile that needed to be updated manually for each and every encode. It is so much more comfortable this way.
Two suggestions. What about adding MPlayer/Mencoder manpage (html) to your Package, so that ppl. can actually try to understand what the commandline assembled by your GUI means, and to be able to add some more fancy options to it that may be too exotic or not yet implemented in your GUI?
If you do not want to add the file to your package, can you at least mention the url of the html manpage to your readme file for those interested in it.
Other question. One is already able to edit the commandline in your GUI, but i did not find my changes in the resulting job.bat. Do you plan to add it?
Last thing, I am sometimes not interested in encoding the hole movie/avs script right away, but just the first <framecount> frames of it to test the impact of certain options. Is it possible to add avs2yuv option -frames <framecount> to your GUI so that i do not have to open and edit the AVS script everytime during the process of option optimization.

Hellfred.

[Doom9]

Other question. One is already able to edit the commandline in your GUI, but i did not find my changes in the resulting job.bat. Do you plan to add it?

It kinda conflicts with the way jobs are handled. I do not save the commandline, rather I save all the GUI options, and at encoding time I convert those settings into a commandline. So you can see where editing the commandline could be problematic. Now say I add the commandline as an additional field.. which one gets taken if the compiled commandline from the stored settings does not match the GUI settings? And in case of visualizing a job in the queue, you'd be forced to decide if you want to stored GUI options to be shown, or screw the GUI and just show the commandline.

People who are knowledgeable enough to edit commandlines should imho resort to the commandline.. sure they can use the GUI to get a starting point, but after that, all advanced functionality makes things harder to handle and this is really a tool for people who do not care about the mencoder commandline. I just put the commandline there as a debug measure (it's easy to see if the commandline generation is wrong).

I'm also planning on adding tooltips for all the options, thus making the manpage superfluous (I plan to add some "easy" understandable description for all the options plus suggested settings).

[r0cket]

Doom9

I just put the commandline there as a debug measure

Well then won't it be more logical to make cl read-only in your GUI?

People who are knowledgeable enough to edit commandlines should imho resort to the commandline

But some knowledgeable people, who just don't want to mess with commandlines, should have Advanced tab to play with

[Paced]

Firstly, thanks for the neat GUI Doom9. I seem to have a slight problem getting it working though; here's what happens when I click 'Encode':

-------------------------------------------------------------------
C:\Stuff\Programs\MeGUI>
C:\Stuff\Programs\MeGUI>avs2yuv "C:\WUTemp\TEST\D2VAVS\test.avs" - | mencoder
- -ovc x264 -o NUL: -passlogfile "mencoder-2pass.log" -x264encopts pass=1:qp_constant=26:bframes=1:deblockbeta=-2:rc_buffer_size=700
MEncoder dev-CVS-040228-17:13-3.3.3 (C) 2000-2004 MPlayer Team

CPU: Advanced Micro Devices Athlon MP/XP Thoroughbred 1740 MHz (Family: 6, Stepping: 1)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

Reading C:/Stuff/Programs/MeGUI/mplayer/codecs.conf: 64 audio & 169 video codecs

File not found: 'frameno.avi'
Failed to open frameno.avi
Reading config file C:/Stuff/Programs/MeGUI/mplayer/mencoder: No such file or directory
Option ovc: Unknown suboption x264
C:\WUTemp\TEST\D2VAVS\test.avs: 640x352, 25000/1000 fps, 1829 frames
Exiting... (error parsing cmdline)
Output error: wrote only 316910 of 337920 bytes

C:\Stuff\Programs\MeGUI>

-------------------------------------------------------------------

I've got the latest versions of mencoder (celtic_druid's) and avs2yuv - as stated in the readme - and they are placed alongside MeGUI.exe in the same directory. Is there something else I'm missing (it's my first attempt at using mencoder, so please be gentle )? Thanks in advance.

[celtic_druid]

MEncoder dev-CVS-040228 = 28th Feb 2004, that would be your problem.

Looks like my 2004.02.26 build is actually 2004.02.28, so you grabbed the oldest, not newest.

[Paced]

Originally posted by celtic_druid
MEncoder dev-CVS-040228 = 28th Feb 2004, that would be your problem.

Looks like my 2004.02.26 build is actually 2004.02.28, so you grabbed the oldest, not newest.

How silly of me, for some reason I thought the first one on the page was the latest, serves me right for being incompetent! Thanks for the quick reply.

[Doom9]

Well then won't it be more logical to make cl read-only in your GUI?

That's a flag you have to set in the GUI designer.. the default is editable, no matter if I meant it to be editable or not. It's just that black on white looks better than black on gray, and it improves readability.

But some knowledgeable people, who just don't want to mess with commandlines, should have Advanced tab to play with

There are all the x264 options exposed, and a good selection of the lavc parameters (the ones I left out I think really are mostly beyond reason and work just fine at their defaults). So I don't see anything missing.. it does what I wanted it to do. You cannot have all the options in a GUI, or it'll be just as complex as ffdshow.. the reason to make this was to prevent the sensory overload and confusion by too many options... I suppose I already went too far with all the exposed 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. Perhaps then you'll realize what it is you're asking for. This really isn't a usability feature, it does just the reverse, make things more complicated.

[JoeBG]

Originally posted by Doom9
I'm also planning on adding tooltips for all the options, thus making the manpage superfluous (I plan to add some "easy" understandable description for all the options plus suggested settings). [/B]

Great . I testet your tool with many different settings. It was a very nice evenig yesterday - thank you for this. I´ll host the tests this week and give a link.

But I have one problem which is confusing me while testing myself and reading all the facts about x264: Why do I get blocks when using b-frames in 2 pass mode? ffdshow supports them => it´s not a problem of the player (player also has no problem with Ateme). I´m testing the AVI-file => it´s not a problem of mp4creator or avi2raw. Would be so nice to have b-frame support with MeGUI and x264.

[Doom9]

well, the blocks have nothing to do with the GUI, but with the codec. The problem is already known (see here: http://forum.doom9.org/showthread.ph...882#post592882). Once this issue is fixed in the core, you just have to download a new mencoder build that incorporates the new x264 core and you'll be all set. The GUI might also need to be changed over time if there are new core parameters (I understand weighed predition was just added to ffdshow so perhaps we'll see that as an option in x264 soon).