Avidemux Forum

following on from http://www.avidemux.org/smf/index.php?topic=10730.msg57668#msg57668 "how are these combinations of codecs with containers?"  there was some discussion about the GUI

and a suggestion from JM.
(https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fi50.tinypic.com%2Fsbosw7.png&hash=799aa1bc222d16edc4069ac8f39e6a97463fa0a3)

i'll put some of my comments here 'cos they're more appropriate in this section

I don't think parentheses are so bad..

-
Putting mpeg4 in parentheses is fine but one could say  ff-mpeg4  just to show that it's ffmpeg's  mpeg4.   Putting libavcodec in parentheses isn't that useful as it refers to ffmpeg's whole library of codecs.  ffmpeg does name each codec so if using libavcodec and using for example, mpeg4 then ff-mpeg4 is good and completely clear.

it's listed by ffmpeg, very specifically.

C:\>ffmpeg -codecs | find /i "mpeg4"
DEVSDT mpeg4           MPEG-4 part 2
DEVSD  msmpeg4         MPEG-4 part 2 Microsoft variant version 3
DEVSD  msmpeg4v1       MPEG-4 part 2 Microsoft variant version 1
DEVSD  msmpeg4v2       MPEG-4 part 2 Microsoft variant version 2
C:\>

Regarding anything nonsensical about "FLV1(flash)"

Suppose they get the codec from ffmpeg.

Why not   Flash(ff-flv)

I don't see why something like that with parentheses needs to be nonsensical.

MPEG-4 AVC and right below MPEG-4 ASP in there with proper names is confusing in a notation of codec format(codec).  but maybe they could go in italics as colloquial names..though MPEG-4 ASP is more necessary as a colloquial name than MPEG-4 AVC but both names seem to be used colloquially I suppose. 

The colloquial names could go alongside  proper names.  But "part this" and "part that" gets ugly and perhaps those proper names should be in a help file that really elaborates about the names. The rest of the proper names like H.263 or AVC, are neat and could easily fit alongside the colloquial names.

In your screenshot of the style you suggest, why is the Input(Left hand side),in a different format to the output?

