full fledged x264.exe GUI

[Sharktooth]

lite version fixed (damn CAPS!!!)...
The lite version is a non istaller version :) it contains the EXE and the DLL only.
The uninstall link is safe, unless the user is blind and click the UNINSTALL button a second time... :D

[bob0r]

I think i have found some bug, it could be a visual bug only:

When i open megui-x264.exe in dir only with x264.exe (so first time), also 2nd and 3rd..... etc time.

When you go to config > Show commandline, it shows:
"x264.exe" --bitrate 700 --analyse p8x8,b8x8,i4x4 --progress --no-psnr --output "" ""

When you select Baseline Profile it shows:
"x264.exe" --bitrate 700 --no-cabac --analyse p8x8,b8x8,i4x4 --progress --no-psnr --output "" ""

When you go back to Main Profile it still shows:
"x264.exe" --bitrate 700 --no-cabac --analyse p8x8,b8x8,i4x4 --progress --no-psnr --output "" ""

When you go to High profile, it remains:
"x264.exe" --bitrate 700 --no-cabac --analyse p8x8,b8x8,i4x4 --progress --no-psnr --output "" ""

So the --no-cabac stays there, is this only a visual bug, or will this affect your encode?


Also, when you go to High Profile directly, Show commandline does not change...

[Doom9]

well, by default CABAC is turned on.. then if you select the baseline profile, it is turned off (unchecked). Main profile doesn't require CABAC, and neither does high profile require lossless, or 8x8dct / i8x8 MBs.. hence if you up the profile, more GUI options become available but they are not automatically selected, and thus the commandline stays the same. If you select a lesser profile, the commandline can change because certain options have to be disabled as they are not compatible with the selected profile.

[bob0r]

I understand, and you are correct.

Its just rather confusing, that you have to recheck all options that were enabled by default.

But i guess when you start megui-x264, you have to right away save your own profile!

[Doom9]

Its just rather confusing, that you have to recheck all options that were enabled by default.Imagine coding a multi level history for that, that would be beyond reasonable. Incidentally, no program I know of, offers anything similar, and with profiles, there's really no need for it.

[akupenguin]

One solution that doesn't need a history: The profile selction could by applied during commandline generation instead of modifying the options selected.

[Doom9]

One solution that doesn't need a history: The profile selction could by applied during commandline generation instead of modifying the options selected.and then people would ask me "why is the commandline not showing this option even though it's selected in the GUI?" ;)

new release is out, enjoy.

[bob0r]

Ok, if thats the problem i agree with you.

We still love it! 0.2.2.5 added to x264.nl installer.

:thanks:

[stephanV]

and then people would ask me "why is the commandline not showing this option even though it's selected in the GUI?" ;)
A greyed out option is generally assumed not to be used. This is how it's done in virtually every other program or GUI. (e.g. x264 VFW)

It's you choice of course.

[Doom9]

the CodecSettings property is painfully oblivious to greyed out ;) Lowering the profile, then increasing it again is rather pointless to begin with.. those who know what they're doing will not have the slightest problem with this behavior. And those that don't fit this criteria can always learn.. at times this is to be prefered over the dumb solution <evil grin of an arrogant developer>

[Selur]

would be nice if you could support mp4(aac) as audio input and mux it with the created mp4(x264) file :)

[berrinam]

For non-x264 features, use MeGUI full version.

[bob0r]

would be nice if you could support mp4(aac) as audio input and mux it with the created mp4(x264) file :)

For now its best to use MeGUI-FULL anyway, as .mp4 output of x264 is not quite there yet.
( http://forum.doom9.org/showthread.php?t=99909 )

I just use MeGUI-x264 for raw output (.264) and just mux the video with the latest MP4BOX.

Simply mux:
MP4Box -add video.264 x264.mp4
MP4Box -sbr -add audio.aac x264.mp4 (-sbr only for HE-AAC/AAC+/AAC+SBR(+PS))

... assuming MeGUI-FULL muxes the .264 video file with mp4box.

[Doom9]

as .mp4 output of x264 is not quite there yet.well, shit in shit out. Clearly something is wrong with AVIs that have those outrageous dwScale and dwRate values.. it's probably another Microsoft "feature", but it's not like a file having the proper values would cause any problems.

[stephanV]

Nothing is wrong with those AVIs, it is nowhere defined dwRate and dwScale are not allowed to have those values. A video file should be allowed to have any arbitrary framerate, not just 23976/1000, 25/1 and 2997/100. Note that the mp4 output of x264cli is so far the only thing that exhibits those problems. It would be more logical to seek the problem there. (for MKV it is fixed already)

[bob0r]

Is there a way to add http://x264.nl/x264.ico to the megui.exe shortcut in Start/Programs/x264 just like VFW configuration?
( rundll32.exe x264vfw.dll,Configure x264.ico but then for megui-x264.exe)

The reason i ask here is, if its not possible, is there a way to alter megui-x264.exe with some tool to change the icon, if thats a yes, is it allowed by doom9 to alter your file?

[Sharktooth]

Yes, it can be done the in same way as for x264 VFW configuration icon.

[Doom9]

you can assign any icon to a shortcut you want. If you want to design a nice MeGUI icon, you're of course also welcome ;)

[bob0r]

you can assign any icon to a shortcut you want. If you want to design a nice MeGUI icon, you're of course also welcome ;)

Well you can use our sweet x264.ico for megui-x264 :)
As for megui-full, i would not dare to design an icon for it :scared:

