Wish-list: Additional options with drop down menus with most common settings.

[GoogleCodeExporter]

What is the expected output? What do you see instead?
Under "Additional Options," the fields Video Bitrate, Frame Rate, Width,
Height, Aspect Ratio, Audio Bitrate, Sample Rate, and Audio Channels should
all have drop down menus which allow the user to click on the most common
values. As of version 1.2, the user must reach to the keyboard and type the
values. 

What version of the product are you using? On what operating system?
1.2 on Windows Vista

Please provide any additional information below.
For example, Audio Sample Rate is almost always either 11025, 22050, 44100,
or 48000. The user should not have to type these values. There should also
be a blank value in the drop downs.

Original issue reported on code.google.com by QBi...@gmail.com on 27 May 2010 at 1:54

[GoogleCodeExporter]

Original comment by poipodec...@hotmail.com on 27 May 2010 at 5:29

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

After thinking about, some of them might, but not all of them. Especially video 
and 
audio bitrates. They are different for different codecs. The video bitrate can 
be 
tweaked to produce a certain file size, such as 700mb output file.  They would 
change 
depending on the preset chosen, which would burden preset authors. So many 
times they 
are specified in the preset, and prompting a user to use a universal set of 
values 
would be misleading.

Original comment by bgg...@gmail.com on 30 May 2010 at 4:28

• Changed state: WontFix

[GoogleCodeExporter]

I am new to reporting in bug trackers. If it is considered annoying when people
comment on issues marked as wontFix, I am sorry; I don’t know any better. 
Bggmtt, I
think I may not have been clear enough when defining drop down menu. I was 
referring
to the type which allows the user to either, enter a value by keyboard, OR 
select a
value from the drop down list. Did you think I meant the type which forced the 
use of
only predefined values? I do hope you reconsider this issue because I strongly 
feel
it would be convenient for users. I was considering what values would be most 
often
selected and I came up with these. This list is incomplete and could probably 
do with
some additions.
frame rate 15,20,23.976,24,25,29.97,30
video width 320,480,640,1280,1920
video height 240,360,480,720,1080
aspect Ratio 4:3,16:9
audio bitrate 32,40,48,56,64,80,96,112,128,160,192
Sample Rate 11025,22050,24000,32000,44100,48000
Channels 0,1,2

Original comment by QBi...@gmail.com on 2 Jun 2010 at 2:19

[GoogleCodeExporter]

QBikal,

I think the main issue is that it could complicate matters if implemented 
incorrectly.  Anything that 
complicates WinFF is normally frowned upon, however, your idea has merit.  I 
would encourage anybody else to 
find fault with the idea if its a particularly bad idea or not.  I can't be the 
judge.  

Regarding Matt's point, your example of audio bitrate is exactly the problem I 
believe Matt wants to avoid.

If the audio codec was AC3 or DTS for example, those bitrate figures would be 
inappropriate.  I am sure 
people with more knowledge of the subject field than me will be able to find 
other examples like 5.1 audio, 
etc, where the selections you give would not be suitable.  

The way I've used WinFF in the past is to delete the presets I don't need and 
have a limited set for my own 
purposes.  Because of this I rarely need to change the settings very often and 
so I don't mind typing it in to 
overrride when the exception occurs.

I am always willing to listen to a constructive argument and if make a good 
case, I am sure we could look at it 
as long as it makes WinFF better!

Regards,
Ian

Original comment by istoff@gmail.com on 2 Jun 2010 at 5:11

[GoogleCodeExporter]

any more feedback or shall we call this one closed??

Original comment by istoff@gmail.com on 12 Jun 2010 at 9:01

[GoogleCodeExporter]

Istoff,
       I can fully appreciate the desire to keep WinFF simple. I now also recognize the risk that this addition may cause undesirable complication. I work with a limited set of codecs and video/audio specifications, so I guess I just failed to realize how implementing this could get messy when taking into consideration all the various codecs and formats people use. For now I am happy with putting this topic on hold while I take some more time to consider the pros, cons, and alternative possibilities.

Original comment by QBi...@gmail.com on 13 Jun 2010 at 11:52

[GoogleCodeExporter]

QBikal.

If we can collectively agree on a solution to these and other problems, then 
lets do it!

