View Bug Details

IDProjectCategoryView StatusLast Update
0002268DCP-o-maticBugspublic2022-09-20 00:23
Reporteroverlookmotel Assigned Tocarl  
PriorityimmediateSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformMacOSOS XOS Version10.14
Product Version2.16.10 
Target Version2.16.14 
Summary0002268: Invalid subtitles XML produced when creating multi-reel VF DCP with multiple SRT files
Description

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:

  • Split the captions into 2 separate SRT files. The 1st contains the captions which can be displayed at normal height, the 2nd contains the captions which need to be raised up.
  • Load OV into DCP-o-matic and chop it up into 5 parts. i.e. same DCP loaded up 5 times, and each part trimmed so it continues from the previous.
  • Select "Reels: Split by video content".
  • Tick "Use this DCP's video/audio as OV and make VF" for the video + audio for each of the 5 chunks of the DCP.
  • Load the 2 SRT files into DOM.
  • Tick "Use as open captions" on each SRT.
  • Set "Y Offset" for the two SRTs to set them at intended height.
  • Make DCP

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 asdcp-unwrap). It contains some very strange timing errors.

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.:

<dcst:Subtitle SpotNumber="2" TimeIn="00:00:-83:21" TimeOut="00:00:-80:10" FadeUpTime="00:00:00:00" FadeDownTime="00:00:00:00">
  <dcst:Text Valign="top" Vposition="91.6818">bought a big chunk of their UK business,</dcst:Text>
</dcst:Subtitle>

Strange indeed!

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.

TagsNo tags attached.
Branch2268-reels
Estimated weeks required
Estimated work requiredUndecided

Activities

overlookmotel

2022-06-07 03:46

reporter   ~0005063

The XML above got garbled. To be clearer, the timecode part reads:

TimeIn="00:00:-83:21" TimeOut="00:00:-80:10"

overlookmotel

2022-06-07 14:03

reporter   ~0005068

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

2022-06-08 00:36

administrator   ~0005073

@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:

  • high emits @ 16:54,480 and so its position is 16:54,480
  • low emits @ 16:55:920 and so its position is 16:55,920
  • pass() is called on high, as its earlier, and it emits @ 21:24,800, causing the subtitle writer to move onto the next reel
  • pass() is called on low, and it emits @ 16:59,400, which is still on the previous reel so causes a -ve time stamp (which is not checked for anywhere yet)

carl

2022-06-08 00:36

administrator   ~0005074

@carl pass() should have been called on low first.

overlookmotel

2022-06-08 12:33

reporter   ~0005080

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 {\an8} tags in SRTs.

carl

2022-06-08 14:42

administrator   ~0005081

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.

overlookmotel

2022-06-08 15:14

reporter   ~0005082

Thanks! Ah so I could work around this by using a single ASS subtitle file. Are other ASS tags like {\pos(20, 300)} also supported?

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.

carl

2022-06-08 18:31

administrator   ~0005083

Last edited: 2022-06-08 18:32

Thanks! Ah so I could work around this by using a single ASS subtitle file. Are other ASS tags like {\pos(20, 300)} also supported?

Some tags are supported (\pos \fs \c \an \u \b \i)

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!

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

2022-06-10 21:32

administrator   ~0005090

Last edited: 2022-06-10 23:50

@carl tests fail, something needs fixing here

carl

2022-06-12 00:00

administrator   ~0005093

@carl tests running again

carl

2022-06-12 14:46

administrator   ~0005094

c8a036eb727ceddc64a0304d781c916eb952c001

overlookmotel

2022-09-20 00:23

reporter   ~0005219

I've sent you an example of output when chopping up a 1-reel OV DCP into reels when making an VF.

This VF was made from ASS subtitles file to work around the issue originally described above. In the process, I did notice one other oddity:

In the subtitles XML the subtitles are out of order i.e. in a 2-line subtitle, the top line appears in the XML below the bottom line.

This isn't invalid I don't think as Vposition is set correctly for each line, to position the top line above the bottom line. But it certainly looks weird in the XML. As it's unusual, I guess it's possible it might be more likely to surface a bug in badly-behaved projector which has never encountered this before.

Spot no. 11 in reel 1 in the example I've sent you Carl demonstrates this.

<dcst:Subtitle SpotNumber="11" TimeIn="00:01:01:23" TimeOut="00:01:05:18" FadeUpTime="00:00:00:00" FadeDownTime="00:00:00:00">
  <dcst:Text Valign="bottom" Vposition="8.68056">there was land here and not sea.</dcst:Text>
  <dcst:Text Valign="bottom" Vposition="14.4381">[Girl] 200 million years ago,</dcst:Text>
</dcst:Subtitle>

overlookmotel

2022-09-20 00:23

reporter   ~0005220

Oh damn it! Mantis really doesn't like XML/HTML in comments.

Bug History

Date Modified Username Field Change
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
2022-09-20 00:23 overlookmotel Note Added: 0005219
2022-09-20 00:23 overlookmotel Note Added: 0005220