:script: (i just like the smilie of this one)

[bob0r]

Yes, it can be done the in same way as for x264 VFW configuration icon.

CreateShortcut "$SMPROGRAMS\x264\x264 command line interface encoder.lnk" $INSTDIR\megui-x264.exe $SYSDIR\x264.ico possible?

Please explain to me how its done.

Windows wont update my icons in the start menu
CreateShortcut "$SMPROGRAMS\x264\uninstall x264.lnk" $INSTDIR\x264-uninstall.exe still shows the original NSIS icon, while C:\Program Files\x264\x264-uninstall.exe uses the new icon.

Any way to reset how windows reads the icons?

[Sharktooth]

1 - RTFM :
4.9.3.4 CreateShortCut

link.lnk target.file [parameters [icon.file [icon_index_number [start_options [keyboard_shortcut [description]]]]]]

Creates a shortcut 'link.lnk' that links to 'target.file', with optional parameters 'parameters'. The icon used for the shortcut is 'icon.file,icon_index_number'; for default icon settings use empty strings for both icon.file and icon_index_number. start_options should be one of: SW_SHOWNORMAL, SW_SHOWMAXIMIZED, SW_SHOWMINIMIZED, or an empty string. keyboard_shortcut should be in the form of 'flag|c' where flag can be a combination (using |) of: ALT, CONTROL, EXT, or SHIFT. c is the character to use (a-z, A-Z, 0-9, F1-F24, etc). Note that no spaces are allowed in this string. A good example is "ALT|CONTROL|F8". $OUTDIR is used for the working directory. You can change it by using SetOutPath before creating the Shortcut. description should be the description of the shortcut, or comment as it is called under XP. The error flag is set if the shortcut cannot be created (i.e. either of the paths (link or target) does not exist, or some other error).
2 - to reset the icons completely uninstall the previous version (remove the uninstall and the icon if they're still there), reboot and reinstall the new version. If the icon is still not refreshed, start in fail safe mode with command prompt and delete the windows icon cache file.

[bob0r]

1: i tried
CreateShortcut "$SMPROGRAMS\x264\x264 command line interface encoder.lnk" $INSTDIR\megui-x264.exe x264.ico
and
CreateShortcut "$SMPROGRAMS\x264\x264 command line interface encoder.lnk" $INSTDIR\megui-x264.exe $SYSDIR\x264.ico

i did read RTFM, i even tried search with google, but without samples i am completely clueless here. Too bad i am not as smart as i look :cool:

2: ok seems a reboot is needed (sjees i hate that)

Edit:
Ok i got it fixed now, from the same FM:

CreateDirectory "$SMPROGRAMS\My Company"
CreateShortCut "$SMPROGRAMS\My Company\My Program.lnk" "$INSTDIR\My Program.exe" \
"some command line parameters" "$INSTDIR\My Program.exe" 2 SW_SHOWNORMAL \
ALT|CTRL|SHIFT|F5 "a description"

When you add rundll32.exe, x264vfw.dll,Configure is the "some command line parameters", so for megui-x264.exe, i had to add "" ( $INSTDIR\megui-x264.exe "" $INSTDIR\x264.ico ) Bleh, no wonder i didn't get it!

Anyways enough OFF Topic, doom9 feel free to remove all useless posts in this thread.

[Doom9]

new build is up. enjoy!!

[bob0r]

new build is up. enjoy!!

Attachments Pending Approval
MeGUI-x264.0.2.2.6.zip

:D

[bob0r]

@Sharktooth
(r327B) Updated MeGUI-x264 to version 0.2.2.6a (support for Adaptive Quantization and Mixed Refs).

Where can this be found?
Or was it a private build, just to test your builds and patches, because AQ was not submitted to SVN yet?

[kurt]

http://forum.doom9.org/showthread.php?t=89979
-.-> the "x264 Full package" contains r327B, isn't it?

[Sharktooth]

it's in the megui development thread, and yes, it's for testing.
Bugfixes:
-The OneClickWindow doesn't crash when trying to use 'Don't Encode Audio'
-DGIndex doesn't crash when aborting jobs
-MeGUI won't let you try to open the Process Window when running DGIndex, which would lead to a crash.
-root directory bug discussed with haubrija in main MeGUI thread

Cosmetics:
-MeGUI will give a message if there are jobs queued, but not waiting (eg done or postponed, etc)
-Better managing of 'Don't Encode Audio' with the container format dropdown

New features:
-load simple DGIndex jobs
-add '--mixed-refs' option for x264
-add AQ options for x264

[mezzanine]

Can i have a link to the latest source code?

thanx

[Sharktooth]

It's in the MeGUI Development thread.

[Doom9]

a new release is out. enjoy

[Doom9]

a new build is up. This marks the first x264 gui to support the new --crf switch.

[Sharktooth]

doom9, look at the MeGUI main thread plz.

[Doom9]

done.. hope the a build works for your distro.

[bob0r]

It could be wise to make a Megui-x264-SVN and a Megui-x264-Sharktooth build, as for example SVN revison 334 does not support AQ and --subme 7 yet.

[Doom9]

well.. autoaq is off by default and I suppose many people won't even bother looking for it.
I have enough revisions to take care of as it is and another one is simply out of the question. Whoever uses options that their build doesn't support only has himself to blame.. it's like using a unicode build on w98. And the software requirements do point to Sharktooth's custom builds ;)

P.S. Just so that you don't get the wrong impression, I know where you're coming from, but the effort to add another conditional compilation switch compared to the use (these patches are going to be committed in the forseeable future and thus I would have to remove that switch again), just telling people or having them fail (if you use an unsupported option x264 will tell you so you'll only commit that error once) is imho preferable in this case.

[Sharktooth]

for the next builds, i will separate SVN builds from the Experimental builds so MeGUI x264 will have no problems with x264 builds other than mine.
im just waiting AQ gets committed.

[Doom9]

well.. it's not so much a problem, rather you just can't use every switch. It is not completely unlike x264 with mencoder.. you can configure everything but half the things don't make it into the commandline because mencoder doesn't support them.

[Doom9]

a new build is up. As usual you can find the changelog in the main megui thread.

[Doom9]

a new build is out
The changelog of the full MeGUI fully applies to the x264 edition as well this time.

[Sharktooth]

updated x264-Full with 0.2.3.0.
updated custom profiles for version 0.2.3.0.

[Doom9]

A new build is out. Enjoy avc levels and support for b-frame RDO.

Now I can say it's your turn to update ;)

[Doom9]

@bob0r: since you're also shipping MeGUI with your compiles perhaps we can reach a compromise regarding the non SVC patches. Would it be enough if the options that cannot be used in your build simply were to not be in the GUI? If people were to edit the XML file manually, they could still make use of them, and if they load a profile with them activated, they'd be in the commandline. Plus, a profile with subme7 would just lead to a crash. But hiding the options in question would not be much of a burden (as compared to properly hide everything - even in the config files). You'd just need to make your own compiles with my compile script and warn people that not all of Sharktooth's profiles will work with your build.

[bob0r]

@doom9

I still think we, you/me, should focus on the SVN.

Builds for sharktooth can be called beta (also be tested like beta).
Once a patch is updated to the x264 SVN, you could also update megui-x264 to match the SVN options. (With update i mean release a "stable matching x264 svn release")

Or indeed add something like: Enable none-SVN options, for sharktooth or other custom builds.

I dont know how hard it is to generally disable an option for all profiles/settings, until "Enable none-SVN options" is selected, but that would be the best way.


Extra motivation :D:
If i would "demand" a megui-x264 version for my custom builds, then ofcourse you should not change your ways. But i am just working of SVN, thats my standard, everything i do i try to do as basic and generally as possible (Meaning reach the most CPUs with encoding and decoding files)

I think sharktooth's builds are very important and i think megui-x264 should match his updates.
For x264 SVN megui-x264 files, i think my visitors can wait a few days/week before they can test new options. (by then possible more documentation is made anyway)

[Sharktooth]

my builds are easy to identify... the CLI stdout contains:
x264 core:40 svn-362M (built by Sharktooth)in the first line.
An easy check for "Sharktooth" will identify if it's my build or not.

[Doom9]

well x264 is alpha anyway. I won't stop adding support for non supported patches.. MeGUI is basically the only option people have for these patches unless they use the commandline. What you suggest with another checkbox is actually even more work than both ways I've outlined above.
What I suggested above is two lines so it's virtually no effort. But I don't have time to reorganize the GUI and update 4 different files every time a patch gets commited. Furthermore, as it stands now, unless somebody uses subme 7, profiles would be fully compatible which isn't the case if I start modding the settings class for different compiler flags.

[bob0r]

Well then, what ever you find best, its fine with me :)

[DryFire]

With MeGui 2.3.1, the Quene tab remains teh same size as teh jobs tab and does not show the start, stop, pause buttons etc...

It also does not allow me to resize the window.

[Doom9]

damn you visual studio.. stupid GUI designer got rid of the event that should trigger the resize. One thing's for sure: Visual studio's GUI designer is not made for having multiple GUI looks depending on compilation option and has huge trouble coping with that scenario.

[Doom9]

alright, I have uploaded the source code supporting the SVN options only and updated the compile script as well. syntax: compile x264-svn.. you have to compile it on your own though. The a build attached here supports all the patches as usual and fixes the GUI resizing issue.

[bob0r]

Attachments Pending Approval

(just delete this message when done)