View Bug Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002268||DCP-o-matic||Bugs||public||2022-06-07 02:28||2022-06-12 14:46|
|Platform||Mac||OS||OS X||OS Version||10.14|
|Summary||0002268: Invalid subtitles XML produced when creating multi-reel VF DCP with multiple SRT files|
I have an OV DCP (created with DOM) and am trying to create a VF DCP to add open captions. I have the captions as an SRT file.
The complication is that some of the captions need to be raised up to avoid clashing with existing on-screen text.
The OV DCP is feature-length and in a single reel. To ensure no subtitles XML is longer than 256KB, I need to split it into reels for the VF.
The feature is 25fps so OV is SMPTE and VF is going to be SMPTE too.
Steps taken to achieve the above:
When playing back, 2 large stretches of subtitles are absent, around the reel boundaries.
I have traced the problem to a fault in the subtitles XML in the VF DCP (as extracted from the subs MXF files with
Subtitles which should have been at the end of reel 1 appear at the start of the subtitles XML for reel 2, but with invalid negative timecodes e.g.:
The above is observed in 2.16.10, and also in 2.14.54 (though in DOM 2.14.54 the timecodes are different e.g. "-1:58:34:14"). Have not tried 2.16.13, but I don't see anything obvious in the changelog to suggest it may have been fixed since 2.16.10.
Probably bug has been around a long time, but no-one has been foolhardy enough to try such weird stuff with multiple SRT files and reels before.
|Steps To Reproduce|
Carl, I'll send you the OV DCP, SRTs, and DOM project.
|Tags||No tags attached.|
|Estimated weeks required|
|Estimated work required||Undecided|
The XML above got garbled. To be clearer, the timecode part reads:
Carl, I've emailed you files to reproduce.
I noticed one other thing. The two reels which had subtitles "stolen" from them also have the TTF font file in the MXFs twice (both copies are identical, same hash).
@carl this seems to be due to the fact that the text decoder's position() is the time of the last subtitle that was emitted; in this case we have two bits of subtitle content:
@carl pass() should have been called on low first.
Is using two SRT files in this way even supported?
Or is there an easier way to position some subtitles differently? DOM (at least 2.14.x) seems to ignore
It's supposed to work, particularly for the use case of adding two subtitle files in different languages and having them both on-screen at the same time. There's a little bug related to that, made worse by the reels, and also there seems to be another bug exposed by having repeated trimmed content and then making reels... phew!
\an8 should work in SSA/ASS but last time I looked the jury was out on whether SRT is supposed to support these tags and I wasn't sure whether it was a good idea to muddy the waters further.
Thanks! Ah so I could work around this by using a single ASS subtitle file. Are other ASS tags like
Can I ask what's the bug related to trimmed content and reels? (i.e. chopping up an existing DCP into sections to make multiple reels in a VF). Have been doing that a fair bit recently and not hit any bugs that I'm aware of. Unless I did hit a bug and just won't find out until the DCP screens!
NB One of those DCPs went to MPS for distribution so I assume they validated it and would have rejected it if it wasn't valid.
By the way, I don't know if there's a formal spec for SRT, but it seems to be a bit wild west. I'd say at least 30% of the SRTs we receive from filmmakers aren't valid in some way or another (overlapping subs, excess line breaks between subtitles etc). It's pretty messy.
Some tags are supported (\pos \fs \c \an \u \b \i)
As far as I can see if you are trimming the start of DCP content and placing it at a non-zero position in a VF DCP, and referring to it, there may be problems - but I would expect errors rather than bad DCP outputs. Can you share the metadata.xml and CPL files of any DCPs you are worried about?
Agreed on the randomness of SRT. I'm not even sure which program people mostly use to create them - if there was an obvious one I guess using its output as a de-facto "standard" would make some kind of sense.
@carl tests fail, something needs fixing here
@carl tests running again
|2022-06-07 02:28||overlookmotel||New Bug|
|2022-06-07 03:46||overlookmotel||Note Added: 0005063|
|2022-06-07 09:22||carl||Status||new => acknowledged|
|2022-06-07 09:22||carl||Estimated work required||=> Undecided|
|2022-06-07 09:22||carl||Priority||normal => immediate|
|2022-06-07 09:22||carl||Target Version||=> 2.16.14|
|2022-06-07 09:22||carl||Severity||minor => major|
|2022-06-07 14:03||overlookmotel||Note Added: 0005068|
|2022-06-07 23:59||carl||Assigned To||=> carl|
|2022-06-07 23:59||carl||Status||acknowledged => in progress|
|2022-06-07 23:59||carl||Branch||=> 2268-reels|
|2022-06-08 00:36||carl||Note Added: 0005073|
|2022-06-08 00:36||carl||Note Added: 0005074|
|2022-06-08 12:33||overlookmotel||Note Added: 0005080|
|2022-06-08 14:42||carl||Note Added: 0005081|
|2022-06-08 15:14||overlookmotel||Note Added: 0005082|
|2022-06-08 18:31||carl||Note Added: 0005083|
|2022-06-08 18:32||carl||Note Edited: 0005083|
|2022-06-10 21:32||carl||Note Added: 0005090|
|2022-06-10 23:50||carl||Note Edited: 0005090|
|2022-06-12 00:00||carl||Note Added: 0005093|
|2022-06-12 14:46||carl||Status||in progress => resolved|
|2022-06-12 14:46||carl||Resolution||open => fixed|
|2022-06-12 14:46||carl||Note Added: 0005094|