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

[Doom9]

MeGUI is my first attempt at a ripping software.

It is an mencoder based x264, XviD, Snow and libavcodec MPEG-4 (lmp4) encoder.
It supports all x264 features, all Snow features and a good number of XviD and libavcodec MPEG-4 features. In addition, it supports AAC audio encoding using the Nero AAC encoder (with BeSweet to decode the input audio), and muxing the result in an MP4 file using mp4box.

Supported input types: AviSynth scripts, AAC/AC3/MP2/MP3/MP4/MP4/WAV
Supported output types: AVI, raw video data, MP4 (audio and video)

MeGUI supports profiles for both audio and video so you don't have to configure every encoding job, but can just load your input and select a profile and you're ready to roll. There is a tab for Queues, similar from what you might know from VirtualDub.

In addition, there is a fully automatic MP4 creation facility with included bitrate calculations. You just need to specify a valid video and audio input, select a desired size and codec, and the GUI will do the rest for you.

Required tools:
.NET Framework 1.1 (http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3&displaylang=en)
latest version of mencoder (http://www.aziendeassociate.it/cd.asp?dir=/mplayer)(it's part of the mplayer package, pick the version that best matches your CPU)
pgthreadGC2.dll (http://www.webalice.it/f.corriga/misc/pthreadGC2.dll) (required when using mencoder & x264)
x264 CLI (http://forum.doom9.org/showthread.php?t=89979) Alternative to mencoder for x264 encoding
besweet 1.5b29 (http://www.doom9.org/Soft21/Audio/BeSweetv1.5b29.zip)
latest version of mp4box (http://www.aziendeassociate.it/cd.asp?dir=/gpac/dev)(4/19 or newer)
DGMPGDec 1.21 or higher (http://neuron2.net/dgmpgdec/dgmpgdec.html)

check the readme file for more info on how to get started. Changelog of older versions comes bundled with the download.


Version history:

0.193 alpha 06/13/2005

bleeding edge alpha for the adventurous..

0.1915 05/08/2005, downloaded 338 times

new: supports x264.exe as alternative x264 encoder
new: supports x264 minimum gop size

changed: all references to merge jobs have been removed
changed: extension defaults to mp4 when using x264 for mp4 output (no separate muxing unless you are
in auto mode)

bugfix: the me type is set to the default in the GUI, preventing a mencoder abort if you didn't configure
the me type on your own
bugfix: invalid custom paths & working default path no longer causes a crash

0.1914 06/05/2005,

new: supports the AVC High Profile 8x8 transform in x264 (you will need a bleeding edge mencoder build for that.. CelticDruid has not yet released such a build at the time I'm writing this)
new: automatic vertical resolution suggestion for the AviSynth script creator, based on the DAR set and the croping values

0.1913 06/05/2005, downloaded 27 times

new: x264: all x264 options available in mencoder are supported. This includes abr, me range, me type, vbv buffer size, vbv initial buffer size, vbv maximum bitrate, bitrate variance (rate_tol), p8x8, number of threads and zones
new: xvid: supports adaptive quantizer (requires a brand new mencoder build, it was just added to mencoder yesterday) and zones
new: should be more stable towards improper AviSynth scripts (catches native Win32 errors as well now whenever it opens an AviSynth script)
new: additional disc sizes have been added as requested

changed: x264 options that do not apply to a certain mode are not used for the commandline anymore
changed: x264 and xvid credits rely on zones in the codec rather than external files. This will resolve whatever problems might have ocurred in the past using separate files and not use as much space because no files have to be merged anymore.


0.1912 05/16/2005, downloaded 609 times

new: dgindex is now run in its own thread so the GUI remains accessible while you create DGIndex projects
new: auto force film has been implemented. For now, open the new version once, close it again, then you can edit settings.xml to enable/disable it and set a percentage above which force film will be automatically applied

bugfix: chained jobs work properly now (broken since 0.1813)

0.1911a 05/16/2005 downloaded 62 times
changed: moved changelog from the 0.18x series from the forum to the included changelog
changed: updated readme file

0.1911 05/16/2005 downloaded 86 times

changed: autocrop function now uses 10 frames rather than 5, and uses the lowest possible crop value found if no majority can be found for one value from the 10 samples. This is done per crop value. In addition, I introduced a treshold to decide when a line/column is considered for cropping (got the idea from GKnot). It finally worked as it should in the few samples I have tried.

changed: non working DGIndex project files are now catched and no longer result in a crash.

0.191 05/15/2005 - downloaded 19 times

new: creates DGIndex projects (load them where you load the AviSynth script)
new: autocrop (it's a work in progress.. somebody come up with a better way than compare the color values of a pixel to the pixel in the upper left corner let me know)

bugfix: 5th subtitle track is now properly accessible

0.19 05/15/2005 downloaded 94 times

new: opens DGIndex project files.

bugfix: adding jobs, then deleting some and finally encoding no longer crashes
bugfix: changing the codec takes the encoding mode for the selected codec into account
bugfix: changing path of the desired executables updates the commandline immediately
bugfix: custom paths are fully functional now and do not throw an error if you don't have a copy of the executable in your megui path (it worked before and the custom path was used but the check prior to encoding wouldn't find the executable unless it was in the megui folder)

[Doom9]

my GUI only accepts AviSynth input and feeds them to mencoder via avs2yuv. That way you get the full power of AviSynth, and no hassle when trying to make mencoder to accept virtual AVIs made from AviSynth.

[buzzqw]

my GUI ???

what gui ? :confused:

BHH

[Yong]

Graphical User Interface;)

[kurt]

Originally posted by Doom9
Interesting.. just last week-end I wrote my own mencoder GUI specifically for x264 encoding. It supports all x264 parameters (needs testing though). But since I wrote it to try out VC# Express I'm having some trouble getting it to run on other machines.

@buzzqw: nothing to download yet :D

[buzzqw]

@kurt

oppss, sorry i missed it

thanks

BHH

[JoeBG]

Originally posted by Doom9
my GUI only accepts AviSynth input and feeds them to mencoder via avs2yuv. That way you get the full power of AviSynth, and no hassle when trying to make mencoder to accept virtual AVIs made from AviSynth.

Thats what we need. Where is the download? :) :) And the instruction? ;)

[Doom9]

okay, here's a first version to be tested. I'm afraid you need the .net runtime 2.0 (still in beta). It doesn't encode yet, and the 3rd tab is still disabled (just got the defaults this second.. I don't write a parameter in the commandline if it's left at the default value to make it easier to spot problems in the commandline.. but that complicates my commandline generation). Also, no encoding so far, but you can copy & paste the commandline to a commandprompt.

Not that at this point I'm only looking for errors in the commandline generation. Once all the options work and encoding works as well, I'll release the source so whoever wants to see more options can add them personally.

initial version downloaded 465 times prior to removal

[SeeMoreDigital]

When I tried to run the .exe file I got this: -

http://img107.exs.cx/img107/9701/x264gui0no.gif


Cheers

[Doom9]

do you have the .net framework 2.0 beta1 installed or the 1.1 framework? The reason for writing this gui basically was that I wanted to have a peek at .net 2.0.
It won't work if you don't have the 2.0 framework. All the nifty gui components require the new framework.

[SeeMoreDigital]

Sorry Doom9,

I wasn't aware that there was a 2.0 beta1 available. I only installed .NET in the first place, so I could test MPEG4 Modifier and Dolemite's (aka: stax) DVX ;)


Cheers

[Doom9]

alright, I'm all done, encoding included. I finally resorted to a batchfile and some process list trickery to get the process priority down but I think we're pretty much there. Now all that needs to be done is go through every parameter and check if it works.

I also posted some screenshots so that you see what you're missing if you don't have the .net runtime 2.0 ;)

[Doom9]

bleh, why can't I attach multiple files at one?

[Doom9]

and the last shot

[bond]

Originally posted by Doom9
It won't work if you don't have the 2.0 framework. All the nifty gui components require the new framework.you can get it here (http://www.microsoft.com/downloads/details.aspx?FamilyID=B7ADC595-717C-4EF7-817B-BDEFD6947019&displaylang=en)

nice screenshots doom9 ;)

[708145]

Nice work doom9!
I'm downloading the .NET2.0 ATM.

Does anyone know if and when mono will support this?

bis besser,
Tobias

[superdump]

I've downloaded the .NET 2.0 beta from the link bond provided and the current x264gui requires a newer version than that. The linked version is 2.0.40467 I think and as SeeMoreDigital pointed out via his picture the one required is 2.0.41013. Could someone please point us to this because I've scoured the Microsoft site and I cannot find it. :( In future Doom9, could you provide a link to the required redistributable alongside the GUI download link? Thanks. :)

[RedDwarf69]

Originally posted by bond
[B]i think a mencoder gui will surely give x264 and snow a boost and it would also ensure easier support for latest/future technologies than vfw and platform independance imho :)

Someone can give a summary of what are the actual limitations of vfw (and if mencoder corrects)?
We will be able to use variable framerate but no CODEC currently search for ways to use this, correct? And something else?

[Doom9]

@superdump: I compiled it using the Visual C# Express CTP build from October. I'm afraid it comes with a different .NET runtime that you can download (I've not found it for download). So what I'll do is compile again with the beta1 IDE, that should fix the problem. I'm just hoping that once .NET 2 gets out of beta we can get beyond such petty issues (that I've never had before with .NET.. stuff compiled with 1.1SP1 works just fine in 1.1 and even 1.0 if you take care of the little differences there are between the 1.1 and 1.0 release).

Anyway, I'll let you know when the beta1 compatible build is up.

As far as mono goes, once they incorporate Windows.Forms 2.0.. they now support Windows.Forms 1.1 (still limited though).. I wouldn't expect anything to run before Mono 2.0, but eventually the GUI should run under Mono regardless of the platform. Though by then I hope somebody has written a better GUI, it's really simplistic.

Now if somebody has me a reference documentat that explains all snow configuration parameters, their allowable and default values, I might be able to add snow support as well.

[iapir]

Originally posted by RedDwarf69
Someone can give a summary of what are the actual limitations of vfw (and if mencoder corrects)?
We will be able to use variable framerate but no CODEC currently search for ways to use this, correct? And something else?

So far the only solution I know is to encode different parts separately and then merge the result together with timecode files in Matroska.

It would be nice someday to have an API and an editor to do that. But mencoder is not designed to do that anyway. It has somehow the same limitations as VfW.

[akupenguin]

Originally posted by iapir
So far the only solution I know is to encode different parts separately and then merge the result together with timecode files in Matroska. You don't have to encode separately. Just lie to the codec about framerates and bitrates (if you want to get fancy, use zones to correct the bit distribution), and fix it with the Matroska timecodes.

[iapir]

Yes, but unfortunately the whole bunch of MPEG codec keep track of the time inside the frame. So it's probably better not to fool them too much.

[SeeMoreDigital]

Sadly, after installing .NET 2.0 beta (2.0.40467), I concur with superdump's findings!

EDIT: The "macroblock options" look interesting!


Cheers

[easyfab]

Originally posted by SeeMoreDigital
Sadly, after installing .NET 2.0 beta (2.0.40467), I concur with superdump's findings!

EDIT: The "macroblock options" look interesting!


Cheers

Same for me BUT :)
Go to windows/Microsoft.NET/framework/
Create a directory called v2.0.41013 and copy v2.0.40607 files in it, it should work , at least for me

Hope for you too

Thanks Doom9 for your tool :)

[SeeMoreDigital]

Originally posted by easyfab
Same for me BUT :)
Go to windows/Microsoft.NET/framework/
Create a directory called v2.0.41013 and copy v2.0.40607 files in it, it should work , at least for me

Hope for you too Jeez!

I don't believe it... that procedure worked a treat :D There sure are some clever people around here!

I wonder whether such a procedure would have worked without having to install .NET 2.0 beta at all?


Many thanks

[Doom9]

here's a new version, compiled against the 2.0 beta1 runtime.

I'm afraid it looks less sexy (hopefully the next official beta will be out soon - the October CTP was really unstable), but I've added job queuing as well so you can now configure multiple jobs and have them run one after another.

[Doom9]

and here's the source. I don't really feel like packaging license files and adding source comments, but consider it released under the GPL. I'll fix commandline bugs if there are any, but other than that even though I have tons of ideas, I'm not really looking favorably upon spending what little free time I have adding features to this gui. Though snow and lavc mpeg-4 output would be cool ;) And if somebody packports it to .NET 1.1, I wouldn't mind either..

[Wilbert]

1) I assume it doesn't work with .NET 1.1?

2) Could you please separate this part of the thread from the original topic?

[Doom9]

@wilbert: I think It won't work if you don't have the 2.0 frameworkis pretty clear ;)

[JoeBG]

Originally posted by Doom9
and here's the source. I don't really feel like packaging license files and adding source comments, but consider it released under the GPL. I'll fix commandline bugs if there are any, but other than that even though I have tons of ideas, I'm not really looking favorably upon spending what little free time I have adding features to this gui. Though snow and lavc mpeg-4 output would be cool ;) And if somebody packports it to .NET 1.1, I wouldn't mind either..

It works great, thank you very much. But first of all I have to understand all the features in it. I don´t know all of them. So I will have a nice week and an interesting weekend.

Can I ask some questions here in this threat?

[bond]

i think its ok to use this thread, as the initial gui talked about doesnt support x264 till now anyways?
changed the title to a more clearer one :)

[Doom9]

Can I ask some questions here in this threat?Sure. If I have time I might add some tooltips in the future.

[JoeBG]

Originally posted by Doom9
Sure. If I have time I might add some tooltips in the future.

Oh yes, some functions need some tips for me: :)

1) output four CC
AVC1 would be ok for MP4 Container right? I want to mux to MP4 after encoding

2) Codec
a. 2 pass, first pass:
a1) Quantizer: 0 is highest quality? I want to encode 1/3 DVD.
a3) Number of reference frames: 3 -5 ?
a4) Number of b-frames: 2-3 wwould be
a5) I want to use somethimg like adaptive. Is -2 for both ok?
a7) subpixel refinements: Always QPel brings highest quality?
a8) Macroblock options: Both for highest quality? b8*8mv and 4*4mv?