Like on the left hand side you say MPEG-4 ASP.. (you include the profile you don't write the part)  and on the right hand side you write MPEG-4 Part 2. i.e. you write the part and don't write the profile

I suppose the left hand side isn't input, as input would just be, settings of the current file, and just needs one line saying the file's container and codecs,  and no options. So I wouldn't know what the left hand side was.  As to the menus for container, video codec and audio codec..  I think 3 menus(one for each) could make it  nauseating to see at a glance what the options are.   But as there aren't that many options for compatible combinations of  container, audio codec and video codec,  then perhaps there could be one menu for container, and below, another or better (what they call in VB) a list box, that lists all the combinations of compatible audio and video  codecs, for that container. That has the advantage of being educational too. An "advanced gui" option for container and codecs could have 3 menus or list boxes, container, video codec, audio codec, and the user can choose whichever combination,  and there can be some text at the bottom of the screen that says whether it's compatible or not or how compatible, whether recommended or not.

I guess I don't really see why there are 2 columns?

Quote from: garin on June 23, 2012, 02:31:26 AMI don't think parentheses are so bad..

That's what I thought in 2005, too. 7 years later, I think it is quite clear... That is is not clear. :) People have no idea what they mean.

QuoteMPEG-4 AVC and right below MPEG-4 ASP in there with proper names is confusing in a notation of codec format(codec).

It is confusing because AVC and ASP are not at the same level in the logical hierarchy. Advanced Video Coding is a name for Part 10, while Advanced Simple profile is a profile of Part 2. And the user can choose some other Part 2 profile, too.

Quotebut maybe they could go in italics as colloquial names..though MPEG-4 ASP is more necessary as a colloquial name than MPEG-4 AVC but both names seem to be used colloquially I suppose. 

The colloquial names could go alongside  proper names.  But "part this" and "part that" gets ugly and perhaps those proper names should be in a help file that really elaborates about the names. The rest of the proper names like H.263 or AVC, are neat and could easily fit alongside the colloquial names.

The problem is that in this layout, you have to keep the names short or it will make the drop-down list, and hence the whole A/V sidebar, and hence the whole window, ridiculously wide. You could also truncate the names, which is not too good either. Or you would have to invent a new way of presenting all this in the Avidemux window. But in this current layout, I'm afraid the only reasonable option is choosing a single name for each format. But sure, the documentation should explain the format names in more detail.

QuoteIn your screenshot of the style you suggest, why is the Input(Left hand side),in a different format to the output?

It's not input and output. It is a comparison. Both are outputs in the A/V sidebar in the main Avidemux window. The picture on the left is the current 2.5 Avidemux version (or used to be the current version when I made that picture some time ago originally for the Why call MPEG4 part 2 "ASP"? (http://www.avidemux.org/smf/index.php?topic=10188) topic), while the picture on the right is my proposal for a new, improved version, explained in more detail in those two previous topics (1 (http://www.avidemux.org/smf/index.php?topic=8874.0), 2 (http://www.avidemux.org/smf/index.php?topic=10188), the pictures got deleted in these old topics, so it is now reposted here).

QuoteLike on the left hand side you say MPEG-4 ASP.. (you include the profile you don't write the part)  and on the right hand side you write MPEG-4 Part 2. i.e. you write the part and don't write the profile

Because the user does not have to use the Advanced Simple Profile.

QuoteAs to the menus for container, video codec and audio codec..  I think 3 menus(one for each) could make it  nauseating to see at a glance what the options are.   But as there aren't that many options for compatible combinations of  container, audio codec and video codec,  then perhaps there could be one menu for container, and below, another or better (what they call in VB) a list box, that lists all the combinations of compatible audio and video  codecs, for that container.

Now that would be really nauseating. :D Just imagine:

Matroska
  Copy/Copy
  Copy/MJPEG
  PCM/MJPEG
  MP3/MJPEG
  MP2/MJPEG
  Vorbis/MJPEG
  AAC (FAAC)/MJPEG
  AAC (libavcodec)/MJPEG
  AC3 (aften)/MJPEG
  AC3 (libavcodec)/MJPEG
  Copy/MPEG-2 Part 2
  PCM/MPEG-2 Part 2
  MP3/MPEG-2 Part 2
  MP2/MPEG-2 Part 2
  Vorbis/MPEG-2 Part 2
  AAC (FAAC)/MPEG-2 Part 2
  AAC (libavcodec)/MPEG-2 Part 2
  AC3 (aften)/MPEG-2 Part 2
  AC3 (libavcodec)/MPEG-2 Part 2
  Copy/MPEG-4 Part 2 (libavcodec)
  PCM/MPEG-4 Part 2 (libavcodec)
  MP3/MPEG-4 Part 2 (libavcodec)
  MP2/MPEG-4 Part 2 (libavcodec)
  Vorbis/MPEG-4 Part 2 (libavcodec)
  AAC (FAAC)/MPEG-4 Part 2 (libavcodec)
  AAC (libavcodec)/MPEG-4 Part 2 (libavcodec)
  AC3 (aften)/MPEG-4 Part 2 (libavcodec)
  AC3 (libavcodec)/MPEG-4 Part 2 (libavcodec)
  Copy/MPEG-4 Part 2 (Xvid)
  PCM/MPEG-4 Part 2 (Xvid)
  MP3/MPEG-4 Part 2 (Xvid)
  MP2/MPEG-4 Part 2 (Xvid)
  Vorbis/MPEG-4 Part 2 (Xvid)
  AAC (FAAC)/MPEG-4 Part 2 (Xvid)
  AAC (libavcodec)/MPEG-4 Part 2 (Xvid)
  AC3 (aften)/MPEG-4 Part 2 (Xvid)
  AC3 (libavcodec)/MPEG-4 Part 2 (Xvid)
  Copy/MPEG-4 Part 10
  PCM/MPEG-4 Part 10
  MP3/MPEG-4 Part 10
  MP2/MPEG-4 Part 10
  Vorbis/MPEG-4 Part 10
  AAC (FAAC)/MPEG-4 Part 10
  AAC (libavcodec)/MPEG-4 Part 10
  AC3 (aften)/MPEG-4 Part 10
  AC3 (libavcodec)/MPEG-4 Part 10
  Copy/huffYUV
  PCM/huffYUV
  MP3/huffYUV
  MP2/huffYUV
  Vorbis/huffYUV
  AAC (FAAC)/huffYUV
  AAC (libavcodec)/huffYUV
  AC3 (aften)/huffYUV
  AC3 (libavcodec)/huffYUV
  Copy/FLV1
  PCM/FLV1
  MP3/FLV1
  MP2/FLV1
  Vorbis/FLV1
  AAC (FAAC)/FLV1
  AAC (libavcodec)/FLV1
  AC3 (aften)/FLV1
  AC3 (libavcodec)/FLV1
  Copy/YV12
  PCM/YV12
  MP3/YV12
  MP2/YV12
  Vorbis/YV12
  AAC (FAAC)/YV12
  AAC (libavcodec)/YV12
  AC3 (aften)/YV12
  AC3 (libavcodec)/YV12
AVI
  Copy/Copy
  Copy/MJPEG
  PCM/MJPEG
  MP3/MJPEG
  MP2/MJPEG
  AC3 (aften)/MJPEG
  AC3 (libavcodec)/MJPEG
  Copy/MPEG-4 Part 2 (libavcodec)
  PCM/MPEG-4 Part 2 (libavcodec)
  MP3/MPEG-4 Part 2 (libavcodec)
  MP2/MPEG-4 Part 2 (libavcodec)
  AC3 (aften)/MPEG-4 Part 2 (libavcodec)
  AC3 (libavcodec)/MPEG-4 Part 2 (libavcodec)
  Copy/MPEG-4 Part 2 (Xvid)
  PCM/MPEG-4 Part 2 (Xvid)
  MP3/MPEG-4 Part 2 (Xvid)
  MP2/MPEG-4 Part 2 (Xvid)
  AC3 (aften)/MPEG-4 Part 2 (Xvid)
  AC3 (libavcodec)/MPEG-4 Part 2 (Xvid)
  Copy/MPEG-4 Part 10
  PCM/MPEG-4 Part 10
  MP3/MPEG-4 Part 10
  MP2/MPEG-4 Part 10
  AC3 (aften)/MPEG-4 Part 10
  AC3 (libavcodec)/MPEG-4 Part 10
  Copy/huffYUV
  PCM/huffYUV
  MP3/huffYUV
  MP2/huffYUV
  AC3 (aften)/huffYUV
  AC3 (libavcodec)/huffYUV
  Copy/FLV1
  PCM/FLV1
  MP3/FLV1
  MP2/FLV1
  AC3 (aften)/FLV1
  AC3 (libavcodec)/FLV1
  Copy/YV12
  PCM/YV12
  MP3/YV12
  MP2/YV12
  AC3 (aften)/YV12
  AC3 (libavcodec)/YV12
MP4
  Copy/Copy
  Copy/MPEG-4 Part 2 (libavcodec)
  MP3/MPEG-4 Part 2 (libavcodec)
  AAC (FAAC)/MPEG-4 Part 2 (libavcodec)
  AAC (libavcodec)/MPEG-4 Part 2 (libavcodec)
  Copy/MPEG-4 Part 2 (Xvid)
  MP3/MPEG-4 Part 2 (Xvid)
  AAC (FAAC)/MPEG-4 Part 2 (Xvid)
  AAC (libavcodec)/MPEG-4 Part 2 (Xvid)
  Copy/MPEG-4 Part 10
  MP3/MPEG-4 Part 10
  AAC (FAAC)/MPEG-4 Part 10
  AAC (libavcodec)/MPEG-4 Part 10
.
.
.
.
.
.
.
.
.
And the list goes on and on and on and on and on...
.
.
.
.
.
...and on and on and on...

Nah. I think this would drive people crazy :) The problem with this approach is that it does not scale well. Three separate menus scale much better. Two menus would be practical only for simple applications that offer a very limited set of encoders.

QuoteAn "advanced gui" option for container and codecs could have 3 menus or list boxes, container, video codec, audio codec, and the user can choose whichever combination,  and there can be some text at the bottom of the screen that says whether it's compatible or not or how compatible, whether recommended or not.

Making "advanced" options in the main window could be awkward. In a separate dialog, maybe (even though, in my experience, it is usually awkward in separate dialogs, too). But still, the A/V sidebar was put in the main window exactly because it is the heart and soul of Avidemux and its workflow. You select a video encoder, and then you can add a video filter... I think every Avidemux user should understand this concept, these three things (video encoder, audio encoder, container format), because that's the way Avidemux (and not only Avidemux) works.

But yes, Avidemux could suggest which combinations are compatible (possibly by listing only those compatible options). This was suggested several times before, but Avidemux is not that intelligent yet. I don't even remember if this suggestion was rejected for some reason (is it a good idea or not? It could make the list boxes more confusing.) or simply not implemented...

First thoughts..

ok,  ff-  is a bad idea,

But regarding mpeg4.   I think alone it isn't useful.

libavcodec alone says too little.

while mpeg4 is a command line parameter, a command line parameter from ffmpeg -codecs is not a command line parameter like absolutely any other. And the software package, ffmpeg, has a relationship to libavcodec unlike any other software package, given that libavcodec was developed by the ffmpeg team.

ffmpeg takes itself so seriously as a command line program, and of course has no gui anyway. It's not likely to change those  command line parameters in -codecs.

mpeg4 and the other names, aren't as official as one might like, but I think being part of the list from ffmpeg -codecs,  it is fairly well established.

it's not libavcodec's mpeg4.. as ffmpeg names it..

but how about a notation e.g. 
ffmpeg - mpeg4
The notation could be defined in documentation.  the codec in libavcodec that ffmpeg calls mpeg4.

It looks like the distinction between  Video Compression Format, and Codec    should be strengthened.. and a good way is to separate them.

So,  Video and Audio could have 2 menus.. "Compression format"  and "encoder"

Mpeg-4 Part2  does at least have a proper name that isn't ugly.  Mpeg4-Video
and of course Mpeg-4 Part 10 has neat names.

If colloquial names "MPEG4-ASP" "MPEG4-AS" "MPEG-AVC"  don't fit, then they could go in documentation.  Along with the proper names that are ugly like "part this" and "part that".


Second thoughts..

How about a more transitional change..

keeping the GUI design looking similar to how it does

scrap MPEG-4 AVC  , changing it to just AVC,H.264 (...)
scrap MPEG-4 ASP , changing it to MPEG-4 Visual (..)   

You could include MPEG-4 AVC and MPEG-4 ASP in grey with a strikethrough line through them, and if chosen then a msgbox could come up saying to  choose ....


It's a small change that would clear up some confusion.  I don't really see any downside to doing that?


I don't know whether saying ffmpeg's mpeg4  is better than just mpeg4.  I prefer either of those to changing to libavcodec, as saying libavcodec is just so unspecific.

If at some point it was decided to have 2 menus for Video Codec,  (compression format and encoding). 2 for Audio..    Then, it wouldn't be such a sudden change. Because the notation would already divide between  Compression Format, and Encoding.

btw where's the option to encode Mpeg-4 Part 2  SP?  In the menu the only MPEG-4 ones that I see, are Compression Format of MPEG-4 Part2  with ASP profile, and I see  Compression Format of AVC.

Quote from: garin on June 23, 2012, 04:53:07 AMlibavcodec alone says too little.

Is says everything that's needed. It is a unique, unambiguous identifier, just like "Xvid" or "x264".

"MPEG-4 Part 10 (x264)" says "the format is MPEG-4 Part 10, the encoder library is x264".
"MPEG-4 Part 2 (Xvid)" says "the format is MPEG-4 Part 2, the encoder library is Xvid".
"MPEG-4 Part 2 (libavcodec)" says "the format is MPEG-4 Part 2, the encoder library is libavcodec".

Which is true, correct, googleable, and understandable.

There is no option in the encoder menu called just "libavcodec". I have no idea how anyone on earth would get that "mpeg4" means it is from libavcodec.

As far as I remember, the only reason why neither "libavcodec" nor "FFmpeg" was used as an identifier in the 2005 GUI version (and hence why it is still not used today) was because people thought they needed to install FFmpeg to use Avidemux. So cryptic names like "lavc" or "ff" were used to obfuscate the origin. Which is not a reason I would agree with, and especially not in 2012, but that was the decision.

Quotewhile mpeg4 is a command line parameter, a command line parameter from ffmpeg -codecs is not a command line parameter like absolutely any other. And the software package, ffmpeg, has a relationship to libavcodec unlike any other software package, given that libavcodec was developed by the ffmpeg team.

But it is a command-line parameter. Not a product name. All those names in the codec command-line list follow this naming scheme. A shortened lowercase string (e.g. "nuv", which is not the correct name for NuppelVideo, just a commandline parameter, "mp2", which is not the correct name for MPEG-1 Layer II  aka MP2, just a commnandline parameter in FFmpeg, or "mpeg4", which is not the correct full name for "MPEG-4"), followed by an explanation (full name) in the help output:

DEVSDT mpeg4           MPEG-4 part 2

What this line says is that the MPEG-4 Part 2 encoder from libavcodec can be used in the FFmpeg program by writing "mpeg4" on the command line (because writing "MPEG-4" on the command line would be problematic, and because everyone knows this is FFmpeg, so "FFmpeg MPEG-4" would be redundant). Nothing else than that. It does not say that the name of this software product is "mpeg4".

Scientifically speaking, this line says three things:

• DEVSDT: decoding and encoding supported, it is for video, supports draw_horiz_band, direct rendering method and weird frame truncation
• mpeg4: a command-line string to use this codec
• MPEG-4 part 2: description of this codec

Quoteffmpeg - mpeg4
The notation could be defined in documentation.

This is really just a variation of "MPEG-4 (FFmpeg)"  which does not really solve the problem this topic was trying to address. It does not matter whether you use "Format (encoder)" notation or "Encoder - format", or any other cryptic notation, because people simply do not understand what the secret notation - any secret notation - means. Even if you explain it in the documentation, people will not read it. And even if the read it, they will not understand it. That's the experience of the whole Avidemux history. In my opinion, based on 10 years of very extensive experience with this phenomenon, and not only in this forum, the only way to make people understand what the labels mean is directly saying what the labels mean. I cannot see any reason for not doing it, except perhaps for saving a couple of pixels.

QuoteYou could include MPEG-4 AVC and MPEG-4 ASP in grey with a strikethrough line through them, and if chosen then a msgbox could come up saying to  choose ....


It's a small change that would clear up some confusion.  I don't really see any downside to doing that?

Some concerns:

• Why grey, why a strikethrough? A strikethrough is redundant when an item is greyed out, and only items that are not available in the current context should be greyed out. Making an item available by selecting it is not what any user interface guideline would recommend, as it would create confusion rather than clearing it up.
• Opening dialogs by selecting a drop-down list item is not exactly good UI practice either. I would prefer at least a small "Configure" button (even just a small icon). Then the greyed out items would start to make sense, because they would be unavailable until you press the configure button and select an encoder. Otherwise it would mean "Copy". But then, for formats having just a single encoder, the button should be greyed out (and the list item should be enabled by default).

Considering the concerns above, I'm worried that this could make the GUI more clumsy and confusing instead of simplifying it.

QuoteMpeg-4 Part2  does at least have a proper name that isn't ugly.  Mpeg4-Video
and of course Mpeg-4 Part 10 has neat names.

If colloquial names "MPEG4-ASP" "MPEG4-AS" "MPEG-AVC"  don't fit, then they could go in documentation.  Along with the proper names that are ugly like "part this" and "part that".

Yes, the documentation should mention all that. I'm just not sure if people would read it... But that's not a reason not to include it there.

QuoteIf at some point it was decided to have 2 menus for Video Codec,  (compression format and encoding). 2 for Audio..    Then, it wouldn't be such a sudden change. Because the notation would already divide between  Compression Format, and Encoding.

Yes, I think 2 menus would be a much better option. It would also solve the two-line item problem with my suggestion in the picture. I was thinking of this option, too, and the possible problems were:

• You would have to find a sensible way to cram this into the window, again without making it too bloated
• Someone would have to implement it. And I don't mean the GUI, but the automatic "compatibility list" in the Avidemux encoder plugins where the encoder list would dynamically change based on the format selection. But this point generally applies to my original suggestion, too (the picture) - it is not just a GUI change (that's the easy part), but primarily a change inside Avidemux.

