View Bug Details

IDProjectCategoryView StatusLast Update
0000766DCP-o-maticBugspublic2018-10-17 20:14
Reporterrobn Assigned Tocarl  
PriorityhighSeveritycrashReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSFedoraOS Version22
Product Version2.5.0 
Summary0000766: Burned-in subtitles from specific .srt file lead to excessive memory consumption
Description

I had problems with rendering a DCP for a certain film:
DCP-o-matic would always crash after several hours.

I narrowed the problem down to the .srt subtitle file used in combination
with burned-in subtitles. Even when I edit the subtitle file and only
leave the first 5 subtitles in, the problems persists. This very short
"demo.srt" is uploaded with this report.

The only thing special I can see about the demo.srt file
is that "file demo.srt" says:

UTF-8 Unicode (with BOM) text

This BOM thing corresponds to 2 bytes (FEFF) at the start of the file :

https://en.wikipedia.org/wiki/Byte_order_mark

The subtitles are displayed OK in the preview window, and the
subtitles are rendered OK in the result. The only problem is
the huge amount of memory it takes ..

Steps To Reproduce
  • use any video content

  • use the small "demo.srt" subtitle file

  • configure "burned-in" subtitles

  • start the DCP job

  • watch the memory consumption of the DCP-o-matic grow unbounded.
    Eventually when all free virtual memory is used the kernel will
    kill the DCP-o-matic process if your content is long enough or your
    swap & memory small enough.

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work requiredAverage

Activities

robn

2015-11-29 04:49

reporter  

demo.srt (339 bytes)

robn

2015-11-29 04:57

reporter   ~0001019

I tested with v2.5.11 but had the problem with an earlier version too (2.5.8 ?)

carl

2015-11-29 16:49

administrator   ~0001020

Please could you try 2.5.12 as there is a speculative fix for this.

robn

2015-11-29 21:55

reporter   ~0001021

Yes, 2.5.12 seems to fix the problem, thanks!

But I still don't understand why the problem was only with
the supplied subtitle file while any other .srt I tried did
not result in the uncontrolled memory usage ..

carl

2015-11-29 22:21

administrator   ~0001022

Yes, that is very strange. The bug should have manifested with any burn in. Let me know if you have further problems, and thanks for the detective work.

Bug History

Date Modified Username Field Change
2015-11-29 04:49 robn New Bug
2015-11-29 04:49 robn File Added: demo.srt
2015-11-29 04:57 robn Note Added: 0001019
2015-11-29 16:49 carl Note Added: 0001020
2015-11-29 16:49 carl Assigned To => carl
2015-11-29 16:49 carl Status new => feedback
2015-11-29 21:55 robn Note Added: 0001021
2015-11-29 21:55 robn Status feedback => assigned
2015-11-29 22:21 carl Note Added: 0001022
2015-11-29 22:21 carl Status assigned => resolved
2015-11-29 22:21 carl Resolution open => fixed
2018-10-17 20:14 carl Status resolved => closed