b. 2 pass, second pass
Bitrate: Bitrate for a 1/3 DVD Rip? From a calculation tool?


3) Quant & RC
Buffer Size = Bitrate and I should activate "fix" ?

[Doom9]

I think AVC1 is the proper FourCC for MP4, but perhaps bond just forgot to hit me over the head until now ;)

quantizer: it's an up/down control, so use whatever values you can obtain with the up/down buttons ;) Unless you're telling me I screwed up the limits, all the up/downs have been adjusted to allow only entries that are permissible (though I don't know how they act if you start typing away and don't hit enter (hitting enter will enforce a valid value)). I think quant1 is the standard for best quality.. I've never heard of quant0.

You'll also have to dig through the x264 thread, where you'll find suggested useful settings. For instance, if I'm not mistaken you should not use more than 1-bframe, and 3 reference frames is already much.

Bitrate: you obviously have to calculate that on your own ;) Codecs generally don't provide a calculator that really holds for each output type and scenario. For instance, you'll be hard pressed to find reliable overhead values for MP4, with a fixed 1b-frame GOP structure (I think x264 GOP structure is fixed but once again I could be mistaken.. better read the x264 thread).

The fix checkbox for the buffer size is there that you can enforce a certain buffer size. By default, as long as you're in an encoding mode where you can specify a bitrate, the default buffer value is = bitrate. But on that, you'll also find some suggestions in the x264 thread.

[akupenguin]

Originally posted by JoeBGermany
Oh yes, some functions need some tips for me: :)
2) Codec
a. 2 pass, first pass:
a1) Quantizer: 0 is highest quality? I want to encode 1/3 DVD. 0 is highest quality (similar bitrate to huffyuv, though it depends on the amount of motion). I find h264 @ qp=18 to be similar to mpeg4asp @ qp=2, and h264 @ qp=24 to be similar to mpeg4asp @ qp=4.
a3) Number of reference frames: 3 -5 ? more is always slightly better, but if you care at all about speed, 3-5 is good.
a4) Number of b-frames: 2-3 would be No. We don't have adaptive B-frames yet, so don't use more than 1.
a5) I want to use somethimg like adaptive. Is -2 for both ok? is this deblocking? yes, -2 is ok.
a7) subpixel refinements: Always QPel brings highest quality?Always QPel is the highest quality, but is only needed on the final encode. For the 1st pass you can set it to medium with negligible loss.
a8) Macroblock options: Both for highest quality? b8*8mv and 4*4mv?yes.

b. 2 pass, second pass
Bitrate: Bitrate for a 1/3 DVD Rip? From a calculation tool? You can set bitrate to whatever you want. That part of encoding hasn't suddenly changed with h264.

3) Quant & RC
Buffer Size = Bitrate and I should activate "fix" ? Don't touch buffer size unless you know what you're doing.

[snacky]

a1) Quantizer: 0 is highest quality? I want to encode 1/3 DVD.
quant=0 is a good way to end up with a reencode that's larger than the source. The lowest quants I'd normally consider using are in the 10-15 range.
a3) Number of reference frames: 3 -5 ?
You can benefit slightly from using a higher number; the speed penalty is pretty minor and in my experience it practically never ends up raising bitrate (unless you turn off CABAC). Lately I usually just use 15. Be aware that 15 is usually only slightly better than 5, if it's better at all.
a5) I want to use somethimg like adaptive. Is -2 for both ok?
x264 doesn't do adaptive deblocking, but you can tweak deblocking parameters. Don't expect any miracles. It's just a tradeoff of blockiness vs. loss of detail.
a7) subpixel refinements: Always QPel brings highest quality?
It can never LOWER quality as it might in MPEG-4 ASP (assuming a given bitrate, that is). Asking for more subp refinement usually makes a significant difference. The difference between subq=1 vs subq=5 is often a couple percent in bitrate plus a little PSNR, but the speed difference is very big too.

[DeathTheSheep]

15 reference frames?!!! What good could possibly come of such an absurd number of refs? ;-) Man, dude, I'll try it out, heh...

But seriously...Why?

Just curious. As sheeps are, mind you.

Cheers, baa

[snacky]

It wouldn't be too hard to contrive a scene in which it helps a lot to use 15 reference frames.

As for real-life source material, why don't you do some tests and find out?

[akupenguin]

Results: for real movies, I have seen up to about 5% reduced bitrate for 4 refs vs 1, and up to 10% for 15 refs vs 1. (These comparisons run with no B-frames, all other options at max (cabac,subq=5))

While I haven't done a detailed study of how refs are actually used, I think I am qualified to guess. There are two uses for multiple reference frames:
One is to just find blocks that more closely match the current in a scene with somewhat chaotic motion (like most live-action). This produces only a few % difference in bitrate, but only requires a few ref frames (2-4).
The other is to encode scenes where one object obscures another but later moves out of the way. With sufficient refs, you can encode the backdrop as a mv from long ago, but without sufficient refs it has to be intra. This can benefit from any number of refs, easily up to 15 (and could use even more with long-term refs). The only limit is that at high numbers, it starts to get less efficient because of the number of bits required to encode which ref it used. (This is where CABAC helps. It could also be improved with adaptive ref marking and/or ref list reordering, whenever I get around to implementing those.)

[bond]

small letter "avc1" is indeed the four letter code defined by the mpeg-4 standard to signal avc streams in .mp4 (i think its comparable to .avis fourccs)

[JoeBG]

Originally posted by Doom9
The fix checkbox for the buffer size is there that you can enforce a certain buffer size. By default, as long as you're in an encoding mode where you can specify a bitrate, the default buffer value is = bitrate. But on that, you'll also find some suggestions in the x264 thread. [/B]

Thank you very much for this explanations, but especially this ones about the buffer size is something I really don´t understand.

[stax76]

I finally resorted to a batchfile and some process list trickery to get the process priority down


you can control the command shell

http://www.microsoft.com/technet/archive/winntas/deploy/shellscr.mspx


List<string> jobs = new List<string>(new string[] {"notepad", "notepad"});
using (StreamWriter sw = new StreamWriter("jobs.bat")) {
sw.Write(string.Join(Environment.NewLine, jobs.ToArray()));
}
Process.Start("cmd", "/k start /wait /low /b jobs.bat");

[Doom9]

you can control the command shellDoes it work for you? I tried using start as the actual Process name, set ShellExecute to true (in the ProcessStartInfo), but that only gave me a quickly opening and closing window. That's why I ended up just calling jobs.bat. My priority solution right now sucks as it only sets the priority to low for the first encode.. it's really a rush job.

[stax76]

the process class wrapps the ShellExecuteEx Win32 API function for UseShellExecute and CreateProcess otherwise, if it don't cut it for you, you can get the p/invoke type definitons with reflector in a minute, there is a VisualStudio plugin, where you can right click any function to get it decompiled in any language. It's quite powerful though, instead of using a batch file you should be able to execute each command one by one and you should also be able to redirect the streams if necessary.


I tried using start as the actual Process name


you mean you tried using start as filename for StartInfo? That would search for a file named start and throw a Win32Exception on most systems since there is no such file

[JoeBG]

Originally posted by JoeBGermany
Thank you very much for this explanations, but especially this ones about the buffer size is something I really don´t understand.

Is there noone who wants to explain me how to use it???
I really do not understand the feature with buffers, maybe it´s a problem of translation?

[Doom9]

Joe, what does it say in the forum rules about not posting the way you did? Oh right, it's a strikeable offense:devil:

I presume you do not understand the parameter, not the GUI, but you will find the answer in the very thread I mentioned. http://forum.doom9.org/showthread.php?s=&postid=590516#post590516 , even on the last page so there's no particular effort required. It was even quoted

akupenguin once pointed out that rc_buffer_size gives good results when set around 0.5-1 second worth of video bitrate for CBR, or 1-2 seconds worth of bitrate for multi-pass.
Meaning when you are doing your onpass with bitrat 450 kbits/second go for 225 kbits/second to 450 kbits/second, and to 450 kbits/second to 900 kbits/second for multipass encoding with same bitrate.So, basically what we have here determines how much the bitrate can fluctuate. It's a reservoir of the bits available to encode the next frame.

There's a smart rule I think should be applied if you do not know what a parameter does and cannot find an answer to what it does: either experiment, or leave it at its default ;) not filling in the field will leave it at the default, which means buffer size = video bitrate * 1 second. Since in order to indicate the value of the default buffer, I always copy the value from the bitrate field to the buffer field, as soon as you either select cbr or 2 pass vbr 2nd pass. But, should you chose another value than the default, you may not want your selecting the 2nd pass overwrite your buffer value, that's why you first fill it in, check fixed, and then you can select another encoding mode, and your chosen buffer size will be preserved. Though that I have previously explained, and it's quite apparent if you just play around with the GUI ;)

[JoeBG]

Originally posted by Doom9
Joe, what does it say in the forum rules about not posting the way you did? Oh right, it's a strikeable offense:devil:


Don´t hurt me so much. It´s all not so easy here! I´ll do my very best next time :) I promise.

There is one problem lefr for me and I really studied the hole threat here if there is a solution: When I start encoding, there is only the black dos window opening for a very short time when I use your gui. I don´t know why. I installed avs2yuv new, I installed mencoder with mplayer new, always the same problem. :confused:

[Doom9]

When I start encoding, there is only the black dos window opening for a very short time when I use your gui. Well, I guess the GUI needs some instructions. You have to place both avs2avi.exe and mencoder.exe in the same directory as the GUI itself. Try that and if it doesn't work, start a command prompt (start - run - type "cmd" without the "s and press OK,= then navigate to the directory you have put the gui - for instance c:\temp\x264gui\, and then run jobs.bat. If it also aborts immediately, please post the contents of your dos window here.

Also, you need a very recent mencoder version from celtic-druid, not the version you can download from the mplayer homepage.

[hellfred]

Originally posted by Doom9

Also, you need a very recent mencoder version from celtic-druid, not the version you can download from the mplayer homepage.
I have provided Sascha Sommer, a mplayer developer that builds the official win32 binaries, with a howto to include libx264 to mplayer/mencoder. So we just need to bug him a little bit (:devil: ) so that he will actually link his builds to it. Which should, by the way, be no problem, as Sascha includes quite every feature available to his binaries....

Hellfred

[JoeBG]

Originally posted by Doom9
Also, you need a very recent mencoder version from celtic-druid, not the version you can download from the mplayer homepage. [/B]

It seems to work so far. But I don´t have the mencoder and mplayer version of celticdruid in the moment, his site is down since two ore more days.

[JoeBG]

I was searching for 2 hours for the celticdruid compile. Seems to be impossible to get it somewhere else. Can someone help me please? :thanks:

[hellfred]

