[MPlayer-dev-eng] [PATCH] switch audio delay keys

[Ivan Kalvachev]

2006/4/15, Diego Biurrun <diego at biurrun.de>:
> On Sat, Apr 15, 2006 at 05:42:13PM +0200, Ivo wrote:
> > On Saturday 15 April 2006 17:06, Ivan Kalvachev wrote:
> > > 2006/4/15, Diego Biurrun <diego at biurrun.de>:
> > > > On Tue, Apr 04, 2006 at 09:05:31AM +0200, Diego Biurrun wrote:
> > > > > After Uoti Urpala's mail I've stumbled over the fact that the keys
> > > > > that set audio delay are backwards from what is documented...
> > > > >
> > > > > man page:
> > > > >
> > > > >   + and -
> > > > >     Adjust audio delay by +/- 0.1 seconds.
> > > > >
> > > > > code:
> > > > >
> > > > >   { { '-', 0 }, "audio_delay 0.100" },
> > > > >   { { '+', 0 }, "audio_delay -0.100" },
> > > > >
> > > > > So I suggest the attached patch to bring this in line with the
> > > > > documentation.  Increasing the delay with '+' and decreasing it with
> > > > > '-' is the only sane way...
> > > >
> > > > Applied.
> > >
> > > Did you ever make the effort to read the discusion before going ahead
> > > and commit that?
> >
> > Not speaking for Diego here, but I don't think it really matters which way
> > around the keys are bound. You will probably press the wrong one 50% of the
> > time anyhow ;) Maybe more.
>
> Anyway, let's define what is needed here:
>
> - a certain behavior of the relationship of audio and video during
>   playback, something that should be consistent with the word delay
> - a certain behavior of the command line option
> - a certain behavior of what is shown on the OSD
> - a certain behavior of the keys controlling audio_delay
>
> First of all this needs to be consistent.  By consistent I mean that
>
> - positive values on the command line should correspond to positive
>   values on the OSD
> - the + and - keys should behave as expected with regard to the numbers,
>   i.e. + should make the number increase, - should make it decrease
>
> This we have achieved right now.
>
> Then we have to decide what direction delay should be interpreted and
> adjust the code to match that definition.  Right now positive values
> mean that audio comes before video.
>

After some reasoning on IRC, I'm going to pass the modification.
I still don't like changing behaviour I am already used to... Only
because of wording issue.