Quote from: JM

Is(libavcodec) says everything that's needed. It is a unique, unambiguous identifier, just like "Xvid" or "x264".

"MPEG-4 Part 10 (x264)" says "the format is MPEG-4 Part 10, the encoder library is x264".
"MPEG-4 Part 2 (Xvid)" says "the format is MPEG-4 Part 2, the encoder library is Xvid".
"MPEG-4 Part 2 (libavcodec)" says "the format is MPEG-4 Part 2, the encoder library is libavcodec".

Which is true, correct, googleable, and understandable.

There is no option in the encoder menu called just "libavcodec". I have no idea how anyone on earth would get that "mpeg4" means it is from libavcodec.

The current notation at the moment  (mpeg4)  (mpeg1video),  these seem to be ffmpeg's command line parameters. So not sure what you mean, as somebody on earth could realise it's from libavcodec.    As, contents of parentheses are or are often.. Or, the fact that it's all lowercase and no hiphen between mpeg and 4, it's exactly the name of ffmpeg's.  Maybe i'm misunderstanding you there.


"MPEG-4 Part 2 (libavcodec)" says "the format is MPEG-4 Part 2, the encoder library is libavcodec".

yes but libavcodec  has a variety of codecs that could fit into MPEG-4 Part 2
  one could do  ffmoeg with  -vcodec libxvid

DEVSDT mpeg4           MPEG-4 part 2
DEVSD  msmpeg4         MPEG-4 part 2 Microsoft variant version 3
DEVSD  msmpeg4v1       MPEG-4 part 2 Microsoft variant version 1
DEVSD  msmpeg4v2       MPEG-4 part 2 Microsoft variant version 2

EV    libxvid         libxvidcore MPEG-4 part 2

and maybe divx  if  libavcodec supports it

a codec within libavcodec, that works with that codec format, could be any of those above.
So, to say libavcodec is not specific.


Regarding the transitional idea.. where still ugly proper names are only in documentation.. and only proper names are in the menus for Video and Audio, but the notation is fixed up.. it's a small transition for the user.

Instead of trying to make a user feel comfortable by putting the old  MPEG-4 ASP and MPEG-4 AVC  greyed out. How about, removing them and putting a Note at the bottom..
"Looking for the old option- MPEG-4 ASP ?  Click here"

A help window can then appear giving some explanation and telling them to choose MPEG-4 Visual.

That wouldn't be a big change, just notation being fixed

More Menus and set based on the value in others, as you say, would be a bigger change.
There might be an efficiency tradeoff , to having lots of menus, 2 for video e.t.c.. as at the moment, the video and audio menus aren't that big.   It might not justify that many menus.  On the other hand.. 5 menus vs the current 3 menus, is maybe not too many.

Quote from: garin on June 23, 2012, 11:36:52 AMyes but libavcodec  has a variety of codecs that could fit into MPEG-4 Part 2

It doesn't. MSMPEG-4 is not MPEG-4 Part 2. It is a slightly different format (not MPEG-4 compliant) used in the early Microsoft codecs. Even though, of course, libavcodec reuses common code for all these MPEG-based formats.

Quoteone could do  ffmoeg with  -vcodec libxvid

But that's just an interface to use the Xvid library from FFmpeg. It is not the MPEG-4 codec from libavcodec.

Quoteand maybe divx  if  libavcodec supports it

It doesn't support it.

There is only one MPEG-4 Part 2 codec in libavcodec. Confusion is impossible. Besides, the MPEG-4 codec in libavcodec is not a standalone product. That's also why it doesn't have a name. It is just one of many functions available in libavcodec.

QuoteRegarding the transitional idea.. where still ugly proper names are only in documentation.. and only proper names are in the menus for Video and Audio, but the notation is fixed up.. it's a small transition for the user.

Yes, that's at least something. Better than nothing. Still, it's not a question of changing the GUI (which is only generated from the plugin descriptions).

QuoteInstead of trying to make a user feel comfortable by putting the old  MPEG-4 ASP and MPEG-4 AVC  greyed out. How about, removing them and putting a Note at the bottom..
"Looking for the old option- MPEG-4 ASP ?  Click here"

A help window can then appear giving some explanation and telling them to choose MPEG-4 Visual.

I don't think anything as complicated as this would be needed because what the user is really looking for is just Xvid. They don't care about MPEG-4 whatever, they just want to use Xvid (OK, in 2012, people want to use x264). People often don't even know what MPEG-4 is, but everyone has heard of Xvid. So the MPEG-4 something is there mainly to tell them that Xvid is not the output format, just the encoder. Most people don't know this. Most people think that Xvid is a video format.

QuoteMore Menus and set based on the value in others, as you say, would be a bigger change.
There might be an efficiency tradeoff , to having lots of menus, 2 for video e.t.c.. as at the moment, the video and audio menus aren't that big.   It might not justify that many menus.  On the other hand.. 5 menus vs the current 3 menus, is maybe not too many.

5 menus would be basically the same thing as my picture at the top, just with the added advantage that single-line entries would be used, which would avoid the repetition in the menus. But yes, using more menus could be more tiresome. I think a small prorotype/demo could be built and tested to see if it's usable...

Is it the case for any video format, that libavcodec never defines more than one of a codec for  it?  if so, then great , libavcodec in parentheses would indeed be specific.

Putting aside the parentheses

For the menus then, each time a menu option is changed, a function would run to make the rest consistent.
I suppose, one amendment that could be made easily, is for the menu item "Copy",
I suppose if doing menus,