Originally posted by JoeBGermany
I was searching for 2 hours for the celticdruid compile. Seems to be impossible to get it somewhere else. Can someone help me please? :thanks:
Sharktooth has mirrowed (http://forum.doom9.org/showthread.php?s=&threadid=87719&perpage=20&pagenumber=4) the side, and the link is standing somewhere else in one of the relevant threads about ffdshow and x264
Hellfred
Sorry, he only mirrowed the ffdshow build (http://ebola.gamersrevolt.it/celticdruid/ffdshow/), but maybe that helps you, too.
For getting an mplayer binary, in two houres you can build it yourself.
Follow these instructions (http://www.mplayerhq.hu/DOCS/HTML/en/windows.html) and check this additional MinGW lib compiling manual, and check the enhanced step 5 including building x264 at the end of the HOWTO:
--------------------------------------------------------------------
Part 1, the HOWTO
--------------------------------------------------------------------
Once finished this should become a howto that will explain the steps necessary to setup the toolchain to compile your own versions of MPlayer on MinGW
similar to the one in the packages found at http://www.mplayerhq.hu/MPlayer/releases/win32-beta

Step 1 Mingw and msys
Download the latest versions of MinGW and msys from
http://www.mingw.org/download.shtml

The versions used in this document are
MinGW-3.1.0-1.exe
MSYS-1.0.10.exe

Then install MinGW and afterwards msys.

Answer
"Do you wish to continue with the post install? [yn ]"
and
"Do you have MinGW installed? [yn ]"
with y and give the path to your mingw dir in the next question. (c:/mingw if you did not alter the path during the mingw setup)

After the installation is finished, open a msys shell (you can find an icon for it on your desktop).

The following steps assume that you download the packages to your msys home dir, for me that is in c:\msys\home\useranme
where username is my windows username.

Step 2 directx headers
Get the directx header package at
http://www.mplayerhq.hu/MPlayer/releases/win32-beta/contrib/dx7headers.tgz

As alternative you can also use the modified wine headers reimar posted to the cygwin list.

Extract the headers and move them to your mingw inlucde dir (c:\mingw\include)
To do this use the following commands in your msys shell
tar -xvvzf dx7headers.tgz
mv *.h /mingw/include

Note: In this tutorial I install all packages into the mingw tree, it might probably be better to put all extra libraries and headers
into a seperate directory and pass this directory with the --with-extraincdir and --with-extralibdir switches to configure
Furthermore I'm using static linking to prevent problems caused by different dll versions.
Omitting the --disable-shared from the configure commands will help you to build smaller exes that require the various dlls to be installed.

Step 2 ogg and vorbis
Go to http://www.vorbis.com/download.psp
Select "Unix / Linux" as operating system
Then download the libvorbis and libogg .tar.gz sources
from the Libraries section
Also get the patch http://mplayerhq.hu/MPlayer/releases/win32-beta/contrib/libogg-mingw32.diff

extract the archive:

tar -xvvzf libogg-1.1.tar.gz

change to the dir containing the sources:
cd libogg-1.1

Apply the mingw build patch:
patch -p0 <../libogg-mingw32.diff

Then call configure with your mingw install dir as prefix:

./configure --prefix=/mingw --disable-shared

compile the sources:

make

and install them:

make install

afterwards go back to your msys home dir:

cd

now install libvorbis in a similar way
tar -xvvzf libvorbis-1.0.1.tar.gz
cd libvorbis-1.0.1
./configure --prefix=/mingw --disable-shared
make
make install
cd

Step 3 freetype (for osd font rendering)
First install libiconv from
http://www.gnu.org/software/libiconv/

Get the sources then
tar -xvvzf libiconv-1.9.1.tar.gz
cd libiconv-1.9.1
./configure --prefix=/mingw --disable-shared
make
make install
cd

Then get the latest freetype2 source package from
http://sourceforge.net/project/showfiles.php?group_id=3157

tar -xvvjf freetype-2.1.9.tar.bz2
cd freetype-2.1.9
make
make install
cd

Step 4 zlib, libregif, libpng, libjpeg
zlib is needed for some mov files with compressed headers the others to play/encode png/jpeg/gif files

Sources are available from:
http://www.gzip.org/zlib/
http://armory.nicewarrior.org/projects/libregif/
http://sourceforge.net/project/showfiles.php?group_id=5624
http://www.ijg.org/

tar -xvvzf zlib-1.2.1.tar.gz
cd zlib-1.2.1.tar
./configure --prefix=/mingw
make
make install
cd

tar -xvvzf libpng-1.2.8-config.tar.gz
cd libpng-1.2.8-config
./configure --prefix=/mingw --disable-shared
make
make install
cd

tar -xvvzf jpegsrc.v6b.tar.gz
cd jpeg-6b
./configure --prefix=/mingw/ --enable-static
make
cp .libs/libjpeg.a /mingw/lib/
cp jpeglib.h jconfig.h jmorecfg.h c:/mingw/include/
cd

tar -xvvzf libregif-4.1.5.tar.gz
cd libregif-4.1.5
./configure --prefix=/mingw
make
make install
cd

Step 5 lame and xvid

Get the nasm sources from http://sourceforge.net/project/showfiles.php?group_id=6208

tar -xvvzf nasm-0.98.38.tar.gz
cd nasm-0.98.38
./configure --prefix=/mingw
make
make install
cd

Install lame from http://lame.sourceforge.net/download/download.html
tar -xvvzf lame-3.96.1.tar.gz
cd lame-3.96.1
./configure --prefix=/mingw --disable-shared --disable-decoder
make
make install
cd

Now get http://www.xvid.org/downloads.html
tar -xvvzf xvidcore-1.0.3.tar.gz
cd xvidcore-1.0.3/build/generic
./configure --prefix=/mingw --disable-shared
make
make install
mv /mingw/lib/xvidcore.a /mingw/lib/libxvidcore.a

Step 6 live.com rtsp streaming support
Get the sources
http://www.live.com/liveMedia/public/

tar -xvvzf live.2004.12.29.tar.gz (got some errors from tar here but the build worked nevertheless)
cd live
genMakefiles mingw
make


Step 7 MPlayer
For my build I'm using a cvs checkout using cygwin, but cvs snapshots, wincvs or release tarballs should work, too.

In the cygwin shell
cd to your msys home dir

cvs -d:pserver:anonymous@mplayerhq.hu:/cvsroot/mplayer login
cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/mplayer co -P main

When asked for a password, just hit enter. A directory named main will be created.

Now checkout ffmpeg
cvs -d:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg login
cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg co -P main

and copy the libavcodec and libavformat dirs from it to the main dir
cp -R ffmpeg/libavcodec/ ffmpeg/libavformat/ main/

All the sources should be there now.

cd main
./configure --enable-runtime-cpudetection --with-codecsdir=codecs --enable-static --with-livelibdir=/home/username/live
(make sure you use the right path for the --with-livelibdir option)
make

If everything went well your first mplayer.exe can be found in the main dir now.


02.01.2005 Sascha Sommer

--------------------------------------------------------------------
Part 2, enhancement for including x264
--------------------------------------------------------------------
Enhanced step 5 including building/installing x264

Step 5 lame, xvid and x264

Get the nasm sources from http://sourceforge.net/project/showfiles.php?group_id=6208

tar -xvvzf nasm-0.98.38.tar.gz
cd nasm-0.98.38
./configure --prefix=/mingw
make
make install
cd

Install lame from http://lame.sourceforge.net/download/download.html
tar -xvvzf lame-3.96.1.tar.gz
cd lame-3.96.1
./configure --prefix=/mingw --disable-shared --disable-decoder
make
make install
cd

Now get http://www.xvid.org/downloads.html
tar -xvvzf xvidcore-1.0.3.tar.gz
cd xvidcore-1.0.3/build/generic
./configure --prefix=c:/mingw --disable-shared
make
make install
mv c:/mingw/lib/xvidcore.a c:/mingw/lib/libxvidcore.a

Get x264 svn checkout from videolan.org. Either use cygwin svn client or download official ziped win32 binaries from http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91.
Unpack and copy all files in /bin somewhere into your PATH, e.g. /mingw/bin

svn co svn://svn.videolan.org/x264/trunk x264
cd x264/build/cygwin
make
cp bin/libx264.a /mingw/lib
cd ../../
cp x264.h /mingw/include/

--------------------------------------------------------------------
Suggestions and comments are wellcome, especially if send directly to mplayer cygwin mailing list (http://mplayerhq.hu/mailman/listinfo/mplayer-cygwin).

EDIT: Diabled smilies

[JoeBG]

Originally posted by hellfred
Sharktooth has mirrowed (http://forum.doom9.org/showthread.php?s=&threadid=87719&perpage=20&pagenumber=4) the side, and the link is standing somewhere else in one of the relevant threads about ffdshow and x264
Hellfred

Yes, I know this side. But it´s without the mplayer compile. You can get ffdshow and so on, but no mplayer with mencoder.

[hellfred]

Originally posted by JoeBGermany
Yes, I know this side. But it´s without the mplayer compile. You can get ffdshow and so on, but no mplayer with mencoder.
See edited answere above.
Additiona information about compiling mplayer and configuring the source are available in the README file that comes with mplayer source. And i need to disable the smilies.
For just compiling x264, you do not need to install all the libs of the howto, by the way. Just msys,mingw,directxheaders,nasm,x264 and then mplayer including libavcodec should be enough for getting started with x264 encoding.

Hellfred

[celtic_druid]

Site should be back up tomorrow (Monday). Might put some new compiles up. Already have a Athlon-64 compile that I did yesterday. Also did a new XviD compile (cartoon mode in zones) and a ffdshow compile.

[JoeBG]

Originally posted by hellfred
See edited answere above.
Additiona information about compiling mplayer and configuring the source are available in the README file that comes with mplayer source. And i need to disable the smilies.
For just compiling x264, you do not need to install all the libs of the howto, by the way. Just msys,mingw,directxheaders,nasm,x264 and then mplayer including libavcodec should be enough for getting started with x264 encoding.

Hellfred

Puuuhhh Helfred, what can I say. It´s so nice from you to explain everything with so much details. But I´m really not intelligent enough for this :stupid: I´have to wait until tomorrow, when celticdruids side is back. It´s really a pity that noone has the right mencoder for the gui.:(

[ivan_alias]

If this attachment works, then this build of mencoder should work with x264 and Doom9's x264 GUI. It was from Celetic-druids site. Note: only on Athlon CPUs.

[JoeBG]

Originally posted by ivan_alias
If this attachment works, then this build of mencoder should work with x264 and Doom9's x264 GUI. It was from Celetic-druids site. Note: only on Athlon CPUs.

No, there is no attachment. Sadly I have a P4.
But many thanks anyway :thanks:

[Doom9]

Here's the latest version. It's now a regular .NET 1.1 program (compiled under 1.1 SP1 but there are no version issues.. I'm using 1.1SP1 binaries under 1.1 at work).

What's new:
.NET 1.1 binary, thus no need to install a beta framework. Sadly, the GUI also looks less sexy
libavcodec MPEG-4 codec support. I tried to pick the codec options that looked useful to me, leaving away the gazillion of confusion options that are exposed in ffdshow for instance. I hope that makes that codec less confusing to use.
I've also temporarily removed the queue mode, it'll be replaced with something a lot better in the near future.
And there's a readme file now.

Version 0.1:
Queing is almost back. Lots of work was done in the background that will enable persistent profiles in the future. For now, you can add jobs to the queue, visualize them (select a job in the list and all the job's settings will be automatically loaded), move jobs up/down. But you can still only encode the job that's currently configured in the GUI.
Resized some input fields so that there's not so much free room.
x264 subpel refinements now come with a number.
Buffer size is now 0 as default for both codecs (means using mencoder standard, not a buffer size of 0 which obviously makes no sense).
The variable storage adds some potential for failure (string to int conversions), so while you can still enter completely senseless values in textboxes that should contain numbers, you'll get an exception and have to close the program if you try to use an alphanumerical bitrate and the likes..

Version 0.11:
Persistent profiles. You can have an arbitrary number of profiles. They are saved upon closing the program and loaded upon startup. And, you can even edit the XML file in a text editor (just don't mess up or the GUI will balk upon trying to load). Profiles include all the parameters you can configure in the GUI.
Snow codec support
various small changes under the hood.

version 0.11 downloaded 464 times before removal.

[bond]

nice! it also worked now on my good ol' winme :D

some small things coming to my mind:
- for the input .avs file there are no " " used for the paths which causes troubles when spaces are used in the path (the output path already uses " ")
- 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)
- 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...
- the values look somehow moved too close to the left (maybe moving them to the right might look better?)
- maybe something like an automated 2pass would be nice (so that the two passes dont have to be done seperated). like when choosing the 2nd pass the options of the first pass get also added to the cmdl (dunno if thats easily doable tough, the job display you mentioned would be indeed good)
- 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
- 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 ;) )

[ivan_alias]

The 'Snow' option was a big tease!!
:D

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 valueI 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 detailhm 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 (http://www.mplayerhq.hu/homepage/design5/info.html#docs) 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 :D)? 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 withThere 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. :confused:

[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.php?s=&postid=592882#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).

[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 blocksIt 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]
:rolleyes: That´s what all are waiting for :p

[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. :D

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

[Leak]

Originally posted by Doom9
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.

'\r' IIRC.

[Doom9]

I have an idea for those who want to edit the commandline:

When you have done your configuration in the GUI, you can edit the commandline, and if you press encode, the generated commandline is compared with the commandline in the text field, and if the two strings don't match, I use the one from the text field at the bottom of the GUI (obviously there's no error checking here). Similarly, I could save the commandline when a job is being added, then when it's time to visualize the settings / generate the commandline, I generate it, compare it with the stored commandline, and if the results don't match, I use the stored value. That will mean though that your commandline doesn't necessarily match the GUI options that are being dsplayed as you visualize a job, and any GUI changes you make (apart from directly editing the input, output and logfile textfields (not using the fileselector.. that'll trigger a commandline regeneration)) will reset the commandline to the generated one.

Would that be useful?

[Doom9]

as far as queueing goes, even with 4 hours (all my free time yesterday), it's not done yet, but it'll be cool. But I need to figure out how to get the number of frames from my input.. the line that I get on the command window indicating resolution, fps and number of frames
D:\killbill2-1.avs: 640x272, 23976/1000 fps, 1000 framesIs not present on either my redirected stdout nor my redirected stderr. And why mencoder sends information messages to stderr rather than stdout is beyond me.. it doesn't make any sense to send the info about the encoded file to stderr (and reading from both is kind of a problem as they mutually block each other (there's less data on stderr.. so at some point when you try to read, it'll block, where there would still be stdout data to be read that has to be read in order for encoding to continue (there's a status update for every frame encoded).. so the only way I see to get both output is to read them separate threads and to somehow put the output back together (obviously at times it'll not be in the same order as you'd get in the commandline)).

[akupenguin]

D:\killbill2-1.avs: 640x272, 23976/1000 fps, 1000 frames
That line is printed to stderr by avs2yuv, not by mencoder.
I don't know any way to redirect it from the windows cmdline. But if you give up having a commandline at all, and directly exec both avs2yuv and mencoder, you can build any pipes you want in between, including merging stdout and stderr. (At least, it's easy with anything remotely POSIX compliant. I have no idea about .NET)
But I don't know why mencoder mixes them.

[Doom9]

hmm.. I actually redirect both stdout and stderr from my job.bat file, so imho that should give me the output of both programs. In theory, it's easy to create two processes and connect the stdout from the first to the stdin of the 2nd.. I'll have to see if that really works as you can only connect any of the stdio streams after the process has been created.. though what I experienced yesterday is that once redirected, if I do not read stdout, encoding is not even started.

I almost figured avs2yuv gave that output.. though I don't quite get why its sent to stderr.. being an informational message, would it not make more sense on stdout?

But I don't know why mencoder mixes them.I suppose it's simply a timing issue.. mencoder is faster to dump its first few lines to stdout, or perhaps windows is slow to display stderr output?

[stax76]

But I need to figure out how to get the number of frames from my input...


1. Win32 DShow API: I experienced lot's of problems and besides that COM+ overhead

2. Win32 avifile API: I'm using this in my apps, I've made a C# class (GPL). Note: with C++/CLR you don't have to define the interfaces which can save you a lot time if you don't need to expose the complete API and it's faster than C# because it uses the optimizing backend of the native compiler. I've used C++/CLR a couple of times, the new implementation rocks.

3. write a log file with AviSynth, AutoGK does this too

[akupenguin]

Originally posted by Doom9
I actually redirect both stdout and stderr from my job.bat file, so imho that should give me the output of both programs. In theory, it's easy to create two processes and connect the stdout from the first to the stdin of the 2nd.. I'll have to see if that really works as you can only connect any of the stdio streams after the process has been created..
I was thinking more like (untested):
int avs2me[2];
int avs2enc[2];
int enc2me[2];
pipe(avs2me);
pipe(avs2enc);
pipe(enc2me);
if(fork()==0){
if(fork()==0){
dup2(avs2me[1], fileno(sterr));
dup2(avs2enc[1], fileno(stout));
execvp("avs2yuv" /*...*/);
}
dup2(avs2enc[0], fileno(stin));
dup2(enc2me[1], fileno(sterr));
dup2(enc2me[1], fileno(stdout));
execvp("mencoder" /*...*/);
}
FILE *read_from_mencoder = fdopen(enc2me[0], "r");
FILE *read_from_avs2yuv = fdopen(avs2me[0], "r");

though what I experienced yesterday is that once redirected, if I do not read stdout, encoding is not even started. MEncoder uses normal (blocking) output, so if it tries to print something and there isn't room in the stdio buffer...

I almost figured avs2yuv gave that output.. though I don't quite get why its sent to stderr.. being an informational message, would it not make more sense on stdout? In most programs that would make sense, but I'm sending the video to stdout.

[Doom9]

In most programs that would make sense, but I'm sending the video to stdout.ahh, now that you mention it..

the thing about .NET and native is that while you can mix it, mixing gets ugly rather easily. Come to think of it, I actually have software running at work where I redirect both stdin and stdout from certain programs, just never sned the output from one to the input of another.

I don't suppose there are any linewraps or similar in the avs2yuv output, is there? Is the end of the video data somehow signalled?

And msdn has just proven to be useful yet again. I found an example where multiple programs are piped (similar to your example.. I have some tested code on this at home that I wrote a couple years ago so I'd have a working example just in case :)) I just won't be able to put mencoder's stdout and stderr messages in the proper order, so that won't be too nice, but I guess I'll just have to place the stderr events just prior and after all the status updates and it should roughly match the standard commandline output.

[daveidmx]

@doom9

You said the encoder gives a status line after every frame, right?
Since the encoder's output is blocking and you have to read it before the encode will continue, won't that catostrophically slow down the encode?

Is there a way to force an in-thread buffer on the ostream so you don't have to keep waiting for the task scheduler every frame?

[Doom9]

actually, speed appears to be quite good in my 1000 frame sample that I'm using for testing. and keep in mind that if the stdout has to be read, it does not apply to redirected stdouts only.. but also to regular stdout.. e.i. cmd.exe will also have to read it before encoding continues. And if you encode in VDub, you also have all the status updates (frames encoded, percentage complete, video size) that'll slow down encoding (any progress indicator does).

[daveidmx]

I'd always figured status indicators were best made passive, i.e. updating by independantly reading counters say four times a second or something.

But:
Originally posted by Doom9
actually, speed appears to be quite good in my 1000 frame sample that I'm using for testing.
That's what really matters.

Cheers!

[Doom9]

I'd always figured status indicators were best made passive, i.e. updating by independantly reading counters say four times a second or something.And who writes those counters? the encoding process ;) And every CPU cycle you use for something else than encoding makes encoding slower.. it's just the matter of things.

Anyway, version 0.12 is out.

Queue mode is now enabled. At the end of each job, a log is being shown with the standard output from mencoder. Unfortunately, mencoder writes a lot of informational messages to the standard error output (and the windows command shell combines that), so there's a bunch of messages missing from the log right now.
the two commandline generation bugs reported have been fixed.
strict compliance mode removed from snow (checking it would throw an error and encoding would not start).

And here's the todo:
persistent jobs
redirect and read standarderror from mencoder and put output in log window
make progressbar active (that requires different queue handling.. to those who follow the technical discussion: instead of launching job.bat, pipe avs2yuv and mencoder myself, and also read the avs2yuv stderr which gives the input properties like nb frames, which is required to feed the status bar (mencoder only gives number of frames encoded)
status window during encoding
status change in the queue as its done in virtualdub
tooltips

I haven't received any feedback on the commandline editing, so I suppose nobody is interested and subsequently that feature is currently not on the todo list.

v0.12 downloaded 62 times before removal.

[hellfred]

Originally posted by Doom9
I have an idea for those who want to edit the commandline:

When you have done your configuration in the GUI, you can edit the commandline, and if you press encode, the generated commandline is compared with the commandline in the text field, and if the two strings don't match, I use the one from the text field at the bottom of the GUI (obviously there's no error checking here). Similarly, I could save the commandline when a job is being added, then when it's time to visualize the settings / generate the commandline, I generate it, compare it with the stored commandline, and if the results don't match, I use the stored value. That will mean though that your commandline doesn't necessarily match the GUI options that are being dsplayed as you visualize a job, and any GUI changes you make (apart from directly editing the input, output and logfile textfields (not using the fileselector.. that'll trigger a commandline regeneration)) will reset the commandline to the generated one.

Would that be useful?
I understood the first part, and I would welcome, that hand-edited comannd-line is favoured over generated commandline and used in case of pressing encode. The one who tweaks or messes with the comanndline directly should be able to pin down mistakes in there commandline and remove them, if encoding fails.
If the elements of the GUI are not set perfectly after reloading an saved and handdtuned job, that is nothing serious for me. Again, the one who messes with comandline directly should be well knowleged and not easily confused.

Hellfred

[hellfred]

Originally posted by Doom9

I haven't received any feedback on the commandline editing, so I suppose nobody is interested and subsequently that feature is currently not on the todo list.
Sorry for awnsereing that late, but i am quite buiy with my diploma thesis and spent at least 12 houres a day in university for it, so i did not have the leisure to read and awnsere your suggestion before.

Hellfred

[JoeBG]

Originally posted by Doom9
And who writes those counters? the encoding process ;) And every CPU cycle you use for something else than encoding makes encoding slower.. it's just the matter of things.

Anyway, version 0.12 is out.

Queue mode is now enabled. At the end of each job, a log is being shown with the standard output from mencoder. Unfortunately, mencoder writes a lot of informational messages to the standard error output (and the windows command shell combines that), so there's a bunch of messages missing from the log right now.
the two commandline generation bugs reported have been fixed.
strict compliance mode removed from snow (checking it would throw an error and encoding would not start).

And here's the todo:
persistent jobs
redirect and read standarderror from mencoder and put output in log window
make progressbar active (that requires different queue handling.. to those who follow the technical discussion: instead of launching job.bat, pipe avs2yuv and mencoder myself, and also read the avs2yuv stderr which gives the input properties like nb frames, which is required to feed the status bar (mencoder only gives number of frames encoded)
status window during encoding
status change in the queue as its done in virtualdub
tooltips

I haven't received any feedback on the commandline editing, so I suppose nobody is interested and subsequently that feature is currently not on the todo list.

Hi doom9,

I have the following error message:
"Can´t find avs2yuy"

So I deltet Version 0.12 and started 0.11 und this version has no problems because avs2yuy is in the same directory


Edit: But b-frames seem to work now.

[akupenguin]

Originally posted by Doom9
I don't suppose there are any linewraps or similar in the avs2yuv output, is there? Is the end of the video data somehow signalled?
The only outputs from avs2yuv (all to stderr) are:
"foo.avs: 640x272, 23976/1000 fps, 1000 frames\n" (always),
"converting YUY2 -> YV12\n" (if the avs didn't output YV12),
and error messages (if invalid options at startup, or caught from avisynth at any time).

It signals the end of the video by fclose(stdout) and then exiting. (no message)

[Doom9]

"Can´t find avs2yuy"Huh? Where? I don't even check for the existence of that software, plus it's avs2yuv, not avs2yuy, and I've been encoding a bunch of batchjobs with it just minutes prior to posting and the only thing I changed is re-enabled the old code for single job encoding (pressing Encode in the input tab) - and that is code from the previous release that I had just commented out.

I absolutely need to see your commandline. What happens if you execute job.bat manually (you need to make sure that the directory from which you execute it contains avs2yuv.exe and mencoder.exe)?

btw does anybody know if mencoder uses different exitcodes depending on whether encoding succeeded or failed? I already have defined a job status error but there's no signalling yet, and analyzing the stderr output seems not the way to go as there can be different error messages that not necessarily have some text element in common.

[JoeBG]

@ doom9

In the moment I don´t know how to use batch processing. I need a tooltip for this. I get the jobs in the queue, but nothing happens when I press start. So I don´t have any success with this new function.

So I only use single encoding. This works fine with 0.11. But it fails with 0.12 with the same job because he cannot find avs2yuy. In the moment I´m at work. I can post the commandline this evening.

Would be very nice if someone could help me. I´m a little depressed about this in the moment. :(

[Doom9]

Batch encoding is simple. Configure encoding session, press Queue button, configure next encoding seesion, press Queue button again. Then you have a list of jobs in the Queue tab. Press Start will start encoding. You do not see anything happening right now.. but if you start the task manager you should see the CPU usage peak.. that means it's encoding. Keep watching the queue tab, you'll get an fps number and the number of frames encoded updated every 50 frames. And the Start button will suddenly be a Stop button, and the Abort button will be enabled.

Things work very much the same as in the virtualdub job list. In status waiting, jobs will be encoded if you start. If you click on jobs and the status changes to postponed, it'll not be encoded. Abort can be used to abort encoding right away. Stop can be used to stop the queue (the current job is still being encoded). If you know how to handle VirtualDub's jobs, MeGUI's jobs will act just the same (but unlike VDub, you can still add new jobs to the queue).

avs2yuyThere is no such program.. it's called avs2yuv, with a vat the end, not a y. If the commandline includes a y, then obviously I typed something wrong. Come to think of it though, I have an idea why single job encoding doesn't work.. I should've left it to background encoding. I completely revamped the commandline generation and I suppose the old code needs the old processing - though since I only have the code at home I can't check right now. But I'm 200% positive batch encoding worked. I've been encoding up to 3 queue jobs after another, one with each codec. Just because you don't immediately see anything in the GUI doesn't mean it's not encoding.. except for the buttons changing and the status of the currently being encoded job changes, all you can go by is CPU usage, and keep watching those status indicators because they will change eventually.

[JoeBG]

Ok, I´ll try again this evening. But when I press "start" a new window with the commandline pops up. I´ll try again.

[Doom9]

Ok, I´ll try again this evening. But when I press "start" a new window with the commandline pops up.Run job.bat and you'll see why it fails. I just did a quick test here.. no avisynth installed and no mencoder.. and here's what I get from the commandline


yuv "test.avs" - | mencoder -
-ovc lavc -o NUL: -passlogfile "mencoder-2pass.log" -lavcopts vpass=1:vbitrate=8
00
failed to load avisynth.dll
'mencoder' is not recognized as an internal or external command,
operable program or batch file.All those errors are sent to stderr which I'm currently not reading.. hence you only get the commandline which is sent to stdout (and that's what I'm reading). So, it is working, just failing because of a reproducible error (I obviously have no ripping software installed at work)

[JoeBG]

@ doom9

Works perfect in batch modus. Ididn´t saw a dos window and thought it´s not working. Sorry for this.

It´s working perfect with b-frames and it´s very fast and accurate. I´m testing with a really difficult scene from LOTR2. It´s a very foggy scene and you can see very good the differences between sex264 and MeGUI. MeGUI brings better results than sex264. Because of mencoder?

[Doom9]

Here's Version 0.13.

What's new:
Persistent profiles (even status and order is preserved)
Disabling of non used logfile and output file fields depending on the selected encoding mode
Queue status change via double click (similar to VDub joblist, but I don't preserve the error state as mencoder doesn't clearly separate between error messages sent to stderr and informational messages sent there - and thus I can only guess what is an error message)
mencoder's stderr is now redirected, so you'll get to see all the mencoder messages you'd see on the commandline (you get to see everything at once once encoding is complete)
2pass-firstpass jobs no longer list an output file that's not going to be used

Todo:
Status window during encoding
Enable the progress bar in the Queue tab
Enable commandline editing for advanced users
Tooltips for the various codec options
Turbo mode for x264.

If anybody has an idea how to reliably figure out if mencoder has thrown an error, let me know (basically the error status in the queue is already there, I just don't signal it because I'm looking for a way not to have to match stderr output lines but figure out something more reliable than text comparisons to determine what is an error).

Similarly, I'm wondering if besides Joe anybody is still using the GUI.. it seems the x264 VfW is attracting a lot more people, and the main reason for me to start a GUI was that there was no GUI specifically for x264 encoding.. I wouldn't want to spend every free minute on something nobody uses.

@bond: I've been resizing GUI elements over time, I hope it's better now. Actually, in the first version I tried right align, but it just didn't feel right.. and that's because left aligned is the standard.

As for automated two pass encoding, it's mainly a settings thing. With profiles, you can quicly set up two pass encoding and have access to all configuration parameters. With a 5th encoding mode "automated" twopass, there's no possibility to configure the first pass. Is that a good idea, and if so, what first pass settings should be used?

I also named the codecs ASP and AVC. I'll add some explanatory tooltips eventually (it's kind of a low priority thing.. as it's not so much a coding challenge but a compiling all the info challenge ;)

version 0.13 downloaded 52 times prior to removal

[North2Polaris]

@ Doom9,

So far, I have been unable to get the latest versions of the these programs to work and Windows XP shuts down mencoder and offers to send off an error report to Microsoft.

Probably a simple mistake on my part. The script works fine using VDubMod and x264 VfW.

The following is the mencoder log report:

C:\Documents and Settings\My Documents\My Downloads\DVD\mencoder>avs2yuv "F:\avalon.avs" - | mencoder - -ovc x264 -x264encopts qp_constant=10:deblockbeta=-3:rc_buffer_size=700 -o "F:\test.avi" -of avi -ffourcc x264
MEncoder dev-CVS-050110-15:31-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping: 2)
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

File not found: 'frameno.avi'
Failed to open frameno.avi
Reading from stdin...
success: format: 0 data: 0x0 - 0x0
YUV4MPEG2 file format detected.
YUV4MPEG2 Video stream 0 size: display: 640x352, codec: 640x352
VIDEO: [YV12] 640x352 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:12 fourcc:0x32315659 size:640x352 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 640 x 352 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
F:\avalon.avs: 640x352, 23976/1000 fps, 153528 frames
Output error: wrote only 317552 of 337920 bytes

Suggestions?

Thanks.

North

[RadicalEd]

I've been using MeGUI for Snow encoding, as it's the only GUI that completely supports it.

[Doom9]

@North2Polaris: How many frames have actually been encoded?

[Doom9]

@akupenguin: I have created a pipe between stdout of avs2yuv and stdin of mencoder, but mencoder only writes the AVI header, then exits. I see data being written to the pipe from avs2yuv till the end though. What could make mencoder exit prematurely?

[North2Polaris]

Originally posted by Doom9
@North2Polaris: How many frames have actually been encoded?

@Doom9,

The file that is created is empty (0 KB).

I ran the same script through the GUI and encoded to Xvid.

North

[Doom9]

@North2Polaris: I tested your script on my PC, and it works, so it's not a GUI problem but a mencoder problem. What could cause this is beyond me though.

[bond]

Originally posted by Doom9
2pass-firstpass jobs no longer list an output file that's not going to be usedhm i dont get the firstpass job to be added. when pushing "queue" a message pops up that says "make sure .log, input and output is defined". as the log and the input is there, the missing output file causes the troubles (but of course the output doesnt have to be defined in firstpass)
also it has to be mentioned that this problem doesnt occur when there is already another job in queue listed (this job of course doesnt need to have to do anything with the firstpass job)

another thing: done jobs cant be deleted from the queue, as they are still listed as "processing", as if they run atm
i had to delete the job file to get rid of the already done job

Similarly, I'm wondering if besides Joe anybody is still using the GUI.. it seems the x264 VfW is attracting a lot more people, and the main reason for me to start a GUI was that there was no GUI specifically for x264 encoding.. I wouldn't want to spend every free minute on something nobody uses.i am using it (just did not a lot of encodes lately).
also mencoder and your gui is the only solution to use when you want to avoid having missing frames when using b-frames (thanks to vfw's limitations)
mencoder is technically simply superior to vfw (i hope we will see avc-in-mpg output too soon)

@bond: I've been resizing GUI elements over time, I hope it's better now. Actually, in the first version I tried right align, but it just didn't feel right.. and that's because left aligned is the standard.hm its not a big problem, and also with text the problem isnt there. its just that numbers are touching the left side of their box here
is there something like "center"?

maybe you want to rename the macroblock options to something like used in sex264, i think its more explanatory if someone doesnt look at the mencoder manpage

[North2Polaris]

Originally posted by Doom9
@North2Polaris: I tested your script on my PC, and it works, so it's not a GUI problem but a mencoder problem. What could cause this is beyond me though.

@Doom9,

Thanks.

I did a Google seach on "File not found: 'frameno.avi'" -- lots of hits related to mencoder.

More research to do!

North

[Palikrovol]

Originally posted by North2Polaris
@Doom9,

Thanks.

I did a Google seach on "File not found: 'frameno.avi'" -- lots of hits related to mencoder.

More research to do!

North

I had this problem with the build from the mplayer homepage, but when i changed to the celtic_druid builds then just worked.

regards

[Doom9]

I had this problem with the build from the mplayer homepage, but when i changed to the celtic_druid builds then just worked.
Well, the frameno.avi is not an error, you'll always get it. But, the manual says you need celticdruid's build.. x264 is not possible using the official mencoder builds ;)


Attached is version 0.14:

It has a working progress bar (in the queue tab)
allows custom commandlines (you are warned if you use a custom commandline)
the "hm i dont get the firstpass job to be added. when pushing "queue" a message pops up that says "make sure .log, input and output is defined"." error is fixed


and also with text the problem isnt there. its just that numbers are touching the left side of their box hereThat's standard behavoir.. check any other GUI ;)

maybe you want to rename the macroblock options to something like used in sex264, i think its more explanatory if someone doesnt look at the mencoder manpageThere's not enough room for that. It's a thing for tooltips (and the mencoder manpage is useless when it comes to those options ;)

another thing: done jobs cant be deleted from the queue, as they are still listed as "processing", as if they run atmI cannot reproduce this behavoir. You are using at least version 0.13, are you not? It might've been an issue prior to that, but the code from 0.13 only stops deletion if status = 1 (processing). I've been able to delete done jobs just fine.

@North2Polaris: Could you try to run the batchfile from the commandline (make sure you change to the directory where it resides) and see if you get any additional output?

I think I figured out something.. the same just happened to me. Turns out I had 2pass first pass selected, but for some wicked reason the GUI tried to do something else. When I went back to the codec settings, changed the encoding mode twice (one to something I didn't really want, and then back to what I wanted), I just had to enter a logfile and things were okay again.

version 0.14 downloaded 23 times prior to removal

[bond]

Originally posted by Doom9
I cannot reproduce this behavoir. You are using at least version 0.13, are you not? It might've been an issue prior to that, but the code from 0.13 only stops deletion if status = 1 (processing). I've been able to delete done jobs just fine.same behaviour with 0.14
after the encoding is done the status stays at processing (eg after a firstpass the second pass doesnt get started as megui thinks the first pass is still running)

i use relatively short inputs, eg 40 frames, dunno if that makes a difference

[Doom9]

try larger files.. I only send a status update every 50 frames (though one should be sent at the end).

I'm using 1000 frames and I have no problem with subsequent jobs being started.

[bond]

no difference

when using little bit more than 50 frames, after 50 frames the progress par stays unfinished at "frames encoded: 50", job is still saying processing, even after mencoder is closed already
when using little bit more than 100 frames, the par stays at "100 frames encoded" aso...

edit: the encodes seem to be done fine

[Doom9]

well.. the code is fine, you can verify tomorrow.. so unless somebody else reports this, I'm going to blame the crappy OS you're using ;)

[North2Polaris]

Originally posted by Doom9
@North2Polaris: Could you try to run the batchfile from the commandline (make sure you change to the directory where it resides) and see if you get any additional output?

@Doom9 and @Palikrovol,

I decided to download the latest mplayer beta version from:

http://www.mplayerhq.hu/MPlayer/releases/win32-beta/

This is helpful if you ever want to try mplayer.

Then I extracted the files from the latest Celtic_druid mplayer version, which includes Mencoder with x264 support, over that:

http://celticdruid.no-ip.com/xvid/mplayer/

Then I added the lastest version of the GUI and the latest version of avs2yuv.

This works, both the "direct" encode and from the queue.

And the file plays beautifully in the OEM version of Nero ShowTime without the h.264 "upgrade warning" that I get when I play a file encoded using VdubMod and the VFW version.

Thanks.

North

[JoeBG]

Originally posted by Doom9
Attached is version 0.14:

It has a working progress bar (in the queue tab)
allows custom commandlines (you are warned if you use a custom commandline)
the "hm i dont get the firstpass job to be added. when pushing "queue" a message pops up that says "make sure .log, input and output is defined"." error is fixed
[/B]

It´s already working on a film. The Turbo is very good and I like the progress bar. Congratulations :)

[Doom9]

Here's Version 0.15.

Changelog:
Status window during encoding with all the info you could desire
Removed FPS and Frame indicator from queue Tab.
Various minor GUI fixes and internal changes

One thing I noted during development: since I've only added certain checks in later versions, profiles and jobs from older versions can potentially cause problems in new versions.

@North2Polaris: You don't even have to dowload the official mencoder version if you just care about encoding.

If I look at my toto.. only tooltips are left. And I just figured out how to do them.. it is so time consuming that I won't add a tooltip for every option after all.. that would be way too timeconsuming.

Also note that x264's "bits<" messages on mencoder's stderr make the GUI chocke for some reason (in a dos window eventually encoding starts). I think aku meant to remove those so it might not hurt using the latest mencoder version.

v0.15 downloaded 1095 times before removal.

[RadicalEd]

I wonder if it would be possible to get mp4creator to accept stdin... if so, I might be inclined to add mp4 output to MeGUI after the sources are released.

[Leo 69]

Please help me guys, I'm at a loss :( I can't encode neither to AVC
nor to Snow using the latest GUI and latest mencoder (6 Jan)
It just stops at the start !

Log :

--------------------------------------------------------------
C:\Documents and Settings\Administrator.TEFLON\My Documents\mplayer>avs2yuv "C:\VIDEO_TS\Ace.avs" - | mencoder - -ovc x264 -x264encopts bitrate=700 -o "C:\Documents and Settings\Administrator.TEFLON\Desktop\1.avi" -of avi -ffourcc VSSH
MEncoder dev-CVS-050106-11:19-3.2.3 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon MP/XP/XP-M Barton (Family: 6, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled with runtime CPU detection - WARNING - this is not optimal!
To get best performance, recompile MPlayer with --disable-runtime-cpudetection.
File not found: 'frameno.avi'
Failed to open frameno.avi
x264encopts is not an MEncoder option

Exiting... (error parsing cmdline)
C:\VIDEO_TS\Ace.avs: 320x240, 23976/1000 fps, 125274 frames
Output error: wrote only 113440 of 115200 bytes

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

Whats wrong?
:confused:

[ivan_alias]

x264encopts is not an MEncoder option

Looks like you don't have Mencoder from Celticdruid

The vanilla mencoder wont work, you need one thats compiled with x264 support. Have a read through this thread for the relevent info and links.

Ivan

[Doom9]

@bond: what happens if you use reasonable input (1000 frames and above)? In the latest version, do you get to see the progress window, progress updates and at the end of a job, is the progress window closed again and the log being shown?
does anybody else have that problem that job queueing doesn't work, and if so, what OS are you using?

[jonjon51]

@ivan_alias and all: Celtic_druid had upload all version of Mencoder, for each processor (P4, Athlon XP/Tbird). the error "x264encopts is not an MEncoder option" was solved by replacing the right build for my processor (Athlon XP 2400+) :cool:

[Leo 69]

@ jonjon51

Oh,yeah it'll take one day to download it from his server :D

[IgorC]

can last build of mencoder(megui x264) do 2 pass correctly?

[easyfab]

Little bug report for Megui 0.15

in "AVC codec" the number of ref frame works not correctly
For exemple when selecting 15 it give frameref=8


Question :
Is it possible to use x264.exe with avs2yuv ?
It doesn't works for me.

[Doom9]

n "AVC codec" the number of ref frame works not correctly
For exemple when selecting 15 it give frameref=8
Let me guess: you have turbo checked, right? I now have a tooltip there.. if you check turbo, the number of ref frames is divided by two and rounded up. As for subpel refinements, if it's > 3, it'll be set to 3, otherwise it'll be reduced by 1. You'll note that even though commandline doesn't match the GUI, there's no warning thrown, but if you start to edit the commandline on your own, then you'll get a warning if want to start encoding. So, no warning = everything is AOK ;)

[easyfab]

Your right I was in turbo mode :)
Sorry for this report.

[Doom9]

@easyfab: don't worry, it's not that obvious unless you know what turbo mode does. I've added a warning about this in the nex release.

Here's release 0.16 (downloaded 1172 times before removal)

Changelog:
You can change the process priority during encoding
More information in the queue (start & end time, FPS)
Certain tooltips.. hover over the label describing an option to see them
Various internal refinements

Keep in mind that the structure of various internal datastrctures have been changed. After starting the new version for the first time, immediately close it again so the new profiles and jobs will be created. It could still be that after this certain of your job settings do not match anymore.

I hope I have not added too many bugs as I'll be away for the next 3 weeks and unable to fix any bugs.

[Doom9]

and here's the source code under the GPL.

It is a VS2003 project. Don't know if it works with any other C# development environment.

Oh, and since I've used an W32 AVIFile wrapper, Mono will probably be out of the picture from here on now. I wanted to use avs2yuv's stderr output, but for some wicked reason, even though I eventually get to see the avs2yuv line about how many frames and what resolution the source has, when I redirect stderr and read from it, I only get that info after encoding has completed, which is useless to me (I need before the first frame is encoded so that I can send status updates to the GUI)

[Doom9]

can last build of mencoder(megui x264) do 2 pass correctly?What makes you think it cannot? As far as the GUI is concerned, unless the mencoder switches change it should never be a problem.

[JoeBG]

Originally posted by Doom9
@easyfab: don't worry, it's not that obvious unless you know what turbo mode does. I've added a warning about this in the nex release.

Here's release 0.16

Changelog:
You can change the process priority during encoding
More information in the queue (start & end time, FPS)
Certain tooltips.. hover over the label describing an option to see them
Various internal refinements

Keep in mind that the structure of various internal datastrctures have been changed. After starting the new version for the first time, immediately close it again so the new profiles and jobs will be created. It could still be that after this certain of your job settings do not match anymore.

I hope I have not added too many bugs as I'll be away for the next 3 weeks and unable to fix any bugs.

Thank you very much. I just finished my second long film with it (0.15). Looks great, but I cannot transfer it to MP4 because of b-frames. Anyone a idea?

[Doom9]

Anyone a idea?Yeah, wait until a tool comes out that supports b-frames ;) That's something you have to check first. Sadly, MP4 is still very much in the pitiful state it was when I wrote the first MP4 guide years ago. It didn't take OGM long to get a good muxing and cutting tool, MKV support it right out of the box, but with MP4? Nada. Perhaps if the MP4 tools grow up one day I can add MP4 output to MeGUI.

[Doom9]

@RadicalEd: if you decide to start coding, perhaps you could also have a look at the encoder class. Attached is something I've been working on.. I've tried to launch avs2yuv and mencoder each in its own process and pipe stdout from avs2yuv to stdin from mencoder. While the pipe appears to work and feeds data to mencoder, mencoder always exits right away and doesn't give me any indication why it exits.

[opsis81]

Since status window during encoding came up MeGUI doesn't work for me.:(
When encoding starts,progress window shows up and then suddently MeGUI crashes.Avs2yuv and mencoder keep working in background.
I have the latest mencoder from http://www.mplayerhq.hu/MPlayer/releases/win32-beta/ , the latest version of avs2yuv , winxp pro and Microsoft NET 2.0.40607 .
Each time I download a new version I delete all previous jobs and presets.
All versions before 0.15 used to work.
MeGUI 0.15 and 0.16 simply don't work for me.

[MaXiMuS]

Installation instructions:

You'll have to copy the latest version of avs2yuv (http://students.washington.edu/lorenm/src/avisynth/avs2yuv/)
and mencoder (http://celticdruid.no-ip.com/xvid/mplayer/) to the same directory as the GUI.

Note that if you're using an official mencoder build from the mencoder homepage, the x264 support will NOT work.

does anyone have better mirror than http://celticdruid.no-ip.com/xvid/mplayer/

i can not download at all :devil:


thx

[JoeBG]

@ doom9

Originally posted by Doom9
Yeah, wait until a tool comes out that supports b-frames ;)

We only have to wait for the next release of mp4creator. You can read it here (http://forum.doom9.org/showthread.php?s=&postid=597264#post597264) or directly on the sourceforge site here (https://sourceforge.net/forum/forum.php?thread_id=1201621&forum_id=59136)

So next MeGUI directly supports MP4 :D (just a little joke :) )

[JoeBG]

Originally posted by celtic_druid
bittorent would be no good as there are a large number of files, which means lots of torrents or a large one which most people only want a small percent of.

x264 is now upto R103 by the way with R101/102 only being VFW changes though.

Revision 103:
finish subpixel motion refinement for B-frames (up to 6% reduced size of B-frames at subq <= 3)

Hopefully once the mirroring is all sorted everything will be fine. Just means that a max wait of say 24hours between me putting a file up and it getting mirrored.

great!!!!

[junglemike]

Hello guys, I wanted to try MeWig, but i have a problem:
No matter what i do - "sound settings" tab is disalbed, i cannot do anything there. I did install .Net framework 1.1 and tried MeWig 0.009 and 0.009a on 2 computers - but result is the same - disabled sound settings tab.
Any thoughts?

[celtic_druid]

On the files tab, press next. It should then detect the audio stream(s) and enable the tab.

[Doom9]

@opsis81: could you downgrade to .NET 1.1 and use celticdruid's compiles, then try again? For once you're using the official builds that I do not trust (don't know if they've added x264 support by now), and .NET 2.0 is in beta.. one of the reasons I went back to .NET 1.1 is because the new IDE was really buggy and had to be restarted all the time.

When a .NET application crashes, you should get a stacktrace. If you still get it with only .NET 1.1 installed (I think after uninstalling 2.0 you have to reinstall 1.1), please post the stacktrace here. GUI update code is quite sensitive, and if they changed something in the GUI components in 2.0, I would not rule out that at this early stage it could case problems.

So next MeGUI directly supports MP4There's still the issue of cutting, and bitrate calculations. FYI, muxing overhead is different depending on if you use B-frames, and if the number of B-frames is adaptive or fixed. And I don't have all the formulas that would be required for a reasonable bitrate calculation, plus, since I cannot know how the GOPs are going to look like, the user would have to be able to specify one of the 3 B-frame modes used prior to encoding. But, if a reasonable way can be found, I'm inclined to add MP4 output.

[JoeBG]

Originally posted by Doom9
But, if a reasonable way can be found, I'm inclined to add MP4 output.

Message transmitted:D So we hope it´s possible.

[opsis81]

@Doom9
I downgraded to .NET 1.1 and everything works OK now.Thank you for your help.:)

