On Sat, Feb 05, 2022 at 02:08:48 +0000, Soft Works wrote: > Let's try to approach this from a different side. Which case is > your [1/2] commit actually supposed to fix? Escape backslashes when converting from WebVTT to not accidentally introduce active ASS sequences and replace the wrong backslash-escape in ff_ass_bprint_text_event with an escape that actually works. > How did you test your patch? > Can we please go over an example? Take a look at the attached WebVTT file. We expect the second event to be rendered like this, as from WebVTT’s point of view it’s just normal text: our final \h approach \N into \ Coruscant. What we currently get after conversion to ASS is like this though (pay attention to the number of spaces): our final approach into \ Coruscant. If we escape \ as \\ like ff_ass_bprint_text_event currently does, we instead get the following rendering which is also wrong: our final \ approach \ into \\ Coruscant. If instead the word-joiner is appended as in my patch, the visual output matches the expectation (mail does not contain U+2060): our final \h approach \N into \ Coruscant. You can confirm this for yourself by feeding the original WebVTT to a native WebVTT renderer, e.g. https://zcorpan.github.io/live-webvtt-viewer/ and using ./ffmpeg -i test2.vtt -f ass tmp_conv.ass on master, master + my patch and master + a modified patch to use \\ then watching how the converted file gets rendered by mpv, VLC or so. I was not able to create a sample using ff_ass_bprint_text_event as the only users seem to be teletext and some rawtext(?) subtitles and I don't know how to create such files. However, as nothing special happened to the \\ for WebVTT after this sequence was inserted for the internal representation, and since the preceding comment (wrongly) declares \\ to be an ASS rather than an internal escape, it seems highly unlikely to behave any different. You are very welcome to provide a sample using the ff_ass_bprint_text_event codepath and keep_ass_markup=false to verify or debunk this.