mpv
mpv copied to clipboard
mpv-player
Terminal subtitles move upwards when jumping in audio-only media
Important Information
System Version: macOS 14.3 (23D56) Model Identifier: MacBookAir10,1 mpv version: git-2024-02-11-71598ca FFmpeg version: git-2024-02-11-66231e5
Reproduction steps
$ mpv --no-config foo.m4a --sub-file=foo.srt- Press
←or→(repeatedly)
Expected behavior
Subtitles should stay put.
Actual behavior
Subtitles are erroneously moved one line up in the terminal (mpv must be printing a superfluous \033[A)
Log file
N/A (Will supply if not reproducible)
Sample files
N/A (Any audio file and subtitle file should work)
Actually, it climbs regardless of seeking. Using plain "Terminal". Try this. ddd will be displayed one line too far up.
1
00:00:00,000 --> 00:00:01,000
aaa
bbb
2
00:00:01,000 --> 00:00:02,000
ccc
3
00:00:02,000 --> 00:00:03,000
ddd
eee
Not sure what you mean honestly but I get this which is what I'd expect.
In step three, notice how ddd overlaps the "Audio" line. This will continue to climb for all similar combinations of lines.
$ mpv a.wav
(+) Audio --aid=1 (pcm_s16le 2ch 48000Hz)
aaa
bbb
(Paused)
$ mpv a.wav
(+) Audio --aid=1 (pcm_s16le 2ch 48000Hz)
ccc
(Paused)
$ mpv a.wav
ddd
eee
(Paused)
In step three, notice how ddd overlaps the "Audio" line.
It doesn't for me. The file I was playing has file tags printed to the terminal so the audio line was not shown in the picture. Here's another screenshot with a different file with no metadata. Also shouldn't the AO line be right above the subs in your terminal output?
Must mean the position has already been displaced from the start. Let's see if someone else with macOS can reproduce.
@kasper93: Maybe this refactoring needs a re-refactoring. Some observations when the problem occurs:
- ANSI codes first go up, then down ("two steps forward, one step back"). Seems unnecessary (unless for clearing lines).
- ANSI codes get negative arguments from the prevailing arithmetic. I find no mention of this in any documentation.
- https://bjh21.me.uk/all-escapes/all-escapes.txt
- https://en.wikipedia.org/wiki/ANSI_escape_code
- https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797
- https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
- https://real-world-systems.com/docs/ANSIcode.html
- https://ttssh2.osdn.jp/manual/en/about/ctrlseq.html
- https://web.mit.edu/gnu/doc/html/screen_10.html
- https://www.xfree86.org/current/ctlseqs.html#VT100%20Mode
ANSI codes first go up, then down ("two steps forward, one step back"). Seems unnecessary (unless for clearing lines).
Repositioning cursor is free, but also it never jump back and forth. Read again.
ANSI codes get negative arguments from the prevailing arithmetic. I find no mention of this in any documentation.
line_skip, shouldn't be negative there.
Quickly looking, just a check is missing. Not tested.
diff --git a/common/msg.c b/common/msg.c
index 729fafa572..f675f6377d 100644
--- a/common/msg.c
+++ b/common/msg.c
@@ -224,7 +224,7 @@ static void prepare_prefix(struct mp_log_root *root, bstr *out, int lev, int ter
// Reposition cursor after last message
line_skip = (new_lines ? new_lines : root->blank_lines) - root->status_lines;
line_skip = MPMIN(root->blank_lines - root->status_lines, line_skip);
- if (line_skip)
+ if (line_skip > 0)
bstr_xappend_asprintf(root, out, "\033[%dA", line_skip);
} else if (new_lines) {
line_skip = new_lines - root->blank_lines;
Seems to work just great. I added some plain text to the print statements, and they showed both [A and [B being printed after each other in the same go. But this doesn't seem to happen with the patch, so probably just a side effect.
I did notice though that A: -00:00:00.000 is printed for one frame. But that's another bug report, I guess.