[JoeBG]

The latest celticdruid-mencoder that works for me with MeGUI is from January. I cant´t detect a newer one here (http://www.aziendeassociate.it/cd.asp?dir=/mplayer) . Has the mirrow for mencoder moved?

[JoeBG]

Originally posted by hellfred
Seven hours ago, demuxing support for avs was added to mplayers cvs.


This means three things/problems for me:
- MeGui will not work automatically with this new mencoder because it has avs2yuv commandlines
- I have to compile it myself
- noone knows about new mencoder compiles from celticdruid

[MaeWanto]

Originally posted by opsis81
I'm waiting for a new MeGUI version with xvid and x264 support and without the need of avs2yuv.Don't dissapoint me Doom9;)
I would add AAC-LC audio encoding and MP4 muxing/hinting ...
Thanks in advance Doom9 ;)

[Doom9]

- MeGui will not work automatically with this new mencoder because it has avs2yuv commandlinesActually, I see no reason why it shouldn't work. I very much doubt that they'd allow a patch that breaks YUV input from the commandline. So who cares if you need avs2yuv or not.

@MaeWanto: as I pointed out here (http://forum.doom9.org/showthread.php?s=&postid=610403#post610403) audio encoding is a whole can of worms and simply not possible the way you want it (only opensource tools). BeSweet is clearly THE audio encoding application in this line of business, and it first doesn't support faac, and second it's close source. Please do not just discard very valid technical objections because you want something. I don't care what you want, I care what can be done reasonably. Those are two different pair of shoes altogether.

[bond]

Originally posted by Doom9
Actually, I see no reason why it shouldn't work. I very much doubt that they'd allow a patch that breaks YUV input from the commandline. So who cares if you need avs2yuv or not.indeed, it avs2yuv will still work
of course for simplicity direct handling in mencoder will lead to that one tool less is needed (also its maybe faster if you dont have to go via piping?)

Originally posted by opsis81
http://4nykey.nm.ru/bin/mplayer-cvs.exe
If your browser can't download it go to http://4nykey.nm.ru/bin/ first.hm, both dont work here :(

[JoeBG]

For me MeGUI 16 does not work in the moment (mencoder celtic druid from yesterday or drm 2005.02.01). The following happens:

When I start the process (pass 1 from 2, batch processing) nothing happens. When I look in taskmanager, mencoder is not working. When I totally stop MeGUI, mencoder is working, I can see it in taskmanager.
It´s only with real movies, not with small clips. With small clips I have to wait about 30 seconds and then the process starts.

I made my last big movie wit MeGUI 15, very successfull. Anyone the same experiences? I´ll test more this evening :) , changing m,encoder to the release of the middle of January or MeGUI back to version 15.