The menus could get a bit tricky, if for example, an item is chosen in one menu, say some audio codec is chosen.  The user wants to specify some video codec, but it conflicts with the audio codec he chose , so it doesn't appear.

How would he know that to make the video codec he wants appear, he has to change the audio codec?

Regarding a small transition, just  fixing the notation (while keeping ugly names in the documentation).  You say "Still, it's not a question of changing the GUI (which is only generated from the plugin descriptions)."

So what's it a question of then?


I think a useful tool would be
2 columns. the 5 menus.
Left hand  column, you enter in a video codec, then hit "Show Compatible" and in the other column it populates the menus with what's compatible.

You could choose a Video codec and Audio codec, then click "show compatible", and it'd show.

Could choose a Container, then "Show Compatible."


Also..
You say people generally look for a particular video codec.. and don't care about compression format.

Do they care about the container format?
i'd think they should, as huge size difference between .mpg and .mp4, or .mpg and other things.

Quote from: garin on June 23, 2012, 09:43:13 PMIs it the case for any video format, that libavcodec never defines more than one of a codec for  it?

Well, yes, at least for the formats Avidemux uses, depending on what you mean by codec or what you mean by "define". I would say "has its own implementation" or something like that. You can use either the libavcodec codecs or external libraries for encoding when you use FFmpeg. For example, you can encode with the MPEG-4 encoder from libavcodec (an MPEG-4 codec written by the libavcodec developers and included in libavcodec) or with the Xvid MPEG-4 encoder (which is an external library, a different product made by different people). Or you can use the libavcodec Vorbis audio encoder (poor) or the external libvorbis encoder (much better) for Vorbis encoding.

So while libavcodec and FFmpeg offer and present these external encoders as "codecs" in the codec list, just like the "native" libavcodec codecs, giving you multiple options for the same format, they are just interfaces for using these external libraries. FFmpeg then becomes just an encoder frontend using a 3rd party library, just like Avidemux can use some of these external libraries for encoding, too.

So you have to differentiate between libavcodec codecs and external ones.

QuoteThe menus could get a bit tricky, if for example, an item is chosen in one menu, say some audio codec is chosen.  The user wants to specify some video codec, but it conflicts with the audio codec he chose , so it doesn't appear.

How would he know that to make the video codec he wants appear, he has to change the audio codec?

That's a problem. Whenever something suddenly disappears from a menu or appears in it, the user will be confused. Maybe that's why this idea wasn't accepted several years ago... (I don't really remember.)

QuoteRegarding a small transition, just  fixing the notation (while keeping ugly names in the documentation).  You say "Still, it's not a question of changing the GUI (which is only generated from the plugin descriptions)."

So what's it a question of then?

I mean, the naming is done primarily in the Avidemux internals, in the plugin code. And the more you want to change the naming logic (like adding format categories etc.), the more you have to change that code. It's not just about changing the GUI. That's why it hasn't been implemented yet. :) Changing the internals is not something everyone is too keen on doing.

QuoteI think a useful tool would be
2 columns. the 5 menus.
Left hand  column, you enter in a video codec, then hit "Show Compatible" and in the other column it populates the menus with what's compatible.

You could choose a Video codec and Audio codec, then click "show compatible", and it'd show.

Could choose a Container, then "Show Compatible."

This is an interesting idea. Compatible encoders would not be shown by default, but only on request, which would solve the problem with confusing menus.

QuoteYou say people generally look for a particular video codec.. and don't care about compression format.

Do they care about the container format?
i'd think they should, as huge size difference between .mpg and .mp4, or .mpg and other things.

Well, the size difference is usually negligible, does not depend on the container too much (.mpg, i.e. MPEG-PS files usually contain MPEG-1 or MPEG-2 video, that's why they're bigger than MP4 files that usually contain H.264 video that can use lower bitrate). They do not care about it too much, but again, mainly because they don't know what a container format is. Or they simply don't know which one they should use. They should know that.

Quote from: garin
Regarding a small transition, just  fixing the notation (while keeping ugly names in the documentation).  You say "Still, it's not a question of changing the GUI (which is only generated from the plugin descriptions)."
So what's it a question of then?

Quote from: JM
I mean, the naming is done primarily in the Avidemux internals, in the plugin code. And the more you want to change the naming logic (like adding format categories etc.), the more you have to change that code. It's not just about changing the GUI. That's why it hasn't been implemented yet.  Changing the internals is not something everyone is too keen on doing.

The names shown in the GUI could be done at the GUI level,  no reason why the GUI can't be flexible in what names it shows and how it shows them, regardless of what it sees in the internals.  Or better names could be stored and pulled by the GUI, from some in between level like an API between GUI and internals. Maybe the former idea of names stored in the GUI is better and simpler.  But either way, Names don't have to be pulled from the internals to show on  the GUI.

Quote from: garin on June 24, 2012, 01:32:11 AMThe names shown in the GUI could be done at the GUI level,  no reason why the GUI can't be flexible in what names it shows and how it shows them, regardless of what it sees in the internals.  Or better names could be stored and pulled by the GUI, from some in between level like an API between GUI and internals. Maybe the former idea of names stored in the GUI is better and simpler.  But either way, Names don't have to be pulled from the internals to show on  the GUI.

They should be, because they are automatically generated from the list of the available (compiled, installed) plugins. All encoders and muxers are plugins in Avidemux, and some of them are optional (i.e. not always available, depending on the compilation options and installed files). So Avidemux can never know what's available, the plugins are scanned at startup. Yes, all official encoder plugins in Avidemux currently come from the official Avidemux source code, so the GUI could overwrite the info for the known ones. But that would be an ugly hack. And people can write their own plugins which are not included in Avidemux. So the best, cleanest option would be if each encoder plugin would store:

• The format
• The encoder name

And for the idea presented in my picture above, the muxer plugins could store:

• The format
• The filename extension

Then the GUI would be free to present this information in any way.

Quote from: JM
Then the GUI would be free to present this information in any way.

I think the GUI should still store its own, so as not to be at the mercy of what a plugin stores.

When a codec format has a few names, like MPEG-4 Layer 2  is one,  MPEG-4 Visual  is another.  Then the GUI shouldn't have to present just what is stored in the "video compression format" field of the plugin. It may be the ugly name!  Or,  it may not be as comprehensive a name as the neat- AVC,H.264

And once the GUI has that facility to store its own, then I don't think it's ugly to use it to store its own form of names, for known plugins.

Regarding your screenshot, I suppose the right hand side is the consistent one..
Supposing ugly names like the ones with Layer in them, are moved out of the GUI..
Looking at that display, of video audio and container format in your screenshot
Assuming that ugly names were removed.
The menu would still be chunky.
Why not then use parentheses?
in the form-   codec format(codec implementation)


(I think Container format seems more meaningful than output format..  As they're all outputs as much as each other, and there is no one format, there's a format for video, format for audio, format for container.. so container format seems better)


When a program has a chunky GUI, then perhaps many instances could eat more memory on a program with low memory. I don't know if it's exactly a RAM issue or just strongly related or correlating with RAM, but i've seen one or two laptops where after a certain number of programs are open, another won't open or will but with a menu not opening or not showing.  I generally prefer programs with smaller footprints.  But, I still think your menu, right hand side of screenshot, is good.

Quote from: garin on June 24, 2012, 10:44:27 AMI think the GUI should still store its own, so as not to be at the mercy of what a plugin stores.

When a codec format has a few names, like MPEG-4 Layer 2  is one,  MPEG-4 Visual  is another.  Then the GUI shouldn't have to present just what is stored in the "video compression format" field of the plugin. It may be the ugly name!  Or,  it may not be as comprehensive a name as the neat- AVC,H.264

And once the GUI has that facility to store its own, then I don't think it's ugly to use it to store its own form of names, for known plugins.

I meant the GUI shoud not present its own information. It can present its own presentation of the data from the plugin (that is, it is free to call Part 10 AVC or whatever). If the plugin stores the format info (which does not have to be a string, i.e. it does not have to be stored in the form of "MPEG-4 Part 10" etc.), then the GUI can display it in some way. But again, there can be plugins with "unknown" formats.

QuoteRegarding your screenshot, I suppose the right hand side is the consistent one..
Supposing ugly names like the ones with Layer in them, are moved out of the GUI..
Looking at that display, of video audio and container format in your screenshot
Assuming that ugly names were removed.
The menu would still be chunky.
Why not then use parentheses?
in the form-   codec format(codec implementation)

Because that's excactly the problem this is trying to address. :) Otherwise this topic would not exist, because we could just be happy with the way it is currently.

