Closed GoogleCodeExporter closed 8 years ago
QBikal.
I've been thinking about this. I think the exhibited behaviour is acceptable.
I think your issue arises because we have a different workflow. In my case, I
would make multiple presets with the different process priority / multithread
settings. I wouldn't go into the presets window mid conversion process most of
the time.
Most of the time, if I go into the preset window, I expect the output folder to
change because I assume that the preset has changed in some way and that I need
to reload the settings and populate the main options screen. Can you be more
specific about your workflow?
Original comment by istoff@gmail.com
on 12 Jun 2010 at 9:05
Istoff,
If by acceptable you mean the issue is minor, I agree. However, I don't think
the behavior is desirable considering how easily the switch could go unnoticed
by those that don't expect it to change. There has got to be at least ten
thousand WinFF users, many of them unfamiliar with the interface and therefore
doing unexpected things. Changing the multithreading/priority preferences as
often as I do has got to be uncommon. I just don't see how making a change in
the preference window should cause the output folder setting in the main window
to change.
Why do I change the priority so often? Most often when I start encoding jobs I continue to use my computer. Sometimes only to entertain myself while I eagerly await my videos to finish, in which case I don't want my activities to slow the encoder. Other times, I am in no hurry for my videos to finish and therefore want my computer to be fully responsive.
Why do I change my multithreading settings? The answer is long and not really relevant but I will try to summarize. There are two reasons. First, parallelizing mpeg2 encoding only offers a modest performance improvement; at least that's my experience. Second, I have had issues in the past with codecs producing very noticeable visual artifacts and reduced compression ratios directly related to improper multithreading implementation. On my Core 2 Duo, I have found I can complete large batches of small files much faster (up to 60% faster) if I run two jobs at once, each with half the files/workload. Under those conditions, multithreading offers zero benefit because there is theoretically only one core available to each job. Providing no benefit, and the risk of codec inefficiencies and errors, I disable multithreading as a precautionary measure. Conversely, when I am running a single large job, I prefer multithreading enabled because it will cut down on run time.
I will clarify; I could easily workaround this output folder "behavior" if I could just remember to set the processor preferences first. It is only an issue for me when I make the change after selecting a new output folder.
Original comment by QBi...@gmail.com
on 13 Jun 2010 at 9:11
Okay.
Maybe when closing the presets window, it could prompt you to keep or discard
your custom folder. Shouldn't be too much of a problem either way.
At least both use cases will be catered for. Will do.
Original comment by istoff@gmail.com
on 14 Jun 2010 at 3:46
[deleted comment]
I don't agree. Most users don't set the preferences very often. The solutions
to it are to change when it was modified or all the time. If it only changes
when modified, then you have to type in a default when you just want everything
to go to what the defaults are. Which it's a personal preference of mine that a
program use everything the way it is in the preferences when you close (not
cancel) the preferences. I don't think it confuses a lot of people. It might be
pain or disappoint, but i think the other waty would really confuse people who
are trying to straighten things out.
a better way would be to put the priority as an option, instead of a
preference. Which i might do.
Original comment by bgg...@gmail.com
on 17 Jun 2010 at 12:43
Original comment by bgg...@gmail.com
on 17 Jun 2010 at 12:44
Original issue reported on code.google.com by
QBi...@gmail.com
on 27 May 2010 at 2:03