[tiki4]

I have the same problem here. The last version of MeGUI I can use is 0.13. 0.15 and 0.16 show exactly the problem you mentioned. My configuration is WinXP SP2 + .NET 1.1 SP1. I also tested Win2K SP4, same problem. I'm not sure where this problem is located, unfortunately.

tiki4

edit: typo

[Doom9]

@tiki4: can you confirm that the problem only happens with newer builds?

Since my code has been unchanged for weeks, it must be something in mencoder. As I keep track of the progress by reading stdin and stderr, perhaps somebody who's into mencoder development can confirm or deny this: has something in the way data is being written to stdout and stderr been changed?

[tiki4]

Sorry, I don't have a clue. I used my own mencoder builds (daily cvs + x264 svn) to test. I only can say that I also tested celtic druid's builds (I think from 20/01/2005 on) and they also didn't work for me. The strange thing is that MeGUI 0.13 works, but 0.15 and 0.16 not (never got 0.14). I think you implemented the progress bar in between these versions or am I mistaken there?

tiki4

[Doom9]

I think you implemented the progress bar in between these versions or am I mistaken there? Yes.

Can you use MeGUI to just give you the commandline, then encode in a dos window using a version that works with MeGUI and one that doesn't and compare the commandline output? It must have something to do with commandline processing (I extract certain information from the commandline for the progress bars and status window.. if that info isn't there, the commandline reader might throw up at some place and that stops the whole encoding process).