Like I explained many times, the problem with the parentheses is that people have no idea what they are supposed to mean. It is explained in the documentation, yet people still have no idea what they mean. They will never get it until it's explicitly said in the GUI. The current method is simply unclear, cryptic, not understandable.

QuoteI think Container format seems more meaningful than output format.

As they're all outputs as much as each other, and there is no one format, there's a format for video, format for audio, format for container.. so container format seems better)

It isn't, because not only container formats are listed in the menu.

QuoteWhen a program has a chunky GUI, then perhaps many instances could eat more memory on a program with low memory. I don't know if it's exactly a RAM issue or just strongly related or correlating with RAM, but i've seen one or two laptops where after a certain number of programs are open, another won't open or will but with a menu not opening or not showing.  I generally prefer programs with smaller footprints.

The memory impact of showing a couple of extra labels in bold font is more or less zero. Unless you want to run Avidemux on ZX Spectrum with 16 kB RAM, it makes absolutely no meaningful difference.

Both menu methods have their advantages. 

A cryptic/concise menu - using Parentheses(done right) is quick to navigate through.

A verbose/descriptive menu is ideal for somebody that doesn't know the parenthesis notation, and somebody who wouldn't go to the trouble of finding out. When they have a problem they'd benefit from a good idea of some  of the terminology, which a verbose menu presents them with nicely.

Regarding verbosity, to write Format and Encoder in each menu item on separate lines, would double the size of the menu, and with any  spacing, and/or larger text , and/or  formatting done for  each menu item, would further increase the size of it.


Regarding the GUI storing its own information, I mean storing its own presentation of the information from the plugin. You're fine with the GUI presenting it its own way, I just had in mind storing in a variable, which I doubt you'd object to, so I  think we mean the same kind of thing there.
For known plugins, the GUI could present the codecs in a consistent fashion.

As far as using the program is concerned,  you say, most people wanting, say, xvid, would just look for xvid. Well, they'll see Xvid just fine in the current system with parentheses. Particularly as the menu is neat and concise.

A big problem  whose solution seems simple and has no obvious downside that I can see, is the Parenthesis notation that is inconsistent. That can even confuse technically minded people. 

-------------------------------------------------------------
As to the GUI and memory issue.
I don't have screenshots at hand so it'd be hard for you to relate to this having not seen it, but
It might be more the fault of other apps like browsers, but there is apparently an issue with GDI objects that might explain how  i've sometimes seen some apps won't open, and I can squeeze out a few more instances for other apps with less GUI.
Here is somebody running into that.
http://www.techsupportforum.com/forums/f10/500-mb-free-memory-but-cant-open-any-window-or-program-132287.html
and another
http://superuser.com/questions/407943/what-resource-am-i-lacking-causes-notepad-to-be-missing-menu-or-programs-to-no

I would guess that large non standard looking GUI objects like in your screenshot would exasperate that.

There's also the issue of the Window needing to be very big.  Currently, with the Parenthesis notation, the window needn't be huge. But, with a more verbose menu system, it may be.

When i've tried it, (and I don't currently have screenshots at hand) I've found using SUPER to be a frustrating experience e.g. not being able to see the whole window.. not being able to make the window smaller
http://2.bp.blogspot.com/_g_5DfKuBHzc/RZtw3SxPm2I/AAAAAAAAAAM/NDWDQ8DQ9_I/s400/super_mpeg4.jpg

I imagine that large Fisher Price like GUI objects would exasperate any issue like that. Programs with that kind of design may not be easy to resize to any size.. again you may not relate to that and I don't have screenshots to hand or knowledge of why it's sometimes like that.
--------------------------------------------------------------


That said, I do see the tremendous advantage to the type of GUI in your screenshot, to a large group of people, as a teaching tool. But, I see disadvantages too..

An application with 5 menus and 2 columns, (or 5 menus on the left, 5 list boxes on the right) showing compatibility, would also show people the structure and terminology., and if they ever needed or wanted to make sense of the parentheses notation in avidemux, they could play with that 5 menus 2 columns app/screen.  Use of that app would actually give them a much better understanding than that big redesign of the avidemux GUI.

Supposing the Parenthesis notation was done correctly and consistently

And a note is added re the notation. See Right hand side pic below where I added a note regarding notation.

Imagining that it had the note -and- was done correctly and consistently-

Is it really so difficult for people to know that the notation is codec format(codec implementation), that it justifies a menu that repeats the fact with every menu item like pic in the screenshot at the top of the thread on the right hand column?

(https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fi46.tinypic.com%2Fychg8.jpg&hash=b7ccd0ee474ae375263dc413ff674deba793c6c6)

And as you say, people that want Xvid for example, wouldn't care about codec format.  Fine. Even in the current system with inconsistent parenthesis notation, they'd just look for the term Xvid. A big advantage to consistent parenthesis is that reasonably technical users and maybe most users, would understand the structure better, and at relatively minimal cost. A tiny bit more screen real estate, and the GUI change is the most minimal one of any alternative.

QuoteI don't have screenshots at hand so it'd be hard for you to relate to this having not seen it, but
It might be more the fault of other apps like browsers, but there is apparently an issue with GDI objects that might explain how  i've sometimes seen some apps won't open, and I can squeeze out a few more instances for other apps with less GUI.
Here is somebody running into that.
http://www.techsupportforum.com/forums/f10/500-mb-free-memory-but-cant-open-any-window-or-program-132287.html
and another
http://superuser.com/questions/407943/what-resource-am-i-lacking-causes-notepad-to-be-missing-menu-or-programs-to-no

I would guess that large non standard looking GUI objects like in your screenshot would exasperate that.

I'm 99.9999999% sure this is really a non-issue. Avidemux uses exactly this kind of menu design in the Video Filter Manager and other dialogs, for example, and I haven't seen anyone reporting any problem with this. The difference with a couple of labels added may be something like a kilobyte or so... It is really a non-issue. It might be an issue on computers from the 1960's, but nobody uses them anymore.

QuoteThere's also the issue of the Window needing to be very big.  Currently, with the Parenthesis notation, the window needn't be huge. But, with a more verbose menu system, it may be.

It doesn't have to be. That's why I posted the comparison. As you can see on the picture, the new version is not much bigger than the original version. A little wider, that's all. The height is the same. Not a big problem for the whole window.

QuoteI imagine that large Fisher Price like GUI objects would exasperate any issue like that. Programs with that kind of design may not be easy to resize to any size.. again you may not relate to that and I don't have screenshots to hand or knowledge of why it's sometimes like that.

The GUI objects in the screenshot are huge not because of the double-line entries, but primarily because it's taken on Ubuntu, which, just like any GNOME-based Linux distribution, uses huge GUI objects and huge fonts (just compare the original "slim" version on the left with your screenshot from Windows XP). As you can see on your screenshot, Windows XP uses much smaller widgets and fonts, so of course the version I am suggesting would be much smaller on MS Windows.

QuoteAn application with 5 menus and 2 columns, (or 5 menus on the left, 5 list boxes on the right) showing compatibility, would also show people the structure and terminology., and if they ever needed or wanted to make sense of the parentheses notation in avidemux, they could play with that 5 menus 2 columns app/screen.  Use of that app would actually give them a much better understanding than that big redesign of the avidemux GUI.

Actually, this is what I would call big redesign. :) Anyway, I am afraid 5 menus would be too much and people would find it painful to use.

QuoteSupposing the Parenthesis notation was done correctly and consistently

And a note is added re the notation. See Right hand side pic below where I added a note regarding notation.

Imagining that it had the note -and- was done correctly and consistently-

Is it really so difficult for people to know that the notation is codec format(codec implementation), that it justifies a menu that repeats the fact with every menu item like pic in the screenshot at the top of the thread on the right hand column?

Anything is better than a user who has no clue. Your suggestion might explain it to them, but I'm not sure. Still, making these two labels completely separate would be a complete, 100% clear solution.

QuoteAnd as you say, people that want Xvid for example, wouldn't care about codec format.  Fine.

That's not fine. :) The fact that they don't care only means they have no clue. So the program must give them the clue.

QuoteEven in the current system with inconsistent parenthesis notation, they'd just look for the term Xvid.

This means that what they want to select is the encoder. So an alternate version with a simple single-line menu could then look like this:

(https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fimg854.imageshack.us%2Fimg854%2F3797%2Favidemuxavboxnew.png&hash=1174c2337803cf00461799c8299504662150f78c)

Where the format at the top of each section would just be shown automatically based on the encoder or muxer selection. This way, the format would be there just for information. This version would also solve the problem with both your suggested version and my suggestion at the top: the format is the primary information. And then there is the Configure button, which would logically mean "Configure the format". But you configure the encoder, not the format. So now the Configure button is right next to the encoder.

