The GUI for choosing container , compression format and codecs

[J. M.]

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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

Even 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:



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.

[J. M.]

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:



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?")

[garin]

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

[garin]

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.



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.

[J. M.]

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

It's not a drop down menu though

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

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

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

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

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

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

[J. M.]

One more thing...

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

[garin]

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

[garin]

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.

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!

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.

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!

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

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

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

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

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.

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!

[J. M.]

Here 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

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.

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

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.

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

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.

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.

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

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

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.

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

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

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

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.

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.

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.

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.

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

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

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 then they'll have no idea what they're doing and why. And then they'll come here asking confused questions.

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.

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.

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!

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.

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!

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.

[douche]

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.