A/V sync UX is confusing

[baldurmen]

Hello,

I think the current Audio/video synchronisation UX is confusing. At the moment, the message shown is "very human" and tries to guide the user by asking clear questions (Audio is ahead of the video or Video is ahead of the audio).

I think that's not how users actually try to fix the A/V sync though and makes it overall more complex.

The way I (and since there's no simple way to do that in a browser, I also guessing others) try to fix A/V is by downloading the video locally and matching the audio and video in mpv or vlc. The result is a +$NUMBER or -$NUMBER result (in milliseconds, whereas Sreview ask for seconds...).

This doesn't match the questions asked by Sreview and I then have to figure out if +$NUMBER means Audio is ahead of the video or the other way around.

I think the interface would be much more simple and intuitive if it asked the user for that ±$NUMBER directly.

[sthibaul]

From the point of view of the web interface, the question is at least not ambiguous at all, while +/-number is ambiguous. But the reported diff should indeed be coherent with what mpv/mplayer/etc. use.

[baldurmen]

I agree the questions are not ambiguous, but my point is they are not relevant questions, since I don't feel that's the workflow people actually use when trying to fix A/V sync.

I'm not even actually sure the A/V sync logic in SReview is right?

This bit of code is used when you select "Audio is ahead of the video", and thus applies a positive value to the offset.

SReview/lib/SReview/Web/Controller/Review.pm

Lines 163 to 165 in 3c13087

	if($c->param("av_sync") eq "av_not_ok_audio") {
	$talk->add_correction("offset_audio", $c->param("av_seconds"));
	$corrections->{audio_offset} = $c->param("av_seconds");

Audio is ahead of the video means you have to delay the audio, and thus needs a negative offset instead...

[sthibaul]

At least when using the debconf website with chromium, I do get the correction in the right way according to the text

[baldurmen]

For future me and for the purpose of this bug, the right thing to do in SReview is indeed:

• audio is ahead for positive (i.e. +100ms) values
• video is ahead for negative (i.e. -100ms) values

[yoe]

Just to note here:

Yes, the current UX for A/V sync correction values is terrible. I have no idea how to make it more intuitive. If anyone has any suggestions, I'm all ears.

Mean time this is a case of "this sucks but at least it's there".

[sthibaul]

@yoe well, at least have the +/- number coherent with what mpv/vlc shows

[yoe]

@yoe well, at least have the +/- number coherent with what mpv/vlc shows

Isn't it? I thought it was. Yes, there's some discussion in this bug that suggests it might not be, but that seems inconclusive and I'm not sure what to think now :-)

If you think there is something that could be improved in that area then I would appreciate a clearer description of what you think the issue is (that is, a full observed vs expected behavior analysis). Otherwise I'm not sure I understand.