The GUI for choosing container , compression format and codecs

[garin]

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.

[garin]

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?

[J. M.]

I 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.

MPEG-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.

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.

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.

In 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"? 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, 2, the pictures got deleted in these old topics, so it is now reposted here).

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

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

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.

Now that would be really nauseating. 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.

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.

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...

[garin]

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.

[J. M.]

libavcodec 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.

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.

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

ffmpeg - 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.

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?

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.

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".

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.

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.

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.

[garin]

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.

[J. M.]

yes 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.

one 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.

and 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.

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.

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).

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.

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.

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.

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...

[garin]

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.

[J. M.]

Is 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.

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?

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.)

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 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.

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."

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.

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.

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.

[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?

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.

[J. M.]

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.

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.

[garin]

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.

[J. M.]

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.

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.

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)

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.

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)

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

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.

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.

[garin]

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.

[garin]

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?



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.