From 195aa7fd962d011922ec005a73bd4b66c953d9f6 Mon Sep 17 00:00:00 2001 From: Dudemanguy Date: Sun, 11 Feb 2024 11:25:06 -0600 Subject: [PATCH] DOCS/options: mention that sub-clear-on-seek can now break things This is technically due to the previous commits that made subtitle rendering more efficient by eliminating redraws, but working around this particular edge case is useless. The sub-clear-on-seek option was originally introduced in d5940fabcd6b477c72430c84e460975060807646 and specifically is a workaround for completely broken mkv files. There is no reason to use it otherwise. Because that option disables all duplicate checking and the previous commits rework subtitle rendering in the still image case to be dependent on keeping track of packets, the end result is that you will get the same line rendered multiple times. However the important case of broken mkv files with duplicate ReadOrder fields still work just fine with --no-video. So instead of bothering trying to make this option "work", just clarify that stuff can break since, again, there's no reason to use it other than as a workaround for broken files. --- DOCS/man/options.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst index 65c90904c7..131319c9aa 100644 --- a/DOCS/man/options.rst +++ b/DOCS/man/options.rst @@ -2761,7 +2761,9 @@ Subtitles Matroska-style ASS subtitle packets. It should be unique, and libass uses it for fast elimination of duplicates. This option disables caching of subtitles across seeks, so after a seek libass can't eliminate subtitle - packets with the same ReadOrder as earlier packets. + packets with the same ReadOrder as earlier packets. Note that enabling this + option can result in broken subtitle behavior if you are not actually + playing one of the aforementioned broken mkv files. ``--teletext-page=<-1-999>`` Select a teletext page number to decode.