WebVTT subtitle cues after the first hour are missing from merged output
Hello Moritz (et al.),
When merging WebVTT subtitle files, only the first hour's subtitle cues are merged into the resulting MKV. Any WebVTT subtitle cues that occur after the first hour are missing from the merged output. The expected correct behavior would be to include all of the WebVTT subtitle cues from the input file.
Here is an example WebVTT subtitle file with four hours of test subtitle cues: test.vtt
(In case it might be useful, here is the short Bash shell script I wrote to create that test file. Perhaps for making a longer test file, going to two-digit hours, or to adjust the limits on the randomization used for cue durations and gaps. make-vtt.sh)
You'll forgive me for not uploading a sample multi-hour video file... I haven't been able to get this to work with any long video I try (usually H.264 with AAC or AC3 audio tracks and sometimes also SRT subtitle tracks that work as expected), so I'm fairly well convinced the issue is isolated to this subtitle format (and hopefully not any weird interaction). Thus, I think any video more than an hour long that you may already have for testing should do.
I tested with MKVToolNix v58.0.0 64-bit on Windows 10. I usually use the GUI, but get the same behavior with the command line version like so:
mkvmerge -o muxed.mkv input-video-longer-than-one-hour.mkv test.vtt
Neither GUI or command line muxing give any message or other indication that anything went wrong, even with a
-v verbose flag.
Playing the file in a player application (e.g. VLC) will show the VTT subtitles as expected for the first hour, but after that, they are simply missing. Extracting with mkvextract like (adjust track number as needed, obviously):
mkvextract tracks muxed.mkv 5:out.vtt
will give a WebVTT file that only has the first hour's cues.
I considered that maybe it was possible the subtitle cues were merged ok, and the problem was with demuxing. To check, I used the strings command
strings -n 16 muxed.mkv
to see if the cues' text were in the MKV. It again shows only the first hour's cues, none after that. So that confirms to me that they are never muxed to begin with.
In searching the issue (bug) list, I wondered if a clue was hinted by issue #2139 (closed). The problem there was that WebVTT cues that didn't have an hour component specified in their timestamps weren't included. I wondered if it might just be a mis-handling of the hour component when reading/importing the WebVTT timestamps. So I tried modifying my input VTT file to always have the hours component, even when it was zero, and that didn't change anything. Actually, I also installed v15.0.0 from before the fix to see if that fix might have broken anything, but it didn't. It showed the same behavior. (Is this bug really that old???)
So correct behavior would be 1) for
mkvmerge to merge a WebVTT subtitle file with no arbitrary time limitations or cutoffs, and include all of the cues in the file (at least to the end duration of the video track as a minimum), and also 2) for
mkvextract to be able to correctly extract all of those cues as well.
Ideally, we should be able to "round-trip" a WebVTT file, meaning that
mkvextract's extracted file should be identical in content to the input file given to
mkvmerge, aside from ASCII->UTF-8 or such. (For ease of comparison, I suggest it might be better to omit the hour component when writing extracted WebVTT cues when the hour is zero, as that seems to be the convention in all the source WebVTT files I have come across, but that's somewhat separate from the main issue.)
Thanks for all your work!