Also, if you can figure out how long a source has to be for the problem to ocurr. Debugging with full movies is obviously not something that I can readily do.

[tiki4]

I'll try to find out what causes the problem. Give me some time, though, I'm rather busy with finding a job these days.

tiki4

[JoeBG]

@ doom9

I finished my tests with a real movie(2 hours) with mencoder 2005.01.20, 2005.02.01, 2005.02.14
MeGUI Version 15 and 16: Does not work with any mencoder with movies, just with clips

I deletet older versions but I remember a film with Version 13 or 14 where I startet both passes manually because batch processing was not implemented. Since then I testet clips.

I don´t have the older versions anymore => can´t test them again, sorry.

[Doom9]

Does not work with any mencoder with movies, just with clipsWhat exactly does "does not work" mean? The behaviour you described (encoding doesn't start until you close MeGUI) or something else?

And another thing.. is this problem codec related? Can you try with the lavc mpeg-4 codec (the fastest of the 3)? I guess you can see where I'm getting at.. finding the least timeconsuming way to reproduce.

[hpn]

My test setup:
MeGUI 0.16
mplayer2005.02.14.Athlon-XP
avs2yuv 0.23
.NET 2.0.40607
x264 rev.127
Windows XP SP2 with all (most?) post-SP2 critical patches installed

I did about 20 AVC tests starting from a full movie avs and then started dividing the frame number by 2. Encodes with less than 5000 frames work fine. Any avs input that contains 5000 or more frames crashes MeGUI immediately after I press "encode".

It's easily reproducible:
trim(0,4999) - works fine (also fine for any number < than 4999)
trim(0,5000) - crashes (also crashes for and any number >5000)

I don't know if this 4'999 is some general rule or movie input specific or something else, but those who get the same "short clips only" problem could also test it for both 4999 and 5000 frames (if not, just start from a higher frame number and then start deviding the frame number up or down by 2 until you reach your "critical mass"). After each MeGUI crash, mencoder.exe keeps working at 100% in the background, producing a valid "mencoder-2pass.log", so I could wait and finish succesfully the first pass encode (and second later). For every new test you have to manually kill "mencoder.exe" in task manager. I remember reverting to .NET 1.1 a few weeks ago didn't solve some similar problems, but I managed to encode a full movie by letting mencoder.exe works in the background (MeGUI used to exit right away)

When crashing:
Error signature:
AppName: megui.exe AppVer: 1.0.1842.30101 ModName: kernel32.dll
ModVer: 5.1.2600.2180 Offset: 0001eb33

[JoeBG]

Originally posted by Doom9
What exactly does "does not work" mean? The behaviour you described (encoding doesn't start until you close MeGUI) or something else?

Yes Sir, that´s the problem. Encoding does not start until clos of MeGUI


Originally posted by Doom9
And another thing.. is this problem codec related? Can you try with the lavc mpeg-4 codec (the fastest of the 3)? I guess you can see where I'm getting at.. finding the least timeconsuming way to reproduce. [/B]

But you only need to take a film and look if it starts for you?
I have to test lavc a little bit. When I try to start it without changing something in GUI nothing happens, just a termination of the programm.

[Doom9]

@hpn: I'm still a bit concerned about your .NET 2.0 but thanks for testing. Let's hope mencoder acts the same way on my box.. 5000 frames is something I can work with for tests (I did my testing with 1000 frames).

[JoeBG]

@hpn

That´s a better testing than my one. Hope it helps doom9 to find the mistake

[hpn]

Originally posted by Doom9
@hpn: I'm still a bit concerned about your .NET 2.0 but thanks for testing.
I downgraded to .NET 1.1 and tried again with the same test setup. This time MeGUI for all tests with 5001 or more frames doesn't crash with an error message, but the status window simply freezes at 50 frames and mencoder.exe stops working at the background. I press "abort", then close MeGUI and mencoder.exe resumes at 100%. Short clips work fine again. A small correction to the previous post: It's actually 5001, not 5000 as I overlooked the fact that frame number starts from "0", so trim(0,5000) in the avs file actually feeds 5001 frames to mencoder, not 5000.

So in brief: - asv with trim(0,1), trim(0,2), trim(0,3) ... trim(0,4998), trim(0,4999) works fine, and mysteriously stops working for trim(0,5000), trim(0,5001), trim(0,5002) ...

[JoeBG]

Originally posted by hpn
I ... but the status window simply freezes at 50 frames and mencoder.exe stops working at the background. I press "abort", then close MeGUI and mencoder.exe resumes at 100%. Short clips work fine again.

That´s exactly my experience. Freezing after 50 frames...

[Doom9]

Freezing after 50 frames...Alright, that's the point where I make the first GUI update. That gives me a pretty good idea of what I'm looking for. As I'm quite busy these days, perhaps if you could post a progress line (mencoder writes a line that indicates its progress... like fps, the number of frames encoded) from a clip that works and one that doesn't (I take it you can take any version of mencoder and as long as it's a short clip it'll work, correct) that'd be great.

[tiki4]

Just wanted to confirm that the problem really is triggered by the 5000 frames limit.

Trim(0,4999) -> works

Trim(0,5000) -> works not

Cheers,

tiki4

[hpn]

I also tried some ASP encodes (instead of AVC), using both CBR or 2-pass, also made some random changes to the other options (turbo enabled, different buffer size, quantizers, rate control), hoping the freezing would be gone, but the problem persisted (I'm still on .NET 1.1).

As for the "freezing after 50 frames" It's what the MeGUI reports, but only because it's updated every 50 frames. When I open the "mencoder-2pass.log" after the freezing I can see it has actually freezed in the middle of frame 99 (in:98 - check below) and the file size is 8192 bytes, which is exactly 8k and this also seems suspicious (why not 7893 bytes for example?), so these almost 99 frames is exactly what fits in this 8k file. Then everything hangs up and MeGUI can't keep writing to the log file.

-----------------------------
avs2yuv "G:\t\06_.avs" - | mencoder - -ovc x264 -o NUL: -passlogfile "mencoder-2pass.log" -x264encopts pass=1:qp_constant=26:4x4mv:rc_buffer_size=700

mencoder-2pass.log:

in:0 out:0 type:I q:23.000 itex:200 ptex:0 mv:451 misc:221 imb:1215 pmb:0 smb:0;
in:1 out:1 type:P q:26.000 itex:0 ptex:0 mv:0 misc:104 imb:0 pmb:0 smb:1215;
in:2 out:2 type:P q:26.000 itex:0 ptex:0 mv:0 misc:104 imb:0 pmb:0 smb:1215;
.
.
in:96 out:96 type:P q:26.000 itex:10753 ptex:10201 mv:11648 misc:838 imb:296 pmb:461 smb:458;
in:97 out:97 type:P q:26.000 itex:7564 ptex:9988 mv:9560 misc:896 imb:171 pmb:506 smb:538;
in:98 out:98 type:P q:26.000 it

FREEZED and "it" is the last string written to the file (bytes 1FFE and 1FFF)
--------------------------------------------------------------------------------------------

Now I press "abort" and close MeGUI and mencoder.exe "wakes up" and continues to write to "mencoder-2pass.log" in the background:

in:98 out:98 type:P q:26.000 itex:2684 ptex:7527 mv:7593 misc:1020 imb:137 pmb:492 smb:586;
in:99 out:99 type:P q:26.000 itex:870 ptex:7086 mv:5996 misc:1064 imb:61 pmb:484 smb:670;
in:100 out:100 type:P q:26.000 itex:736 ptex:8038 mv:5952 misc:1106 imb:64 pmb:504 smb:647;
.....etc.

Once again this problem is only present for trim(0,5000) or more. Shorter clips work like charm.

[Doom9]

actually, it's mencoder that writes to the logfile. However, mencoder writes out something to stdout for every frame you encode. So, I figure once it writes out the info from frame 100, my app reads it but then screws up somewhere and the reading threads lock. As stdout is no longer being read, mecoder is effectively halted.

[sherpya]

you may need to set null buffer to stdout/stderr descriptors

[JoeBG]

@ doom9

any enlightenments or progress :)

[Doom9]

any enlightenments or progress Yes there is. I wanted to go to bed but I just had to have a look. First of all thanks to all those who made tests.

I can confirm there is a problem and I know why it only happens with sources longer than 5000 frames: as you might have noticed, I update the GUI every 50 frames. If a source is less or equal to 5000 frames, 50 frames means 1% of the video is encoded. If it's longer, percentage done = 0, and as I use that value to calculate the remaining time and that calculation contains a division by the percentage done, with a clip longer than 5000 frames I get a division by zero. As it's not catched, the program blocks. The batchfile is still running, but since the app is not reading from it, it makes no progress. And for some wicked reason, as the program exits and the pipes are no longer being read, the encoding once again takes off. I guess it would be interesting to figure out why that happens, but that's probably something for somebody who understands a lot more of the underlying Windows basics.

Anyway, bug identified, understood and fixed. Attached is the fixed MeGUI 0.161.

Changelog: fixed a division by zero exception that would prevent MeGUI from completing jobs longer than 5000 frames.

Come to think of it, I need to revise my progress estimator big time.. using an int value for the progress in percent is definitely not accurate enough.

Downloaded 79 times before removal.

[JoeBG]

Works http://www.cheesebuerger.net/images/smilie/froehlich/a040.gif

[Sergejack]

Is there a place with all the up-to-date files needed ?
I want to encode in X264 using AVS scripts with a GUI if possible, and there are too much attachement here and there for me.

[North2Polaris]

Originally posted by Sergejack
Is there a place with all the up-to-date files needed?

Check the readme.txt file in the MeGUI 0.161 zip file.

[Sergejack]

Originally posted by North2Polaris
Check the readme.txt file in the MeGUI 0.161 zip file.

I had done that, but it didn't work for me.
(I have an Athlon XP)

[North2Polaris]

Originally posted by Sergejack
I had done that, but it didn't work for me.
(I have an Athlon XP)

I have an Athlon XP, as well. I just copied the latest version of avs2yuv.exe (http://students.washington.edu/lorenm/src/avisynth/avs2yuv/) and mencoder (http://celticdruid.no-ip.com/xvid/mplayer/) to the same directory as the GUI.

Hmm...

[Sergejack]

Originally posted by North2Polaris
I have an Athlon XP, as well. I just copied the latest version of avs2yuv.exe (http://students.washington.edu/lorenm/src/avisynth/avs2yuv/) and mencoder (http://celticdruid.no-ip.com/xvid/mplayer/) to the same directory as the GUI.

Hmm...

As said in the txt file, but I have an runtime error.

[North2Polaris]

Originally posted by Sergejack
As said in the txt file, but I have an runtime error.

Did you check for avisynth.dll and devil.dll as required by Avs2YUV?

Other mencoder builds can also be found here:

http://oss.netfarm.it/mplayer-win32.php

[Ariakis]

I'm not sure if anyone else has had this problem, but when I aborted an encode, mencoder terminated, but avs2yuv remained running in the background... It's no big deal, just something to investigate.

I'm running WinXP Pro SP2 on an Athlon64 if it matters.

[Doom9]

As said in the txt file, but I have an runtime error.That's just no bugreport I'm afraid. The next readme will contain required info for any support call or it won't be answered. Please, how can anybody know what your mysterious runtime error is without you actually posting the exact error message to begin with?

I'm not sure if anyone else has had this problem, but when I aborted an encode, mencoder terminated, but avs2yuv remained running in the background... It's no big deal, just something to investigate.I'll check. It might not even be my error, but then again, perhaps I don't close all the pipes properly and so avs2yuv doesn't exit because data is still being read from it. Though eventually I'll move away from avs2yuv anyway.

[tiki4]

Hello doom9,

thanks for the interim release. I'll be testing it later on.

tiki4

[Doom9]

btw, does anybody know what xvid's turbo mode triggers internally? seems the xvid turbo flag is also not exposed in mencoder (and now I've just told you what is coming next).

@Ariakis: avs2yuv does indeed stay in the bg and will resume decoding if you exit the app. As this is highly undesirable (weird that when I kill the process I started mencoder is closed, but avs2yuv isn't) I've added some code in the upcoming version that'll look for any running instance of avs2yuv when abort is pressed, and kill the process instantly.

[North2Polaris]

@Doom9

On the first tab under "Output", I am using:

Codec: AVC
File Type: AVI
FourCC: x264

When I use "Queue", the job line lists the Codec as "ASP". When I run the job, I get an AVC file, but shouldn't the codec in the job line be listed as "AVC"?

A small thing, hopefully.

Thanks.

North

[hpn]

Just finished a full movie first pass (150k+ frames) and the new MeGUI 0.161 works fine now. Thanks :)

[Doom9]

@North2Polaris: close MeGUI, find the proper jobX.xml file, open it in notepad, copy and paste the contents and send it in a PM to me please so that I can have a look.

@edit: never mind, there's indeed a bug that'll be fixed in the next release.

[Doom9]

here is version 0.162

what's new:
xvid support
3 pass encoding in lavc mpeg-4 and x264 codec
bugfix: codec name is properly transmitted to queue
bugfix: aborting a job via abort button in the status window does not block any further jobs from being processed
bugfix: aborting a job stops avs2yuv
improvement: accuracy of the size prediction has been improved
improvement: accuracy of the estimated remaining time has been improved
improvement: bug report requirements are now stated at the end of the readme file

downloaded 69 times prior to removal

[JoeBG]

Yust finished a very nice video with 0.161. Thanks for 0.162 - Xvid is great :)

[Doom9]

Here is v0.163

new: automated 2 pass encoding of lavc mpeg-4, x264 and xvid
new: probably many new bugs

make sure you read the readme to understand how automated twopass acts when using the queue.

I'll be moving towards MP4 output now but I'd appreciate if somebody could do some hard testing.. so that they can be fixed before I add a lot more code.

And if it's really used (I expect to see lots of posts from different people), I could also add automated 3 pass encoding.. the basics is now there (it's quite tricky to turn a program meant to encode what's in the GUI and double the work to be done without interfering with all the existing mechanisms)

Oh, and if somebody is interested in refactoring, let me know.. the code is so messed up you could probably spend days giving it a clean structure.

[Doom9]

I'm going to use mp4creator for the forseeable future.

[Doom9]

here's v0.164

new: mp4 output (doesn't work with snow obviously)

how does it work: once encoding of a suitable job is done, the video output (named something.mp4 is renamed to be mp4 compliant (for MPEG-4 ASP that's something.m4v, for AVC that's something.264), then it's put into an MP4 file (that file has the name you specified)). The renaming is done automatically and existing files will be overwritten (just as mencoder overwrites existing files).

The output of mp4creator, plus mp4 statistics will be put at the end of the log. The log will only be shown once muxing has completed, so in case of muxing a full movie, the status will remain at 99% until muxing is complete.

Please keep all the mp4 statistics at the end of the log and if you have a sizeable number of them from reasonable input (preferably full movies, but at least 10'000 frames) send them to me.. it'll help figure out an accurate overhead calculation for automated encoding (that's where MeGUI is going.. give an AC3 file and AVS file, set a size, pick codec and parameters, and everything will be done for you).

So once again, KEEP THOSE MP4 STATISTICS

P.S. Forgot something in the readme: you need the most recent mp4creator: http://www.aziendeassociate.it/cd.asp?dir=/mpeg4iptools

v0.164 was downloaded 64 times prior to removal

[cheburashka]

@Doom9
You swapped "AVC Main" and "AVC Q & RC" tabs in 0.164.
Is that intentional?
I guess not.

And you did not add latest x264 (build 142+) options to configure usage of weighted prediction and adaptive BVOPS.

[Doom9]

You swapped "AVC Main" and "AVC Q & RC" tabs in 0.164.Actually, not I, VS.2003 did that. For some wicked reason, in the GUI designer everything is okay but when I compile and run the app, all the tabs are mixed up. I'll eventually (hopefully this week-end) do a redesign where only the tabs that are active are visible, and in that solution the tab order will be controlled by myself and thus the IDE can no longer interfere.

And you did not add latest x264 (build 142+) options to configure usage of weighted prediction and adaptive BVOPS.Are you talking about the VfW? I'm not using it. But if somebody can tell me how those options are exposed in mencoder, I'll gladly integrate them (it'll require an up-to-date build of mencoder though).

[akupenguin]

Weighted prediction is enabled by weight_b, and adaptive B-frames are enabled by b_adapt.

[Doom9]

Weighted prediction is enabled by <i>weight_b</i>, and adaptive B-frames are enabled by <i>b_adapt</i>.Thanks... btw, html code is not enabled so you have to use bbcode, and bbcode uses [ ] brackets instead of the html brackets.

Oh, are those enabled or disabled by default?

[celtic_druid]

From the looks of ve_x264 they are disabled by default.

[Doom9]

@celtic_druid: by the way, I suppose I'd need a newer build than the 2/22 (the latest one on your mirror). Any chance we could get a 0day build?

And is it just me or are those two just exposed in mencoder (and perhaps the cli x264 encoder) and not the VfW?

[bond]

hm i dont seem to get .mp4 output to work (default avc options), i only get a .mp4 file which actually is raw avc (but not muxed into .mp4)
i placed the latest mp4creator in the mencoder folder
i dunno but maybe this damn winme is causing this as it cant pipe streams via dos it seems (always has to decode to raw first and than feed the raw to mencoder), makes avs2yuv pretty unuseable practically :(

i noticed that when choosing level0 for subpixel refinement mencoder crashes (only seems to allow values > 1)

another thing: it might make sense to change the codec naming a little bit: i think instead of asp, avc, xvid and snow the following might be better:
- asp (xvid)
- asp (libav)
- avc (x264)
- snow
cause xvid is of course also asp and your gui offers two asp codecs for encoding, so it might also show this in the options :)

[celtic_druid]

I put new builds up. x264 r144 and current XviD cvs head. Athlon64, XP, tbitd, pentium4 and 3. I assume you know where to find them before they get mirrored?

[Sharktooth]

Since the automatic backup script doesnt work as expected (too much timeouts generated corrupted copies and sometimes it "jumped" some files cause of the incomplete directory listing...) i'm mirroring the files by hand... so it may take a while (CD's site is quite slow too) before i update everything.

[Doom9]

I assume you know where to find them before they get mirrored?Actually, no, so if you could show me the way..

hm i dont seem to get .mp4 output to work (default avc options), i only get a .mp4 file which actually is raw avc (but not muxed into .mp4)
i placed the latest mp4creator in the mencoder folder
i dunno but maybe this damn winme is causing this as it cant pipe streams via dos it seems (always has to decode to raw first and than feed the raw to mencoder), makes avs2yuv pretty unuseable practicallyThe log should tell you something.. I catch the mp4creator stdout (but perhaps it too sends errors to stderr) and put it in the log. And because of mp4creators stupidity when it comes to input filetypes (I wouldn't mind indicating my input type as an additional flag, but using the extension, that's just weird beyond reason), I use the final output name as mencoder raw output, then rename (though.. you seem to have a problem with the renaming already because that is done prior to mp4creator starting). Either way, considering your avs2yuv problem I strongly suggest you upgrade to a reasonable OS ;) Even with your CPU, there's no reason to stick to a crappy pseudo 32 bit OS (and W2K ran just fine on my 450 Mhz P2 back in the day).

- asp (xvid)
- asp (libav)
- avc (x264)
- snowOnce I restructure the GUI (only show tabs in function of the selected codec), that'll happen..right I don't have enough space as it is (scrolling tabs is a nightmare). I really wished that libavcodec codec would have a more reasonable name.. it simply has no reasonable designation.

[bond]

Originally posted by Doom9
The log should tell you something.. I catch the mp4creator stdout (but perhaps it too sends errors to stderr) and put it in the log.there is no log created :(

And because of mp4creators stupidity when it comes to input filetypes (I wouldn't mind indicating my input type as an additional flag, but using the extension, that's just weird beyond reason)hm i find this a normal behaviour, its like why should you have to use a "-avi" flag for signalling .avi input if you can simply analyse the extension :D

Either way, considering your avs2yuv problem I strongly suggest you upgrade to a reasonable OSyeah, i know its crap, but till now all major problems could be solved somehow (eg piping via cygwin works, or simply direct .avs input in mencoder) and i am simply too lazy to resetup :D

[Doom9]

there is no log createdThen how can you encode using my GUI? After encoding completes, the status window will close and a log window will come up with everything that mencoder wrote to stdout and stderr, plus additional stdout info from mp4creator and some of my own stuff (mp4 overhead info for one).
If mp4creator isn't there, the GUI will already balk.

hm i find this a normal behaviour, its like why should you have to use a "-avi" flag for signalling .avi input if you can simply analyse the extension AVI can contain MPEG-4 ASP, AVC and a lot of other stuff, so you'd still have to do some input analysis for this to work ;)

[bond]

Originally posted by Doom9
Then how can you encode using my GUI? After encoding completes, the status window will close and a log window will come up with everything that mencoder wrote to stdout and stderr, plus additional stdout info from mp4creator and some of my own stuff (mp4 overhead info for one).the status window doesnt close :(

[Doom9]

the status window doesnt closeDidn't that always happen for you? I thought you never actually got a single job that finished (they do mencoder wise but MeGUI never finishes). I'm afraid considering that you're the only one with an oudated OS and at the same time the only one with problem, and further considering all the hoops programmers have to jump through to sometimes get modern software to work on outdated operating systems, I can only assume. Don't you have any computer with a reasonable OS accessible to you? And why not upgrade? It's like dragging a 100kg stone after your car.

I really wish I could help, if it were a problem on W2K I'd consider a W2K installation of VMWare and get the debugger running, but I won't touch WinME.

[North2Polaris]

Originally posted by Doom9
Please keep all the mp4 statistics at the end of the log and if you have a sizeable number of them from reasonable input (preferably full movies, but at least 10'000 frames) send them to me..

@Doom9,

I just did a successful 2-pass run of about 10,000 frames. I saved the 2 logfiles in a text file. Are you still interested in getting these?

North

[Doom9]

I saved the 2 logfiles in a text file. Are you still interested in getting these?
Just the end part starting with the filesizes. But, the more you have, and the longer the movie the happier I'll be ;) Of course, that is assuming your output is MP4.. otherwise I'm not interested.

[North2Polaris]

Like this?

MP4 muxing info:
Size of raw input file: 38321919 bytes
Size of video in mp4 file: 38406041 bytes
Total overhead: 84122 bytes
Overhead per frame: 8.01619973318087bytes

source information
codec: AVC
number of b-frames: 0

Will the logfile from a one pass encode give you the information you need?

[Doom9]

Here's version 0.165

new: supports weighted prediction for b-frames
new: supports adaptive b-frames

both those features require an up-to-date mencoder build. I suggest one dated 2/25 or newer. Since those features require an up-to-date mencoder build I think the next version will make use of mencoder's avs input capabilities.

v0.165 downloaded 56 times prior to removal

[Doom9]

Like this?Yup, just the way I like it :)

Will the logfile from a one pass encode give you the information you need?No.

I guess in the future I'll read out the mencoder end output and compare it to the set bitrate so that whenever I have the bitrate calcuations down and somebody complains about over or undersize I can point my fingers to the codec :devil:

Also attached are the latest sources. The next features will probably require a big rewrite, so I figured a source release was in order in case any quick fixes are needed on the current codebase.

[hellfred]

@Bond
You can try to use another "Dosbox". When i was still using manly Win98 i found cmd.exe from ReactOS very usefull, giving me e.g. tab-completion. And there were some builds/backports of MS cmd.exe to Win9x on the net, too. But those failed to switch the partition, just worked on one (e.g. only on c:\)

Hellfred

[celtic_druid]

I made a version that doesn't require avs2yuv if someone wants to test?

@edit by admin: removed link since it's now outdated.

Did some tests including mp4 output and it worked ok here.

Changes.
No avs2yuv required.
Wider gui.
Updated readme (-avs2yuv, +mp4creator).

Everything else is the same.

[JoeBG]

@ celtic_druid

Very nice GUI and it works perfect :)

[Doom9]

Here's version 0.166:

new: preliminary audio support. commandlines are already written and persistent profiles can be created, but audio encoding is currently not possible
new: GUI adapts to the chosen input (audio: mp4/aac audio is for muxing only, selecting other audio input enables the audio configuration. video: only the codec configuration page of the currently selected codec is being shown) => no more tab scrolling
new: advanced codec settings (RC and Quantizer) are hidden by default and can be enabled via checkbox. This should make the GUI less cluttered

changed: video profiles are now written and read from <path of megui>/profiles/video so make sure you copy all your profiles there
changed: adjusted column widths in the queue
changed: many internal improvements reflecting the fact that video and audio encoding will eventually be supported (hopefully in the next version)
changed: avs2yuv is no longer needed

Oh and then there's a todo I forgot to put into the readme: eliminate need for job.bat now that I'm using mencoder without avs2yuv.

v0.166 downloaded 49 times prior to removal

[JoeBG]

@ Celtic_druid

I have blue faces with your build. I tried it with the mencoder from netfarm because I could not find your updatet mencoder. I tried this mencoder here:
http://oss.netfarm.it/mplayer-win32.php

@ doom9

Did you test version 0.166 with a mencoder from celtic_druid? Or do have to create a special avisynth skript?

[celtic_druid]

This has already been discussed. Basically older versions of dgdecode output by default to 1420 which the avs mencoder patch thinks is YV12 so you have blue faces instead of pink.

Solution is to update dgdecode.

This is also I noticed covered in the new readme.

[JoeBG]

Originally posted by celtic_druid
This has already been discussed. Basically older versions of dgdecode output by default to 1420 which the avs mencoder patch thinks is YV12 so you have blue faces instead of pink.

Solution is to update dgdecode.

This is also I noticed covered in the new readme.

Ok, sorry for this :)

[Doom9]

urgh, sorry guys, avs2yuv.exe is still required in v0.166(not for encoding, but the check for the application's existence will fail and encoding won't start).

Here's v0.1661 that no longer checks for avs2yuv and also doesn't need job.bat anymore either.

version 0.1661 was downloaded 161 times prior to removal

[azsd]

thx,

nice tools,I ve using it now

little suggest,could you please change the form's font to Tahoma,8(.25)pt (mostly app use)
change the formborderstyle to FixedDialog,and the Maxmizebox to False?
it's do not functional more but sould look better.
default fonts(if you haven't change the default value,the value will not store in C# apps) will specialed by framework runtiming,so i get some control's text be clipped in my OS.

[Doom9]

@azsd: all those things will be taken care of in the new version.

[Doom9]

@bond: regarding the codec names: perhaps you have noticed there's a tooltip on the codec label. I've added another one to the codec selection dropdown now which gives an explanation on the codec types. I hope that makes it clear enough.

[dinolib]

Hi,
I'm tring megui 166.1. I like it! Thank you Doom9.

I would post strange behaviours (may be bugs, may be my incompetence)

My PC: P4M, winXP SP1, .net RTM 1.1.4322.573, mencoder 20050225, avisynth 2.5.5
Input: DX50 720x416 - 2742 frames

1) Macroblock Option 4x4mv doesn't recognized by mencoder 20050225: "Option x264encopts: Unknown suboption weight_b4x4mv" (is it not released in mencoder yet?)
2) mp4 encoding doesn't signal errors: the previous error appear only with AVI. In mp4 encoding I have nothing (encoding hang up, no CPU activity).
3) When a queue elaboration finish, I can't start another one (if then I try direct encode, MeGUI tell me "cannot have two open encoding sessions at once" and on exiting from the program, I get a run-time error)
4) using queue mode for mp4 files (ASP profile) encoding stop at 99% before mp4 muxing (m4v file is created, not the mp4).
5) AVC codec, adaptive flag: disabled by default with B-frames set to 2 (incompatible, I think)

I hope this will help you to make MeGUI even better!:D
Dino

[Doom9]

1) Macroblock Option 4x4mv doesn't recognized by mencoder 20050225: "Option x264encopts: Unknown suboption weight_b4x4mv" (is it not released in mencoder yet?)That's a bug on my side, weight_b is one parameter, b4x4mv another.. they should be separated by a ":", otherwise mencoder won't recognize them.