On the other hand, sometimes people want to select a format. When they encode MPEG-2 video, they are looking for "MPEG-2", not for "mpeg2enc" or anything like that. When they want to encode the audio to MP3, they are looking for "MP3", not "LAME". I am afraid this would eventually lead to inconsistent, illogical and nonsensical naming in the encoder names again, to make it "easier" for the users... So I'm not sure this would be a good solution.

Now for your idea with 5 menus, if we apply it consistently to the Output File section, too, where we can select a muxer (unfortunately, there can be several muxers for the same format, like the two MP4 muxers in Avidemux 2.6), it would look like this:

(https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fimg99.imageshack.us%2Fimg99%2F3705%2Favidemuxavboxnew2.png&hash=46d59609a3f696b5cc7193460164ff00dc0fe43a)

I think looks a bit too complicated... And the user could be confused ("Where's my Xvid encoder?" "You have to select the MPEG-4 Visual format." "Oh, how am I supposed to know that?")

My mention of  5 menus , that wasn't for this but for a compatibility checker with 2 columns, and would double up as a good teaching tool. Such an app would teach more than your GUI or my note, but indeed a lot of design would be involved for that.
I'm advocating adding the note and correcting the parenthesis notation making it consistent(while ensuring that the menu is still neat, not ugly).

Now you mention the filters dialog, .I see you don't have in mind some clunky foreign looking Fisher Price style thing..  that's good..
It's not a drop down menu though, and 3 of those list boxes wouldn't all fit in  unless they were made small and with a scroll bar(hellishly tedious to use!). So i'm not sure what Windows object you have in mind. Maybe a drop down menu can be used and an item can be on 2 lines. But not seeing the object you'd use, it's unclear what your design would look like, other than surely it'd be twice the size with 2 lines per menu item.

Compare the number of items that fit into an area of each. The list box in the filters dialog, and the drop down menu.
(https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fi45.tinypic.com%2Fa3fv9c.jpg&hash=6ae626827b60436e51993e35d67c7118806d2bc7)


Much easier and quicker to locate an item in the current design or current design with the note and corrected parenthesis notation, than in a listbox full of items and a scroll bar.

Who are the idiot users that might not understand which is which in that
"codec format(codec implementation)" pic on page1 of this thread?

To have run into this program, and to remember the name of this program "avidemux"  requires a certain level of technical ability, significantly more than the average person.

A week ago I didn't know there were "codec formats"/"video compression formats" and "codec implementations"..  and those ugly names, until you and styrol kindly enlightened me and perhaps others including other future perusers, in the recent discussion on that and other things related to the subject.

But, using a GUI that had that note "codec format(code implementation)" would've alerted me to what those options were, as would your GUI.