I've been thinking of having 2 modes of operation.  Very simple, wizard based, 
stripped down easy mode and a hardcare mode with all options.  Posisbly if this 
ever came to be, one of these modes could solve your issue.

Will give the interface a look and see if this is practical or not.  Currently, 
I don't see an elegant solution which solves the problems to the problem I 
mentioned, namely stereo vs multi-channel audio.

Original comment by istoff@gmail.com on 14 Jun 2010 at 3:52

[GoogleCodeExporter]

The simplicity thing was my main goal from the very start. To be able to simply 
use ffmpeg.

I want to pick out a preset, drop some files, and click convert.

If you going to use the options, then have to know them. There is no such thing 
as simple ffmpeg options. They vary dramatically by the specific codec, the 
specific device, and the needs of the specific user. My ideas on a lot of 
options is to put them in the preset. That way a blackberry curve, is a 
blackberry curve, is blackberry curve. A PS3 is a PS3...

The main goal was batch conversion. That no matter which files i add to the 
batch, they all come the same.

I don't want to be mean, but i have to assert myself.

"If we can collectively agree"

If you could help with all things you post, it would be great.

That's the thing about opensource . Most people contribute to open source as a 
hobbie.

We do it for fun, to make the programs we use work the way we want them to.

I am not against new ideas. I've implemented a number of ideas from the forums, 
issues, and blogs out on the net. We will be implementing a couple of yours. 
When we get to it.

To expect us to jump right on your ideas is a crock. We are not being paid.

Original comment by bgg...@gmail.com on 17 Jun 2010 at 1:44

[GoogleCodeExporter]

Istoff,
    I have come to realize that my interests are not specific to this dropdown menu idea, but a more general desire to see WinFF's interface become more "on-the-fly" configuration friendly. Any idea involving improving the convenience of the override fields sound good to me because I am so often using them. Maybe I am trying to use WinFF in a way that it is not intended, but a lot of the time my target specs are for one time jobs that don't match any presets.  I can usually get away with choosing a preset which is close and then adding overrides, but this is not ideal. 
    This is how I envision the ideal interface to work. Everything from the output folder field up can remain exactly how it is (simple for users that are not interested in customization). In the "Additional Options" area, there will be gui controls to specify all the major parameters that end up being passed to FFmpeg. This includes file type, codecs, gop, etc. Less common parameters such as codec specific flags can be consolidated into "additional command line parameter" type fields. Upon selecting a preset from above, all the values in the presets command line string are parsed and the controls in the additional options area are filled with the specified values. The user can now see all the settings that the preset specifies. Furthermore, the controls now allow easy modification. Dropdown menus allow easy selection of common alternatives while not offering options that are incompatible with the selected codec and file type. After customizations are made, the user has the option to "save settings to new preset." Alternatively, the user could specify all parameters from scratch, without having to first choose a preset. To avoid invalid selections, some limitations will have to be imposed. For example, the majority of the audio specs controls are disabled (grayed out) until an audio codec is selected. Once a codec is selected, the rest of the audio controls are enabled and dropdown fields are populated with only valid options. If the audio codec is changed after audio specs are defined, their validity is evaluated. If they are still compatible with the newly selected codec, they are left as is. If they are no longer valid, the fields are blanked and/or the user is warned of the incompatibility. Preferably, a fully working configuration/preset could be defined from scratch using only the mouse.
     Now I am fully aware of the complexity of implementing such an interface. I also know that WinFF aims for simplicity. What I am unsure of is if this simplicity applies only to the user's interaction with the program, or the development side as well. If you want to keep the source code size and complexity to a minimum, then this idea is probably best forgotten. If you are willing to add a lot of weight to the project's code to implement this idea, I believe it can be done while still keeping the interface very simple to work with.
    Whether you wish to go all out and implement a wizard style interface, the interface I described above, or simply "intelligent" dropdown menus, at some point we will have to figure out under what conditions values are valid and not. I think it works something like this. The first factor to consider is file type. From file type your can determine compatible and incompatible codecs. Once an audio codec is specified, you know the valid sample rates and audio channels. Once rate and channels are known, then you have the valid bitrates for that combination. Video specs I don't think are as restricted to codec as they are to a target profile. For example, if you are aiming for DVD specs, then your options of frame rate, size, ratio, and bitrates are limited. If you want to offer only valid options in drop downs, WinFF will need to determine some info about the selected preset. For example, upon the user choosing a preset, WinFF scans the parameters and determines what codecs are specified plus any additional relevant info. It than uses that information to decide what valid alternative options are offered in the dropdowns. 
    I think there is a distinction that has to be made between valid values and appropriate values. I believe there will always be the possibility that an offered value is technically compatible with the other specs, but does not match the original intention of the preset. Bggmtt expressed concern that offering universal values would be misleading to the user. If this is a significant concern of his, I think we should consider his opinions about such a feature before planning too much into this. Yes, I realize that must sound a little funny after such a long ramble. :)

