View Full Version : bridging the command line and GUI approach using x264
stax76
27th September 2009, 17:23
Usually people decide to rather to use CLI or GUI. Both as has pros & cons. Recently I've added some features to StaxRip building a bridge for CLI users to enable them to take advantage of their CLI experience and minimize the requirement to learn how to use the GUI. These features are:
Changing a GUI setting instantly displays the updated command line
The GUI setting that was changed most recently is displayed bold
A Search feature where a switch (or part of) can be entered to quickly find the GUI control for this switch. There are so many features making it hard sometimes to find the setting especially when the GUI don't support the setting
A Go To features with same purpose as the Search feature which lists switches supported by the GUI in a drop down list
The possibility to import the x264 settings from a x264 command line in the clipboard. I've needed a afternoon to build a x264 command line parser but it's quite useful
Allowing to define additional command line parameters
https://sourceforge.net/dbimage.php?id=233700
Latest build: http://www.stax76.bplaced.net/files/applications/StaxRip/StaxRip_1.1.1.7_beta.7z
RunningSkittle
27th September 2009, 18:22
awesome!!!
It looks like staxrip has come a long way in the last year or so since i used it last :)
Inspector.Gadget
27th September 2009, 18:24
This looks like a great idea. Will you add tooltips or explanations to (for example) the "Preset" and "Tune" fields as a quick reference?
stax76
27th September 2009, 18:54
It looks like staxrip has come a long way in the last year or so since i used it last
This year was certainly better than last, especially for Vista/Win 7 as I've finally dumped XP and switched to Win 7 and added new OS features like task dialogs instead of message boxes and some other new OS features.
Will you add tooltips or explanations to (for example) the "Preset" and "Tune" fields as a quick reference?
I've added tooltips using --fullhelp as source, maybe I can use other sources as well, do you know where I can find up to date information for "Preset" and "Tune"? I have to take care of the length of the tooltips, I think they shouldn't be too long.
juGGaKNot
27th September 2009, 19:15
What about selecting a directory ( loading all files in subfolders also automated, not like now ) then setting the codec ( for all files ) and "cloning" to a new directory that has the same syntax ( same folders, same files just the new settings )
or just adding the new encode with a "reencoded" prefix ?
what i want is the ability to load all files in the subfolders auto.
stax76
27th September 2009, 19:59
@juGGaKNot
I'm not sure about the subfolder feature though it was requested before. It's not hard doing it using the explorer shell in Vista or Win 7, it's also possible with XP. You would gather your source files in the explorer window, for instance if you want all avi and wmv files including the one in subfolders you would enter the following search expression (I refer to Vista/Win 7):
ext:avi OR ext:wmv
Then you press Ctrl+A to select all files and drag & drop them on the file batch window in StaxRip or pass it to StaxRip using command line, generally StaxRip has rich shell and automation support. Adding files for batch processing assumes you've setup the settings you want to use for batch processing beforehand. Since it's OT please use the StaxRip thread for batch encoding related discussion. x264 and batch processing or automation in general has high priority so in case you have problems chances are good I can help.
juGGaKNot
27th September 2009, 20:15
they all have the same name, this is the problem, this is why i need exact folder replication ....
le : k i will post in the thread.
le 2 : nvm, VirtualDubBatcher does it all
Dark Shikari
27th September 2009, 21:24
Usually people decide to rather to use CLI or GUI. Both as has pros & cons. Recently I've added some features to StaxRip building a bridge for CLI users to enable them to take advantage of their CLI experience and minimize the requirement to learn how to use the GUI. These features are:
Changing a GUI setting instantly displays the updated command line
The GUI setting that was changed most recently is displayed bold
A Search feature where a switch (or part of) can be entered to quickly find the GUI control for this switch. There are so many features making it hard sometimes to find the setting especially when the GUI don't support the setting
A Go To features with same purpose as the Search feature which lists switches supported by the GUI in a drop down list
The possibility to import the x264 settings from a x264 command line in the clipboard. I've needed a afternoon to build a x264 command line parser but it's quite useful
Allowing to define additional command line parameters
https://sourceforge.net/dbimage.php?id=233700
Latest build: http://www.stax76.bplaced.net/files/applications/StaxRip/StaxRip_1.1.1.7_beta.7z
The image doesn't even make sense: --preset slow, but the "ref" dropdown shows three reference frames? :confused:
stax76
27th September 2009, 21:51
The image doesn't even make sense: --preset slow, but the "ref" dropdown shows three reference frames?
Good point, it requires some thought though because if you happily change and disable a lot controls it can become quickly a bug, usability and maintenance nightmare if you aren't careful. I have to spend some thought on it and wonder how other GUIs handle the issue?
Dark Shikari
27th September 2009, 22:15
Good point, it requires some thought though because if you happily change and disable a lot controls it can become quickly a bug, usability and maintenance nightmare if you aren't careful. I have to spend some thought on it and wonder how other GUIs handle the issue?Gray out the boxes which are not explicitly set by the user?
LoRd_MuldeR
27th September 2009, 22:36
The user should be able to set (overwrite) options explicitly, even if a specific profile was selected. Of course the preset's values should be used by default.
So we would need a checkbox in front of the "Reference Frames" edit box. Only if the checkbox is checked, the value from the edit box is used. Otherwise the preset's value is used and the edit box is disabled.
Alternatively instead of the checkbox a special value (for example "-1") could be used to indicate that the presets's value should be used.
Yet another option would be: Completely remove the "Reference Frames" edit box and similar ones. And let the user enter advanced options in x264's command-line syntax. That's what I did ;)
http://img204.imageshack.us/img204/4668/launcher.th.jpg (http://img204.imageshack.us/img204/4668/launcher.jpg)
stax76
27th September 2009, 23:02
Gray out the boxes which are not explicitly set by the user?
The back color of text controls is gray (system color 'control') when in readonly and disabled state (readonly and disabled state have a different text color), gray cannot be used for editable state because it looks like read only then.
Only thing I'm sure right know is there is a problem that needs to be fixed and I'm afraid it will be a bit work. All ideas help so thanks Dark Shikari and LoRd_MuldeR.
Sharc
28th September 2009, 00:58
What about just adding all user-selected switches to the command line, unless they comply with the preset default values?
stax76
28th September 2009, 01:11
I think changing a preset/tuning requires pretty much to change all effected controls accordingly, anything else has logic or usability issues. I hope somebody can point me to the source code defining the values for the preset/tuning options.
Dark Shikari
28th September 2009, 01:28
I think changing a preset/tuning requires pretty much to change all effected controls accordingly, anything else has logic or usability issues. I hope somebody can point me to the source code defining the values for the preset/tuning options.x264.c
stax76
28th September 2009, 01:48
Can I grab it with http or ftp somewhere?
Dark Shikari
28th September 2009, 01:52
Can I grab it with http or ftp somewhere?I'm confused. You develop an x264 GUI, yet you don't know how to download the source code for the program you're developing a frontend for? :confused: How do you compile your x264 binaries without having the source?
stax76
28th September 2009, 01:57
I don't use a C/C++ compiler unless I have to and this is usually my own little C++ applications, I grab x264 binaries from http://x264.nl
Dark Shikari
28th September 2009, 02:02
I don't use a C/C++ compiler unless I have to and this is usually my own little C++ applications, I grab x264 binaries from http://x264.nlThe first line of text on that page says "source:" ;)
LoRd_MuldeR
28th September 2009, 03:18
Can I grab it with http or ftp somewhere?
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=x264.c;hb=HEAD#l563
ajp_anton
28th September 2009, 04:42
The first line of text on that page says "source:" ;)I actually had to check this, and I laughed =)
stax76
30th September 2009, 01:27
@LoRd_MuldeR
Thanks for pointing me on spot, I hope I didn't appear too lacy on this, I made some attempt to find it but...
I'm working on the preset/tune/profile issue, choosing them will change all GUI settings accordingly and settings will only appear in the command line if they differ from the preset/tune/profile values.
LoRd_MuldeR
30th September 2009, 01:54
This way you will always have to keep your GUI consistent with the x264 presets.
Wouldn't it be easier to implement and especially easier to maintain, if you simply provide options to select the Preset/Tuning and let the user decide which settings should be set explicitly ???
stax76
30th September 2009, 02:49
Yes I have to keep track of the presets but it don't seem to be a big issue, usability has the highest priority.
Other thing I consider is not disabling controls but display a red warn/error message instead of the command line because of when a control is disabled a user might not understand why it is disabled.
LoRd_MuldeR
30th September 2009, 02:54
As suggested before, you could put a checkbox in front of each option ;)
When unchecked it means: Don't use that option, disable control, fall back to the current preset's default value. When checked it means: Use that option, overwrite the preset's value.
And if you don't like that many checkboxes, each option could offer a value like "default" or "auto", which means that the current preset's default value is used...
Selur
30th September 2009, 02:57
Here's how I handle this in a project I'm working on in my spare time:
1. User can select a preset (dropDownBox) and apply it (PushButton), when doing so the defaults and then the preset will be applied.
2. User can select a tune (dropDownBox) and apply it (PushButton), when doing so the parameters covered by the preset are changed.
3. During Command Line configuration I wrote two methods that will filter/minimize the command line. (check which preset/tune options fits best replace the switches covered by it, and last but not least remove the defaults from the command line)
(4. There's also an option to disable 3. and show all options in the command line)
So basically I separated the x264-model/setting changes from the command line view and filter the command line view. :)
Yes, this requires to keep up to date with the presets, but these can be adjusted swiftly. :)
Cu Selur
LoRd_MuldeR
30th September 2009, 03:27
I was thinking of something like this:
http://www.mediafire.com/file/35mnmxgmdzm/x264_gui.zip
Keep it simple and stupid (straightforward) :D
linyx
30th September 2009, 04:18
Only thing I'm sure right know is there is a problem that needs to be fixed and I'm afraid it will be a bit work.
I haven't looked at the StaxRip source code for ages, so I don't know if this would work well for you or not; but why not use a select case statement like this for when the Preset is changed:
Select Case Preset
Case Is = Slow
Me = umh
Subme = 9
Ref = 8
Badapt = 2
Direct = Auto
Partitions = All
Trellis = 2
End Select
imk
1st October 2009, 15:02
The user should be able to set (overwrite) options explicitly, even if a specific profile was selected. Of course the preset's values should be used by default.
So we would need a checkbox in front of the "Reference Frames" edit box. Only if the checkbox is checked, the value from the edit box is used. Otherwise the preset's value is used and the edit box is disabled.
Alternatively instead of the checkbox a special value (for example "-1") could be used to indicate that the presets's value should be used.
Just have the preset drop-down, and then dropdowns for the other values, and have "Default" so the user knows it will use the default value of the preset, and then they may override that by selecting what they want.
This way you wouldn't need a checkbox to enable/disable whether you want to override something or not.
You could also put in parenthesis what the default value is, i.e. "Default (3)" so that not only does the user know that it will be using the default, but that the default is also 3.
LoRd_MuldeR
1st October 2009, 15:24
Just have the preset drop-down, and then dropdowns for the other values, and have "Default" so the user knows it will use the default value of the preset, and then they may override that by selecting what they want.
That's exactly what I suggested as an alternative to the "checkboxes" approach.
However it only works nice with Combo-Boxes (DropDown-Boxes). When using a Spin-Edit, like for key-frame interval, a special value would need to be defined as "use default", e.g. "-1".
And that may be confusing for the user. So in that case a Checkbox may be the more convenient solution...
stax76
8th October 2009, 02:59
I've now changed it to update all settings according to the profile/preset/tuning. It does not need additional checkbox, I hope it's good now.
http://forum.doom9.org/showthread.php?p=1332504#post1332504
Betsy25
8th October 2009, 04:13
I think x264's current preset method is a real bitch for GUI programmers, don't know but it probably takes a lot of code, but perhaps the different settings could get a different colored background when set to the default value for the currently selected preset. For example:
Background Yellow = Default setting for current preset.
Background Light-Green = Higher than default for current preset.
Background Light-Red = Lower than default for current preset.
Dark Shikari
8th October 2009, 05:56
I think x264's current preset method is a real bitch for GUI programmersDo we have to remove every parameter under "analysis" for GUI programmers to get a clue?
The entire purpose of the preset system is so that people don't have to mess with parameters that they don't know anything about. 99% of people don't want to mess with them. And almost all of the rest that do want to mess with them don't know enough to get good results. So why spend so much time working to expose what people don't want or need?
Most people just want things to work.
If someone really wanted to tweak every last option for no good reason they would use the CLI anyways.
stax76
8th October 2009, 13:29
I don't know exactly how other GUIs do it, it took a few hours to integrate it in StaxRip but I don't mind to spend a bit time for a good feature.
ACrowley
8th October 2009, 14:24
I've now changed it to update all settings according to the profile/preset/tuning. It does not need additional checkbox, I hope it's good now.
http://forum.doom9.org/showthread.php?p=1332504#post1332504
Some Options are still not changing in your gui when changing Tune Options.
For example Tune-Grain. AQ Strength 0,5 should change in your Gui too, or am i wrong ?
However, its only a Display Problem in your Gui ,isnt it ?
Megui doesnt change the cmdline when using Tune Options ..very tricky to build a 100% working gui with the new preset/Tune System
stax76
8th October 2009, 14:59
@ACrowley
Thanks for pointing it out, a bit tricky maybe, I missed to update some labels and maybe some other stuff, I'll fix it shortly.
Betsy25
8th October 2009, 15:51
Well, my opinions are probably not what most want.
Perhaps add a "Strict Preset" or "Preset Only" checkbox next to the Preset option dialog, when checked all options which have a default for the selected Preset would be set to that default and dimmed (not possible to change) as long as the "Strict" is checked.
stax76
8th October 2009, 16:33
Such things are difficult, how would this help?
New version fixes the label issue and reorganizes some controls.
https://sourceforge.net/projects/staxmedia/files/StaxRip%20beta/StaxRip_1.1.1.9_beta.7z/download
ACrowley
8th October 2009, 18:11
Stxrip use the same Options for both Passes in x264 2pass VBR mode ? Thats not so good because x264 will lower the settings to run fast.
A Option to run 1 Pass with sumbe 2, Ref frames 1etc would be nice
And is this a Bug too ?
theres no effect into the cmdline when disable Partitions P4x4x ?
EDIT
Ah,v 1.1.1.9 has a Slow First Pass Option..i will try it
And the Preste/Tune Options working fine.
Can you add M2TS Container Suppport?
LoRd_MuldeR
8th October 2009, 18:12
Stxrip use the same Options for both Passes in x264 2pass VBR mode ? Thats not so good because x264 will lower the settings to run in turbo mode.
What's wrong about that? That's exactly how the "--slow-firstpass" option was intended ;)
A Option to run 1 Pass with sumbe 2, Ref frames 1etc would be nice
That option exists! The absence of "--slow-firstpass" will enfroce "--ref 1" and "--subme 2" during the first pass of a 2-Pass encode.
stax76
8th October 2009, 18:26
A Option to run 1 Pass with sumbe 2, Ref frames 1etc would be nice
There are options on the command line tab allowing to fully config the first pass:
Remove from preceding pass
Add to preceding pass
I'm suggesting to use the 'Slow Firstpass' option instead however.
thers no effect into the cmdline when disable Partitions P4x4x ?
I'll investigate it.
ACrowley
8th October 2009, 18:29
What's wrong about that? That's exactly how the "--slow-firstpass" option was intended ;)
That option exists! The absence of "--slow-firstpass" will enfroce "--ref 1" and "--subme 2" during the first pass of a 2-Pass encode.
yes..i see
But only when i dont overwrite it with own Settings?! And when a gui writes the same Parameters for both Passes into the cmdline its not fast. Thats what i mean
LoRd_MuldeR
8th October 2009, 18:49
yes..i see
But only when i dont overwrite it with own Settings?!
Nope, fast first-pass is applied last! So unless you specify "--slow-firstpass" all user settings will be overwritten with "turbo" settings ;)
Of course that only happens in the first pass of a 2-Pass encode...
ACrowley
8th October 2009, 18:56
Nope, fast first-pass is applied last! So unless you specify "--slow-firstpass" all user settings will be overwritten with "turbo" settings ;)
Of course that only happens in the first pass of a 2-Pass encode...
Ah ok..nice :)
stax76
8th October 2009, 19:50
Here is a hotfix regarding the partition bug:
http://www.stax76.bplaced.net/files/applications/StaxRip/StaxRip_1.1.1.9_beta_hotfix.7z
ACrowley
9th October 2009, 18:05
Here is a hotfix regarding the partition bug:
http://www.stax76.bplaced.net/files/applications/StaxRip/StaxRip_1.1.1.9_beta_hotfix.7z
Thank you...now Staxrip works fine so far with the new x264 Preset/Tune System/options:)
What i would like to see is
-M2TS Container Support (BitRate Calculator,Muxing)
-64 Bit x264 Support
-Pause Function doesnt works sometimes ?
-Also most AVS Plugins and some Apps (x264) are outdated
-I cant see any Deadzone inter/intra options ?
---no-dct-decimate --no-fast-pskip are reversed in your gui ?
no-fast-pskip
Default: Not Set
Disables early skip detection on P-frames. Fast skip detection increases speed but may cause slight blockiness in areas of solid color or slight gradients such as dark scenes or sky.
Recommendation: Enabled
no-dct-decimate
Default: Not Set
Disables coefficient thresholding on P frames.
Recommendation: Default
Not a big Problem but i was a little bit confused
stax76
9th October 2009, 21:19
Pause Function doesnt works sometimes?
It's some hack pausing all threads in a process, I'm not sure if there is a more robust way.
I cant see any Deadzone inter/intra options?
You can find out what switches are supported using the 'Search' and 'Go To' feature, IIRC Deadzone inter/intra isn't yet supported.
--no-dct-decimate --no-fast-pskip are reversed in your gui ?
All --no switches are reversed in the GUI (and code).
Regarding the non x264 related topics, probably better to discuss it in the StaxRip support thread.
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.