When I look at the questions asked in the forum,  my intelligence is low enough that all the questions I look at look like intelligent questions(I wouldn't be able to answer them, but I mean just making a judgement anyway. They look like people that are technical enough to know how to ask a question and follow an answer).  So i'm left wondering where the people that wouldn't understand that note would be.

You could cater to people like Super Greg with one eyebrow, but do you really want such people using your program? There's a cost in catering to them, and they, like the average person in the world, wouldn't remember the name of the program "avidemux". The name is too cryptic and technical sounding.

QuoteMy mention of  5 menus , that wasn't for this but for a compatibility checker which would double up as a good teaching tool. Such an app would teach more than your GUI or my note, but indeed a lot of design would be involved for that.

Well, I can't see the purpose... The compatibility between container formats and encoders is understandable, and may be a good idea. But why 5 menus? I don't think there would be any added value compared to just showing the format/encoder info. It's the same thing, just with a more cluttered GUI. You only need 3 menus for compatibility with container formats.

QuoteIt's not a drop down menu though

It isn't, but drop-down menus are basically the same.

Quote3 of those list boxes wouldn't all fit in  unless they were made small and with a scroll bar(hellishly tedious to use!)

Why 3 of them? That's why it is a drop-down box - only one at a time is shown, and only on request.

Besides, those 17 encoder items comfortably fit on my screen as two-line items even in the huge Ubuntu GUI style that's 2x bigger than the Windows XP theme.

QuoteCompare the number of items that fit into an area of each. The list box in the filters dialog, and the drop down menu.

The menu in the Video Filter Manager intentionally uses huge spacing between the elements, exactly because there is a scollbar, so space is not a constraint. Of course, in a drop-down menu, the spacing is much smaller, as you can see on the picture.

QuoteMuch easier and quicker to locate an item in the current design or current design with the note and corrected parenthesis notation.

Well, in my opinion, the formatted design on the left (the filter manager) is much easier to scan. Exactly because it uses bold headings, descriptions, and the sections are visually separated. The design on the right is just a single blob. When I want to add "MPlayer resize", I can see it immediately on that picture. When I want to add libavcodec MPEG-4... It takes me a while to find it.

QuoteWho are the idiot users that might not understand which is which in that
"codec format(codec implementation)" pic on page1 of this thread?

Well, I would call them "victims" rather than "idiots", because they have just read way too much nonsense about these things on the web. This is the biggest confusion in the history of multimedia, and possibly in the history of computing. No wonder so many people are totally confused about these things.

Now, the reason why I started this whole thread (initially in the A/V sidebar suggestion (http://www.avidemux.org/smf/index.php?topic=8874.0) topic which is now broken after the forum software change and without the picture) was because I have been reading this forum since 2002. And the fact that people have no clue what these menus mean is not something I just made up. I am not guessing here. I know. I have been reading this forum for 10 years. And not only this forum... Way too many people simply do not have a clue what the notation means (remember: it's not just the notation per se, but the whole terminology, and I am not talking only about improving the A/V section, but also various other windows in Avidemux). So many discussions would not have existed, so much explanation would not have been necessary, so much bandwidth would have been saved in all those years. If the GUI would have included these two short labels. That's the only reason why I would like to suggest a GUI improvement, because anything else than a GUI improvement (like explaining things in the documentation) does not... well, improve the GUI. That's proven by 10 years of experience.

QuoteYou could cater to people like Super Greg with one eyebrow, but do you really want such people using your program? There's a cost in catering to them, and they wouldn't remember the name of the program "avidemux". The name is too cryptic and technical sounding.

Well, as I said, I think Avidemux should only be used by people who know what a compression format, encoder, muxer and container format is. If they don't know this, they should use something else because this program is based on these things. Multimedia is based on these things.

Now, if Avidemux directly labeled encoder as "encoder" and format as "format", only these people would use Avidemux. Because they would appear instantly, automatically just by using Avidemux. Ignoring these two labels is impossible.

For the Avidemux name... Well, yes, it might have been a mistake. I admit I voted for keeping it 9 years ago or so... It might not have been the brightest idea.

One more thing...

Quote from: garin on June 25, 2012, 12:01:38 AMA week ago I didn't know there were "codec formats"/"video compression formats" and "codec implementations"..  and those ugly names, until you and styrol kindly enlightened me and perhaps others including other future perusers, in the recent discussion on that and other things related to the subject.

But, using a GUI that had that note "codec format(code implementation)" would've alerted me to what those options were, as would your GUI.

When I look at the questions asked in the forum,  my intelligence is low enough that all the questions I look at look like intelligent questions(I wouldn't be able to answer them, but I mean just making a judgement anyway. They look like people that are technical enough to know how to ask a question and follow an answer).  So i'm left wondering where the people that wouldn't understand that note would be.

You came here and asked. People come here and ask what the GUI means (or they don't even ask directly, they just don't know). Yes, they may get the answer, they may even understand it. But the fact that a user comes here to ask what the GUI means suggests that the GUI is not good. If the GUI was better, they would not have to come here. A good GUI usually does not need an explanation, especially if it's as simple as the Avidemux GUI.

Here are some pictures of my screen, 1024x768 as you can see..
and   start menu is on the side so more room top to bottom.
http://i48.tinypic.com/1qshll.jpg
http://i47.tinypic.com/2u7boz9.jpg
http://i47.tinypic.com/zxwd9w.jpg

A menu with 17 items + the chosen item which is 18 items. Takes up  240px or 75mm
as the pictures with rulers in them show
That's not too big, and it's a menu so it collapses back too.
That's 30% of the length of the screen.

The list box with 2 lines per item and formatting,  and 18 items. Takes up 540px or 170mm
http://i46.tinypic.com/2n7matl.jpg
That is over double the length of the current menu
And that is 70% of the length of my screen.

And in your design, it'd be because of redundancy, lots of repeated information in the menu. Constant repetition of "Codec Format"  "Encoding", so each item takes 2 lines rather than one.

Not to mention, the width difference. The 2 item one listbox, is twice the width !
http://i49.tinypic.com/9id1q9.jpg

cont..

For a compatibility checker app, 5 menus vs 3 menus.. , well, you could have an button for advanced view with 5 menus.  It provides a better understanding of containers and codecs.
This container supports these formats which support these codecs.

Quote from: JM
drop-down menus are basically the same.

A drop down menu is not the same as a list box.  If you know what I mean by drop down menu and you know what I mean by list box, then the difference is obvious, particularly in terms of space.  The current one has drop down menus. The filter dialog has a listbox.
When a drop down menu is closed, e.g. the one used currently in avidemux, it takes up  on my screen about 18px in length top to bottom,  or 5mm. That's 2.3% of the length of the screen.  It displays just one item when it is closed   A listbox just displasy all its items, it doesn't collapse.  The one in the filter dialog which may be like your one with 18 items takes up 70% of the length of my screen. Big difference!

Quote from: JM
there is a scollbar, so space is not a constraint. O

Notice that with a drop down menu that is written in a compact way, doesn't repeat itself with "encoder" and "codec format" for every item,  no scroll bar is necessary.
You can open it up and find the string e.g. xvid, that you are looking for, without having to scroll around.

And if you did have to scroll, how would you order it?  alphabetically by codec format, or alphabetically by encoding? And it wouldn't be instantly obvious either as the first letter of each item is neither of those, but the redundant info "Format:" and "Encoder:"  And a side point with that, is that I don't even think that naming is that good. Video Codec format or Audio codec format,  are better terms though they wouldn't even fit into your one big as it is.  One problem with the term "Format" is there are 3 formats.. and if people start using just the word "Format"  then it's not necessarily clear what they mean.

Infact in an earlier thread
http://www.avidemux.org/smf/index.php?topic=10730.msg57668#msg57668
When you said "format", I on first reading , due to my ignorance at the time, didn't realise you meant video compression format, in that instance. The word "format" alone is not such a good term. Hence i've always said, video codec format, container format, audio codec format.   And while I note you're not sure people will understand a notation described as
codec format(codec implementation) ,  or video codec format(video codec implementation) e.g.. it does encourage more specificness in terminology.

Quote from: JM
the fact that a user comes here to ask what the GUI means suggests that the GUI is not good. If the GUI was better, they would not have to come here.

Well a problem in the current GUI is it blurs codec format and codec implementation.
Of course that's not understandable!

They are not necessarily confused just by the GUI. It's the GUI combined with the technicalities, that causes confusion. In this case the GUI presents the technicalities in a blurred funny way that is naturally confusing.

A good GUI should be many things..  It should be likable.. easy to use, quick to navigate..

Shouldn't take up an unnecessary large amount of space on the screen due to lots of redundant info!

Quote from: JM
it is a drop-down box  - only one at a time is shown, and only on request.

ok so when you say drop down box, you mean what I call  drop down menu.. ok.

as an example, you pointed me to a list box (Filters). Hence all my screenshots of them, comparing sizes. But listbox is -not-  really what you meant then.

But a list box like that may be the same size as a drop down menu that uses 2 lines per item.  I'm not sure if such a thing exists, but it'd be as big, when open.
So of course, the problems related to size, still apply to that..
But I note that you don't mean quite like in filters..

Quote from: JM
The menu in the Video Filter Manager intentionally uses huge spacing between the elements, exactly because there is a scollbar, so space is not a constraint. Of course, in a drop-down menu, the spacing is much smaller, as you can see on the picture.

OK so in your terminology, when you use 2 lines for an item, you call it a drop down box and not a drop down menu.
Noted..

Quote from: JM
When I want to add "MPlayer resize", I can see it immediately on that picture. When I want to add libavcodec MPEG-4... It takes me a while to find it.

Well yeah, I can tell you why.. and  I think you know why!

Mplayer resize is -there- in that big menu in the filters dialog.

In the drop down menu in the avidemux screen that lists video codec formats and implementations, you will not find libavcodec MPEG-4 because it isn't there.
http://i47.tinypic.com/20p3lgj.jpg

I can scan that drop down menu and straight away see, that libavcodec MPEG-4 is not there

What I don't see straight away, and  -too long- I see, is that avcodec is there, and I guess that's libavcodec

If that tiny bit of screen one had to scan had libavcodec in there i'd have seen it quickly, and you might've seen it quickly too.

That wouldn't require the menu to be twice as big, and e.g. take up 70% of the screen!

And if it required a scroll bar, then it wouldn't be that quick to find. Even putting aside the question of how in your design, you'd sort them..

Quote from: garin
Who are the idiot users that might not understand which is which in that
"codec format(codec implementation)" pic on page1 of this thread?

Quote from: JM
Well, I would call them "victims" rather than "idiots", because they have just read way too much nonsense about these things on the web. This is the biggest confusion in the history of multimedia, and possibly in the history of computing. No wonder so many people are totally confused about these things.

well, as I said, if i'd seen that note, as well as a consistent parenthesis notation, then i'd know exactly which is which.

People aren't necessarily confused by reading nonsense..   But from not knowing the technicalities.

I remember when  I didn't know that while a DOC file or TXT file has one format,  a Video file, talking in terms of format  isn't necessarily clear. As they have a container, a video codec, and an audio codec.  That the container is  a format, and that the video codec and audio codec, have a format and implementation.  I didn't know there were even 3 components until I had problems with a video and I looked at it in mediainfo.exe   or until I saw avidemux which made it plainly clear that there are 3 components.

Had the GUI then been with my suggested amendment, or your version which is more bloated, then i'd have seen breakdown further. That video codec has a format and implementation, likewise audio codec.

See it's the technicalities and GUI coming together and people see it and are confused, but that can be because not being familiar with the technicalities.
Now you blame the GUI..
But actually.. if they understood the technicalities, then a GUI is not going to confuse them as to the technicalities.

I think with the current GUI, which doesn't present the technicalities well, and doesn't use a consistent notation..  Somebody that understands the technicalities, will not be confused by the GUI.

Somebody that doesn't understand the technicalities, will simply still not understand the technicalities beyond that there are 3 components.  They won't really see the 5 components.

Infact, your idea of presenting it, while being more than twice the size, so very bloated.. and perhaps involving a scroll bar so not as quick to use.. The notation itself that you use,  has most of the "uglyness" as my one.

Most of the uglyness of  A(B)  is actually, in the fact that the A part can have multiple names
AVC,H.264(B) or
Mpeg4-Visual (B)
'B' is just one implementation.

You're still listing the same uglyness(The A when A has multiple names)..just you list it minus the (B), moving the B elsewhere, though B is the part that isn't ugly or rather isn't so confusing to somebody that doesn't know!

One problem with the A,B,C,D(E)   is somebody might not know that A,B,C,D is a notation we are both using for alternative names. See many times when people mean Or, they use '/' 

though we both might agree that something like Mpeg-Layer 2 or Mpeg-Layer 10 is too ugly and is better left in documentation.  But A,B,C,D prior to (blah) is still ugly.  And if not ugly, then confusing to somebody that doesn't know the technicalities.

I don't think A,B,C,D(E)  is much less confusing than A,B,C,D
If somebody isn't aware of the technicalities, they'll just look for what they recognise.
e.g. Xvid

and if they don't understand A,B,C,D(E) they won't understand A,B,C,D. They certainly won't understand the difference between a format and an encoding.   And if they did understand the difference between a format and an encoding, then even then, some might not understand your A,B,C,D notation.. or A,B,C,D(E) without a note about the A,B,C,D notation. 
But if they don't then maybe they don't want to. As they could easily see that and go on wikipedia and they'll see they're alternate names. And if they can do that then they'll get the easy bit, the (E). The which is which bit given the note.

Quote from: JM
For the Avidemux name... Well, yes, it might have been a mistake. I admit I voted for keeping it 9 years ago or so... It might not have been the brightest idea.

I'm saying that the kind of people that'd fine the name avidemux too technical and then not remember it for that reason, e.g. the average person in the world, are the kind of people that aren't going to understand the technicalities even on a plate and don't care to.  And if you lower it to their level, then everybody pays a price! The name avidemux is ok!

Making it more bloated to cater to super greg.. that wouldn't remember a name like avidemux, isn't a good idea even if it wasn't called avidemux but was called something that super greg  can remember!

QuoteHere are some pictures of my screen, 1024x768 as you can see..

The list box with 2 lines per item and formatting,  and 18 items. Takes up 540px or 170mm

That is over double the length of the current menu
And that is 70% of the length of my screen.

You ignored everything I said about the spacing.

I said the spacing in the VFM dialog is intentionally big because in the separate dialog, vertical space is not a (big) concern. Again, drop-down menus use different spacing.

When you apply the combobox spacing to the VFM-style formatting, you get something like this:

http://img717.imageshack.us/img717/4716/vfmcomboboxspacing.png (http://img717.imageshack.us/img717/4716/vfmcomboboxspacing.png)

In other words, the 17 encoders in the single-line menu in your screenshot take 222 pixels vertically, while in the double-line design, they would take about 354 vertical pixels. 354 vertical pixels. Big deal, I guess. On today's screens.

QuoteNot to mention, the width difference. The 2 item one listbox, is twice the width !

::)  ::)

Of course it's twice the width when it contains twice as much text.

QuoteAnd in your design, it'd be because of redundancy, lots of repeated information in the menu. Constant repetition of "Codec Format"  "Encoding", so each item takes 2 lines rather than one.

As I repeatedly said, that's the real disadvantage. Yes. It is a bit stupid. On the other hand, in the pictured formatting, the "Format:" and "Encoder:" labels are toned down so that what you really see when you open the menu (I have a working prorotype) is the format and encoder names.

But yes, the repetition is a disadvantage. But again, the idea is what I considered important in that picture, not whether is says "Format:" on every line. The "Format:" and "Encoder": labels do not have to be there in the menu, for example, the whole menu could just be labeled "Encoder", the encoder would be the heading (like x264), and then in the small explanation below it could say something like "H.264/MPEG-4 Part 10 (AVC) encoder" or whatever... The picture was not about any exact form of labeling, but about this whole idea.

Besides, all other options discussed in this thread have their own disadvantages, too. And we haven't even mentioned other possible options, like a separate dialog, which would solve all space, MPEG-4 naming or repetition related problems (I did not mention this option as the obvious disadvantage, having to click at least twice to configure encoders, was in my opinion enough to dismiss the idea right away). The problem is that there are no perfect solutions to this problem I'm afraid. Only imperfect options. But I still think that even an option with a slight disadvantage can be still much better than what we have now. I don't insist on exactly the design (with that repetition) that I showed on that picture. Let's not get stuck in pixel paralysis and implementation details. Again, I am talking about the general idea here. That was the reason why I started this whole thing, hoping that I could perhaps get some feedback whether the whole idea of consistently storing this information in the plugins and using it consistently throughout the whole GUI is OK or not (and if it is, if there is a chance someone could implement it and how, and then we could start talking about the details).

QuoteFor a compatibility checker app, 5 menus vs 3 menus.. , well, you could have an button for advanced view with 5 menus.  It provides a better understanding of containers and codecs.
This container supports these formats which support these codecs.

Again, I cannot see any reason for this. First, formats do not support codecs. Codecs support (coding) formats. Container formats do not support codecs either. Container formats can support A/V formats. Second, having 5 menus is exactly the same thing as listing the format and encoder separately, either in the repetitive two-line menus, or in the separate label (see one of my screenshots above), or even in the secret notation with parenthesis etc. "MPEG-4 AVC (x264)" means the format is MPEG-4 AVC and the encoder is x264. Which immediatelly tells the user that the x264 encoder is compatible with the AVC standard. Having two separate menus for this just means a cluttered GUI for no reason, no added information.

QuoteA drop down menu is not the same as a list box.

It's not the same thing, but from the GUI toolkit point of view, it basically is (in some toolkits, it is implemented using exactly the same element). It does not matter too much whether you display formatted text in a list or in a drop-down menu, at least not here.

QuoteI don't even think that naming is that good. Video Codec format or Audio codec format,  are better terms

These terms are rather misleading, and probably, considering the things written above, based on a misunderstanding. They also tend to suggest that codecs have or define their own format, while in reality, codecs usually implement one of the existing formats.

Furthermore, the terms are nonstandard and unique. I can't see any reason for inventing new terms nobody else uses, especially when the existing terms are much better.

What it really is is a format of the video/audio bitstream. It can be a video/audio compression format, or the stream does not have to be compressed at all. So generally, it is a coding format, the way of coding video and audio streams. That's why, for example, the MPEG or H.264 standards talk about "coding standards" when they're ereferring to the MPEG video compression formats. But generally, "video compression format"/"audio compression format" or even just "video format" or "audio format" is perfectly sufficient in this context (the term "standard" does not apply to all formats).

QuoteOne problem with the term "Format" is there are 3 formats.. and if people start using just the word "Format"  then it's not necessarily clear what they mean.

Nobody says just "format" without any context when they know what they're talking about. In Avidemux, when you have a big bold label "Audio", marking the whole audio section, and then a sublabel "Format:", then of course, what that label means is "Audio format". I really cannot imagine anyone who would think "Audio format" means "Container format" or "Video format".

QuoteThe word "format" alone is not such a good term.

Alone it's not. But it is not alone.

QuoteHence i've always said, video codec format, container format, audio codec format.

And while I note you're not sure people will understand a notation described as
codec format(codec implementation) ,  or video codec format(video codec implementation) e.g.. it does encourage more specificness in terminology.

Which would suggest that there are codecs like H.264, and then someone impletents these codecs in software products ("codec implementations") like x264. Actually, many people think that's the way it is. This would only confirm their twisted idea.

QuoteWell yeah, I can tell you why.. and  I think you know why!

Mplayer resize is -there- in that big menu in the filters dialog.

In the drop down menu in the avidemux screen that lists video codec formats and implementations, you will not find libavcodec MPEG-4 because it isn't there.
http://i47.tinypic.com/20p3lgj.jpg

I can scan that drop down menu and straight away see, that libavcodec MPEG-4 is not there

What I don't see straight away, and  -too long- I see, is that avcodec is there, and I guess that's libavcodec

If that tiny bit of screen one had to scan had libavcodec in there i'd have seen it quickly, and you might've seen it quickly too.

Well yeah, I can tell you why.. and  I think you know why!

Mplayer resize is -there- in that big menu in the filters dialog.

In the drop down menu in the avidemux screen that lists video codec formats and implementations, you will not find libavcodec MPEG-4 because it isn't there.

No, that's not why. Feel free to replace libavcodec MPEG-4 with Xvid or anything else in my example. It still stands.

QuoteMost of the uglyness of  A(B)  is actually, in the fact that the A part can have multiple names
AVC,H.264(B) or
Mpeg4-Visual (B)
'B' is just one implementation.

You're still listing the same uglyness(The A when A has multiple names).

As I said, we cannot change the ugliness unless we radically change the Avidemux window design, because regardless of the style, labeling, formatting or notation you choose, there is only place for one name. So once again: I don't care whether there's "MPEG-4 AVC", "H.264" or "MPEG-4 Part 10" written in that menu. I am fine with any of the official names. I just had to put something there when I made that screenshot. But that was really not the point...

QuoteI don't think A,B,C,D(E)  is much less confusing than A,B,C,D
If somebody isn't aware of the technicalities, they'll just look for what they recognise.
e.g. Xvid

And then they'll have no idea what they're doing and why. And then they'll come here asking confused questions.

Quoteand if they don't understand A,B,C,D(E) they won't understand A,B,C,D. They certainly won't understand the difference between a format and an encoding.

If it's labeled as "encoding", then they probably won't. They could confuse it with character encoding, for example. But when it's correctly labeled as "Encoder:", because the menu is about selecting and configuring an encoder (a piece of software), then they will understand it. Or at least they will not come here asking confused questions.

QuoteI'm saying that the kind of people that'd fine the name avidemux too technical and then not remember it for that reason, e.g. the average person in the world, are the kind of people that aren't going to understand the technicalities even on a plate and don't care to.  And if you lower it to their level, then everybody pays a price! The name avidemux is ok!

It's not about being technical or not. Avidemux was called Avidemux 10 or 11 years ago simply because originally it was just a tool for extracting an audio track from an AVI file. Hence the name, Avidemux. In 2002, it was clear that the name made no sense anymore, because Avidemux could do so much more than that. But some people (like me) thought that keeping the name would be a good idea because the program was already quite well known. When if fact, in 2002, only a handful of Linux freaks were really using it, so a name change would not have been a big problem. Changing the name in 2012, when it's several orders of magnitude more popular, would be much more problematic. It's not that anyone thinks the name is actually good I think. It's now just a series of characters. A, v, i, d, e, m, u and x. But that's what often happens with product names or company names, they lose the original meaning.

QuoteMaking it more bloated to cater to super greg.. that wouldn't remember a name like avidemux, isn't a good idea even if it wasn't called avidemux but was called something that super greg  can remember!

This isn't about catering to super greg. The first thing is making it correct. The current version says incorrect and confused things (again, not only in the A/V sidebar, but in related dialogs as well), and that's really the main concern.

I wouldn't care about all these choices at all: 2.5 and 2.6 are quite different and both are perfectly usable - and annoying. But that is due to it not remembering my choice for the next launch.