5) AVC codec, adaptive flag: disabled by default with B-frames set to 2 (incompatible, I think)Hmm.. I guess I must've switched it the wrong way around.. obviously it should only be available when b-frames are enabled.

I'll check the other stuff, too, as soon as I can get my dev build running again (I rewrote more than half of the non GUI code yesterday, things are much more flexible internally now and will make automated audio & video encoding and MP4 muxing possible). In the new version, MP4 muxing will be a separate job (in the previous builds, MP4 muxing was part of video encoding.. hence you can't get past 99% if the muxing fails for some reason). Having the muxing separate also has the advantage that if only muxing fails, you can restart that particular job without having to redo video (and audio).

[hitbit]

I know that you guys prefer to rip via avisynth, but since mencoder support reading and decrypting DVDs "on the fly", why don't include this option in MeGUI?

[Doom9]

3) When a queue elaboration finish, I can't start another one (if then I try direct encode, MeGUI tell me "cannot have two open encoding sessions at once" and on exiting from the program, I get a run-time error)I think that this is connected to your mp4 muxing failure. I've completely rewritten the muxer, and I hope things will work better now (when it's out.. I'm still stuck with processing besweet stdout messages (see my post in the development forum if you think you can help), and haven't even tested MP4 muxing yet. But, if you get no message back from the encoding (and thus MP4) muxing, it makes sense that you cannot start another job - as far as megui is concerned, you're still encoding.

5) AVC codec, adaptive flag: disabled by default with B-frames set to 2 (incompatible, I think)There was indeed something wrong with that.. it's fixed now.

