Should H264 frontends provide a unified codec options dialog?

[stax76]

There are several x264 frondends that use a own codec options dialog, probably more than 20 different. Applications with support for VFW codecs share the same dialog. Do you prefer individual dialogs or a unified dialog shared between applications? If so, please vote and explain why. You can also write which codec dialogs you like and which ones you don't like for what reasons. How should the layout look like, should it use a sidebar, tabs, sub dialogs or maybe you have some innovative ideas.

I prefer the codec distribution proving the codec options dialog to prevent duplication of work, building and maintaining such a dialog is a lot work, especially if the codec has more than 50 options, if I don't have to build a dialog I can spent the time with something else. Technically it's not a problem to bundle a codec dialog along with a command line encoder.

The reason why I ask this is DivX will release a H264 command line encoder and I'm asking the DivX people to provide a dialog and I'm asking the frontend authors to support me with this request.

[stax76]

> 25 views but no votes :rolleyes:

[Inventive Software]

I voted unified. There's far too many GUIs, and far too many opportunities to get confused. :D

[*.mp4 guy]

I voted that every frontend should have its own dialog, there just isn't any way to make everyone happy with one, universal gui. Just look at the hoards of people babling on about how awsome SUPER is, they make up most of the 'target market" for gui's, and If there was only one gui they wouldn't be happy if it had any options at all. You can't compromise that sort of attitude, with people like me, who aren't happy when, arguably nearly useless options like aq sensitivity, are removed from the cli's commandline switches.

[audyovydeo]

"x264 has more options than ls" (to paraphrase an old Jörg Schilling quote).

which is why evey GUI should aim to make them :
- all accessible
- immediately identifiable to average user

heck, I dumped megui because I found it *more* complicated than the x264 cmdline, dumped Stax because it "looks" too simple, and dumped avidemux because it doesn't expose all x264 options (or didn't - haven't checked in a while).

cheers
audyovydeo

PS : sorry Stax ... ;-)

[Ranguvar]

I voted that every GUI should have its own. More choices is good :)

[fields_g]

Frontends are good tools to target particular audiences needs. These needs will determine the options that should be visible. My vote, frontends determine who is in their market by developing individual dialogs.

[Avenger007]

From a development pov letting the codec distributor provide the codec options dialog is a good idea (e.g. think customizable JavaBean GUI components).

However, from my view (as user), I would prefer the front end to the encoder as a single options dialog with multiple tabs corresponding to (sub-)categories of options in H.264 specs.
There can be an additional dialog for options that are implementation specific wrt to the encoder.

In other works, specs provide the interfaces... so program to those interfaces, additional (implementation specific) interfaces should be provided by the codec distributor.
This way also allows for well defined documentation based on specs.

[Atak_Snajpera]

heck, I dumped megui because I found it *more* complicated than the x264 cmdline, dumped Stax because it "looks" too simple, and dumped avidemux because it doesn't expose all x264 options (or didn't - haven't checked in a while).
Wouldn't be easier to just say "I don't like Graphic User Interfaces at all" ?

BTW: I voted NO

[LoRd_MuldeR]

I voted "Every frontend should use a own dialog" because:

1. Not every front-end should bother the user with all the available options. Nevertheless a "Pro" front-end should be able to do that.
2. Different front-ends use different toolkits (native Win32, .NET, GTK+, Qt and so on), which makes one common interface hard to implement.
3. Front-end developers should have the freedom to design their own config dialog. Users will decided whether they like the front-end.

