Some WebVTT files don't show because they are treated as ts stream

I noticed, that some .vtt files will not show at all (neither show up in the subtitles submenu, nor be drawn over the video) after being added to a playlist item. Changing the content at certain spots, e.g. by inserting or deleting line feeds or characters, will "cure" the subtitles.

The reason is, that instead of proceeding to the correct "webvtt" demux module, the problematic file is read using the "ts" demux module. The relevant part of the log is:

[00007f9494fa5400] main input source debug: creating demux: access='file' demux='any' location='vtt-bug.vtt' file='vtt-bug.vtt'
[00007f9498d181a0] main demux debug: looking for demux module matching "any": 55 candidates
[00007f9494cf30a0] main xml reader debug: looking for xml reader module matching "any": 1 candidates
[00007f9494cf30a0] main xml reader debug: using xml reader module "xml"
[00007f9498d181a0] ts demux debug: Standard set to Auto
[00007f9498d181a0] ts demux warning: lost synchro
[00007f9498d181a0] ts demux debug: skipping 94 bytes of garbage
[00007f9498d181a0] ts demux debug: pid[5173] unknown
[00007f9498d181a0] ts demux debug: first packet for pid=5173 cc=0x6
[00007f9498d181a0] ts demux debug: transport_error_indicator set (pid=945)
[00007f9498d181a0] ts demux debug: EOF at 708
[00007f9498d181a0] main demux debug: using demux module "ts"

While when working it looks like this:

[00007f9494d628c0] main input source debug: creating demux: access='file' demux='any' location='subs.vtt' file='subs.vtt'
[00007f9497b8fe40] main demux debug: looking for demux module matching "any": 55 candidates
[00007f9497b3e370] main xml reader debug: looking for xml reader module matching "any": 1 candidates
[00007f9497b3e370] main xml reader debug: using xml reader module "xml"
[00007f9497b8fe40] ts demux debug: TS module discarded (lost sync)
[00007f9497b8fe40] mod demux debug: MOD validation failed (ext=vtt)
[00007f9497b8fe40] main demux debug: using demux module "webvtt"
[00007f9498d565f0] main decoder debug: looking for spu decoder module matching "any": 23 candidates
[00007f9498d565f0] main decoder debug: using spu decoder module "webvtt"

I tried to reduce the problem as far as possible from a real world example to the attached minimum test file. The important points to reproduce the bug seem to be:

1. Somewhere in the WebVTT file there must be 6 cues in sequence, where each of them contains exactly 70 characters (counting eventual Line Feeds, but excluding the 2 LFs that delimit it from the next cue), followed by 1 more cue containing at least 39 characters.
2. The 1st, 3rd, 5th and 7th of these cues must have a capital "G" as 3rd character.
3. Each of the first 6 cues must contain at least 1 Unicode character outside the ASCII range, that must be positioned somewhere after the "G" where applicable.

Real world examples are less rare than it might seem. In HLS streams, sequential cue segments often contain the same text, so all it takes is that that repeated cue has the right length, a "G" as 3rd character (e.g. starting with "- G...", and contains some diacritic letter. See the attached opera subtitle in german as an example.