I know that you guys prefer to rip via avisynth, but since mencoder support reading and decrypting DVDs "on the fly", why don't include this option in MeGUI?Because AviSynth I have no use for mencoder's input capabilities other than AVS. I don't think I've come across a post from anybody using mencoder for direct DVD input, and quite frankly I have no clue as how to deal with it.. there's so many things (resize, crop, deinterlace/ivtc, what to do with audio) where I have no experience whatsoever, but know a lot of imho way better tools to get the job done that I think it's futile to implement such features. Plus, even with the redesign, it would be quite a stretch to add that much functionality.

But hey, it's open source so if you think that's something you want to do, be my guest.

[JoeBG]

@ doom9

A big advantage of MeGUI is to have full avisynth power. I don´t want to miss this.

Would it be possibble to add other extensions to raw-output than "raw"? Maybe m4v or h264 would be enough. So noone needs to rename the files when adding them to mp4muxer - would make things easier :)

You plan to convert AC3 to aac with BeSweet? Does this work automatically or do I have the possibility to define own commandlines and save them as aac profiles? (But this really is no need, yust a nice to have when you use robot4rip or directly BeSweet):)

Testet a whole film with ASP my first time. I used it with file extension m4v. Worked great. I make my own mp4 calculation and reached the target size very good.

[Doom9]

Would it be possibble to add other extensions to raw-output than "raw"?Sure, that wouldn't be a problem at all.

You plan to convert AC3 to aac with BeSweet? Does this work automatically or do I have the possibility to define own commandlines and save them as aac profiles?It's already done.. but I just seem to be too stupid to catch the besweet stdout output properly (I want to have a nice progress bar like for the video, at least for besweet's 2nd pass). And you can configure pretty much what you need (basically the Nero AAC encoding config as far as it makes sense for the scenario). Custom commandlines are foreseen but won't be in the next version.

[celtic_druid]

How about:

else if (fileType.SelectedIndex == 1)
{ // RAW output
if (this.codec.SelectedIndex == 1)
this.outputSaveFileDialog.Filter = "RAW Files|*.264"; // x264
else if (this.codec.SelectedIndex == 2)
this.outputSaveFileDialog.Filter = "RAW Files|*.raw"; // SNOW
else
this.outputSaveFileDialog.Filter = "RAW Files|*.m4v"; // XviD & libavc MPEG4
}

[Doom9]

@celtic_druid: that about oughta do it ;)

BTW, if you mind having a look at the code in the developer forum.. some of the GUI updates (selecting a profile, selecting certain input files) seems to have a weird effect on the GUI (the contents in the dropdowns is suddenly selected for instance, and there's a weird thing going on when changing the output type from mp4/raw back to AVI (setting fourcc.SelectedIndex seems to have no effect, I have to first select another index than 0).

[celtic_druid]

As I said earlier I would recommend changing the drop down style to DropDownList.

That said I just compiled the source from thw dev forum and it works fine although I still think dropdownlist looks nicer.

How about this? A little something so that if the user decides to select the output file (gives *.avi) and then decides they want mp4. With this the filename automatically becomes *.mp4. Otherwise you end up saving an mp4 with the extension avi.

if (fileType.SelectedIndex == 0) // AVI
{
this.fourcc.Enabled = true;
// this.fourcc.SelectedIndex = 0;
if (this.outputFile.Text.Length > 2)
{
this.outputFile.Text = this.outputFile.Text.Substring(0, this.outputFile.Text.Length - 3);
this.outputFile.Text += "avi";
}
}
else if (fileType.SelectedIndex == 1) // RAW
{
if (this.outputFile.Text.Length > 2)
{
this.outputFile.Text = this.outputFile.Text.Substring(0, this.outputFile.Text.Length - 3);
if (this.codec.SelectedIndex == 0)
this.outputFile.Text += "m4v";
else if (this.codec.SelectedIndex == 1)
this.outputFile.Text += "264";
else if (this.codec.SelectedIndex == 2)
this.outputFile.Text += "raw";
else
this.outputFile.Text += "m4v";
}

this.fourcc.Enabled = false;
this.fourcc.Text = "";
}
else
{
if (this.outputFile.Text.Length > 2)
{
this.outputFile.Text = this.outputFile.Text.Substring(0, this.outputFile.Text.Length - 3);
this.outputFile.Text += "mp4";
}


more code needed so that if the user selects RAW then changes from say XviD to x264 they don't end up with *.m4v.

Err guess using this.outputFile.Text.LastIndexOf(".") + 1 would be better incase someone enters their own file extension which isn't 3 chars.

[Doom9]

actually I meant to place similar code in the video encoder and override the output filename there.. so basically the user can set whatever he/she wants, in the end if we're going for raw or mp4 the mencoder output will be .264 or .m4v.. but that kinda conflicts with custom commandlines where no checking is done. damn

can you try this: start program, select MP4, then AVI from the dropdown. I now have the Codec dropdown selected (the "ASP" string is surrounded by blue, as if the user had selected it with the mouse), same for the Video Profile and Audio Profile (I have profiles definied that are loaded upon startup).
If I change the codec, the File Type, Video and Audio profile are colored blue.

It also applies to the dropdowns in the video tab (regardless of the codec). I can't have changed much since 0.1661 (just bugfixes). And if you change line 4939 in Form1.cs to this.fourcc.SelectedIndex = 0;, compile and start again, select MP4 output, then AVI again.. note that the FourCC field is now empty.