Original comment by QBi...@gmail.com on 17 Jun 2010 at 2:19

[GoogleCodeExporter]

You are not fully aware of complexities. I don't know of a video converter that 
is able to do all of that. Some have tried and came close, like media coder and 
handbrake, and they do a good job, but they are very complicated programs. What 
percentage average users can download and use Handbrake?

Your still missing the point of presets. A preset SHOULD NOT need alternative 
options. It should be ready to go as it is. If you need a conversion for other 
options, make a separate preset, and put it in the same category. Take for 
example the Ipod. Do you want to watch the video on the ipod's screen or on the 
tv output? There are separate presets for both.

"Maybe I am trying to use WinFF in a way that it is not intended, but a lot of 
the time my target specs are for one time jobs that don't match any presets."

You Absolutely Right. WinFF is to convert a Batch of videos, quickly, and 
easily. It's just a file converter. It's not a video editor.

"Bggmtt expressed concern ... I think we should consider his opinions about 
such a feature before planning too much into this."

Consider my concerns? If it has to do with WinFF, your stuck with them.

Stop haggling my project members!

Original comment by bgg...@gmail.com on 17 Jun 2010 at 12:58

[GoogleCodeExporter]

Bggmtt,
A very unfortunate thing happened and I wish to offer my apologies. I loaded 
the comments page earlier in the day BEFORE your post (Comment #8). I later 
composed my response to Istoff and submitted it without refreshing the page. 
The entirety of my comment was written without the knowledge that you had 
voiced your opinions on the subject. Had I noticed the comment and read it, I 
would not have persisted in my suggestions.
    I never considered myself to have any say in the development decisions of WinFF. I was only offering my opinions on possible alterations and seeing if the actual code writers found value in them. At one point, I decided to refrain from posting any more comments related to this issue. It was not until Istoff posted comment #5 and then #7 that I began to feel my addition input was being requested. Although I never expressed this directly, I wanted it to be known that I never considered myself to be anything other than an opinionated user. Any quotes of mine in which I appeared to consider myself more than that, where merely attempts to demonstrate that I was willing to contribute some of my time as a sort of consultant.
    I will not spend too much time defending my qualifications, being that they may only have been criticized out of frustration.  I have never collaborated on a project with others, but recreationally, I have done much programming in many languages. Some of my more elaborate projects involved fluid physics simulations using Smooth Particle Hydrodynamics, and firmware and drivers for a home made dot matrix printer. I am indeed aware of the complexities of software development. This is why I have an appreciation for the work that goes into a project such as WinFF. I only wanted to contribute as long as my suggestions where valued.

Original comment by QBi...@gmail.com on 17 Jun 2010 at 9:59

[GoogleCodeExporter]

Qbikal.

This isn't hostile community or closed to new ideas, but I also made the 
mistake of trying to turn WinFF away from what it does best.  I think there are 
other tools that you can use to tweak your settings (I've used Handbrake in 
these cases), but what I like most of WinFF is what Matt originally intended.  
Click, Convert, Done.

I haven't found an easy way to address your workflow because it breaks a core 
idea which is that presets are pre-determined and reused without modification 
for 99% of the time.  

I realize that I am repeating myself, but I'm posting this to reassure you that 
your comments ARE looked at constructively.  

I've been too busy engrossed in the World Cup Soccer (I've been to 2 games in 
Cape Town, as I live there) and as host country/city, I am enjoying being close 
to the action.  Development is currently on hold for at least a few more days 
from my side.

Regards all.

Original comment by istoff@gmail.com on 9 Jul 2010 at 8:04