BTW: I think the Qt-based x264 config dialog planned for Avidemux 2.5 looks pretty promising (screenshots (http://www.mediafire.com/?vum2njdjzz9))

[stax76]

If DivX and other frontend authors don't like the idea I'll probably end up using the TreeView which StaxRip uses in various places, same thing VirtualDubMod uses. It's not as nice as a real dialog with normal controls but good enough and extremely easy to build and lightweight as every node/setting is a single line code only.

[stax76]

Not every front-end should bother the user with all the available options. Nevertheless a "Pro" front-end should be able to do that.

This could be addressed with a option 'hide advanced settings' like in VLC or Zoom Player. StaxRip addresses it using a tab called Basic showing the most basic settings.


Different front-ends use different toolkits (native Win32, .NET, GTK+, Qt and so on), which makes one common interface hard to implement.

On windows the toolkit isn't a issue, there could be different versions for different platforms.

Front-end developers should have the freedom to design their own config dialog. Users will decided whether they like the front-end.

Since we are discussing cmdl encoders here, this option remains of course.

[LoRd_MuldeR]

1. The development is going away from platform-specific applications. I think cross-platform becomes more important. So providing the common config dialog only for one specific toolkit is a bad idea. Porting it to many toolkits and keeping them all up-to-date would be a huge piece of work...

2. Another problem: It would be necessary that the host-application can disables/hide/restrict certain options in the config dialog. For example to ensure compatibility to a certain level/profile. Of course this could be implemented in the common dialog, but it would also make the API more complex...

[Avenger007]

Correct me if I'm wrong, aren't H.264 encoders supposed to implement H.264 specs to be considered H.264 encoders? So why not create a standard unified dialog that corresponds to the options in the specs?
This dialog would be updated when the specs change. A separate dialog can be used for encoder-specific features.

I'm suggesting a hybrid of the two options. :cool:

[Dark Shikari]

Correct me if I'm wrong, aren't H.264 encoders supposed to implement H.264 specs to be considered H.264 encoders? So why not create a standard unified dialog that corresponds to the options in the specs?Let's just hope they don't use the actual variable names used in the specs, because then there might be exploding heads :p

[LoRd_MuldeR]

So why not create a standard unified dialog that corresponds to the options in the specs?

Because their are so many encoder-specific settings that are not mentioned in the H.264 standard at all...

[Avenger007]

Because their are so many encoder-specific settings that are not mentioned in the H.264 standard at all...
Quote a little further down :rolleyes:

[Dark Eiri]

I don't think they all should share the same dialog. So, if you can't "understand" one of them, you can always search for another one.
The "Basic/Advanced" switch would be really nice, though. If the basic ones would switch some advanced ones automatically to keep the quality.

And you know what? I miss some really simple interface for x264, being able to produce high quality.
Sure, MeGUI profiles are easy enough for beginners, but that Quality/Speed slider from DivX is really user-friendly.
A simple GUI, featuring a slider that automatically implements those profiles (Fast, Slow, Slower, Slowest, Insane), with a field to insert the target bitrate or quantizer below would be like a dream for most beginners.

I defend that if you want to use something, you must KNOW how to use it and exactly what you're doing, so I think people should actually learn what-does-what, in CLI and stuff, but let's face it: most users just want to compress their videos without losing that much quality. That's why AutoGK was so successful, right? Extremely simple, yet with good results. That's the best thing for "standard" users.

When I see people trying to start encoding with x264, I see them going for really old VfW implementations. That just doesn't sound right for H264.
If there was an "AutoGK x264 Version", probably most beginners would go for it.

[Dark Shikari]

If there was an "AutoGK x264 Version", probably most beginners would go for it.And there are GUIs just like this; not all are very complex.

In my opinion, a GUI should have the following options:

1. Target Device: PC by default, but with options for PSP, iPod, Level 4.1 (PS3/graphics card/etc) and similar.

2. Target Formats: If a Target Device is chosen which allows multiple Formats for container, video, or audio, pick between them here.

3. Target bitrate or quality for video: pick between quality and bitrate mode, and for either, pick a value.

4. Target bitrate or quality for audio: pick between quality and bitrate mode, and for either, pick a value.

5. Video encoding performance (slider bar from Fast to Best with a rough estimation of effect on encoding speed and quality).

6. Input filename and output filename.

7. Simple but often-used and important options that relate to encoding but don't fit speed/quality as above. Example: Cartoon Mode (optimizes settings for animated footage). If its a not a checkbox, it probably shouldn't go here.

That's about all that's necessary, and it should fit on a single tab of a GUI.

Extra tabs should be available for more complex features, such as fine-tuning of encoding options and things like resizing, filtering, batch encoding, etc. As such, if the user wants, he can only use the first tab and never touch the others. Also, sliding the bar should change the encoding settings in the advanced tab(s) in realtime. The second tab after the first tab should cover interlacing and telecine, and the GUI should warn the user if it believes the input file to be interlaced or telecined, and point the user to that tab.

Such a GUI would not merely be supremely useful for users of all skill levels, but also would quite quickly put most competitors out of business faster than they can say "one-click GUI."

[stax76]

The slider is a great idea, target devices also.

[Avenger007]

@DS
What would the advanced tab(s) look like?
Some options would be present in almost all encoders and other options may be encoder-specific.

[Dark Shikari]

@DS
What would the advanced tab(s) look like?
Some options would be present in almost all encoders and other options may be encoder-specific.The advanced tab for encoder settings would just look like a big conglomeration of all MeGUI options, with lines between each section (divided logically and with tooltip help).

The appearance of the tab would change based on the encoder selected, of course.

[Avenger007]

The advanced tab for encoder settings would just look like a big conglomeration of all MeGUI options, with lines between each section (divided logically and with tooltip help).

The appearance of the tab would change based on the encoder selected, of course.
Wouldn't that be a nightmare for the front-end developer to maintain?

[Brother John]

I voted yes, meaning a common config dialogue would be nice for both developers and users. Just to make sure that we’re talking about the same thing: Is it a common x264 config dialogue or or a common H.264 config dialogue for a multitude of encoders (maybe even not only H.264)?

[Dark Shikari]

Wouldn't that be a nightmare for the front-end developer to maintain?Why would it be? It isn't as if x264 options change very often.

[Avenger007]

Why would it be? It isn't as if x264 options change very often.
I assumed the front-end would apply to many H.264 encoders. I was thinking that an encoder-specific dialog could be developed and maintained (possibly by different people like encoder distributors) independently from the dialog showing core options based on specs. I think this would also make documentation (aka tool tips) of options and features easier.
Also, if the specs dialog is used across all front-ends then users will have a uniform view of the features available in H.264. The encoder-specific dialogs would highlight differences between encoders.