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

[The Wanderer]

Ivan Kalvachev wrote:

> 2006/4/5, Uoti Urpala <uoti.urpala at pp1.inet.fi>:
> 
>> On Tue, 2006-04-04 at 19:16 -0400, The Wanderer wrote:
>> 
>>> To address Ivan's other original point, about "delay is something
>>> relative": this is true, but since the name is "audio delay" it
>>> is reasonable to expect that the audio is what is being delayed -
>>> and thus, that increasing the delay factor will make the audio
>>> come later. As things presently stand that is not the case.
>>> Additionally, the signedness of the argument to the '-delay'
>>> option (which sets the initial delay factor to something other
>>> than zero) is presently inverted from the signedness of the
>>> increase/decrease keys, so a change would have to be made in any
>>> case.
>> 
>> There are three directional things:
>> - whether audio or video is ahead of the other
>> - whether the "delay" setting is positive or negative (the value of this
>>   setting is displayed to the user when adjusting it at runtime and is
>>   also settable from the command line, so it's not just an internal
>>   detail)
>> - whether you get to this state by pressing '+' or '-'.
>>
>> The first one is kind of arbitrary relative to the others and
>> depends on the interpretation of the option name (but I agree that
>> "audio delay" sounds like positive values should make audio lag
>> behind video). However the last two have a natural relation: '+'
>> should correspond to positive values and '-' should correspond to
>> negative values. Currently it's the opposite.
>> 
>> Currently positive audio_delay means that audio comes ahead of the
>> video (contrary to the intuitive interpretation of the option
>> name). No one has proposed a patch to change this yet. The two
>> related patches posted so far are my patch that fixes a/v sync
>> adjustment when the delay value is changed at runtime (this is a
>> real bug, not just an user interface consistency issue) and Diego's
>> patch that makes the default keybindings use '+' for increase and
>> '-' for decrease instead of the opposite.
> 
> I think that now i get what is the problem.
> 
> The word "delay".
> 
> It is the word that implies negative values. I guess that the word
> delta or difference would be more correct.

I don't necessarily think so. I see it as referring to "the amount of
time by which the playback of the audio will be delayed" - and in
comparison with the time at which the video will be played, that is
obviously going to be a positive number. (I just woke up, but I think
this is a restatement of what you say just below.)

> If we talk about PTS, then then pressing "+" we make the audio pts
> bigger than video one, so A-V  is positive and audio is ahead of the
> video. However word delay implies that the audio is behind video thus
> negative....

I do not think that this is the case. One problem with it which I see
are the words "ahead" and "behind" - does that mean that the audio comes
before the video (thus, if you picture it as a line of objects moving
towards the future, the audio is behind in that line), or that the audio
comes after the video (thus, in the order in which you encounter the
audio and video as you move forward in time, the audio is encountered
second and so is considered "behind" - that is, this time the line is
moving towards the past)? The usage is ambiguous IMO.

I have been able to work around this for myself by carefully remembering
the word "delay", and specifically the phrase "audio delay" - which
means that "the audio will be delayed", that is, "the audio will be
moved into the future", and makes it clear (if not necessarily obvious)
which is intended.

IOW, I don't think that "delay" really implies "negative" to any
significant degree. "delta" and "difference" would be *less* clear to my
mind, since they - unlike "delay" - do not provide any information as to
which direction the change is in, which is precisely the thing which has
been difficult to handle from a user's perspective in the past.

> So... as of now the audio and subtitles are controlled by similar
> manner, with this patch the things go opposite, that would create
> only more confusion.

I agree that audio and subtitle time adjustment should probably be
handled in a consistent fashion, but I do support having the current
patch applied.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.