View Bug Details

IDProjectCategoryView StatusLast Update
0001290DCP-o-matic[All Projects] Bugspublic2018-05-14 22:24
ReporterCarstenAssigned Tocarl 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformMacOSOS X OS Version10.11
Product Version2.12.x 
Target Version2.12.xFixed in Version 
Summary0001290: changes to subtitle (burn in) parameters do not seem to trigger re-compression/recreation of content
Description

When doing some burn-in subtitle tests, I noticed that when I adjust Y-offset, then recreate (overwrite) DCP, DCP-o-matic seems to reuse the previous video file, and the burn-in subtitle stays at the previous position in the newly created DCP. I need to delete DCP folder/video folder in order for the new position to take effect. This may also happen for other subtitle settings. Maybe NO changed subtitle settings trigger video recreation, because usually that is not necessary when subs are created as timed-text?

In that case - WHEN burn-in is checked, any change to subtitle settings, appearance, font, etc. should trigger video recompression.

  • Carsten
TagsNo tags attached.
Estimated work requiredUnknown

Activities

Carsten

2018-05-06 01:03

manager   ~0002410

Yup - when I first create a DCP with a black outlined burn-in sub, then change the outline color to cyan, then recreate the DCP, I get the request to overwrite, but the previous MXF from the video folder is reused - the DCP still has the black outline sub. I need to delete the video mxf from the video folder and issue another MakeDCP for the actual settings to be used in a new render.

I could test other parameters as well, but I guess it is safe to assume that in this scenario, no changed subtitle setting at all will trigger a recompression.

  • Carsten

carl

2018-05-07 23:50

administrator   ~0002411

Should be fixed by 4a23fb5dd58c6439f240f678be2e26a5bee17881

carl

2018-05-08 23:03

administrator   ~0002414

Should probably be applied to 2.12.x.

Carsten

2018-05-09 01:26

manager   ~0002415

yup - guess it's a 'no-risc' backport.

  • Carsten

carl

2018-05-14 22:24

administrator   ~0002429

Applied to v2.12.x as d2b086ebd7333e80b77fb54ce04816b27dbf1cb6 for v2.12.5.

Bug History

Date Modified Username Field Change
2018-05-06 00:18 Carsten New Bug
2018-05-06 00:18 Carsten Status new => assigned
2018-05-06 00:18 Carsten Assigned To => carl
2018-05-06 01:03 Carsten Note Added: 0002410
2018-05-06 21:52 Carsten Description Updated View Revisions
2018-05-07 23:50 carl Status assigned => resolved
2018-05-07 23:50 carl Resolution open => fixed
2018-05-07 23:50 carl Note Added: 0002411
2018-05-08 23:03 carl Status resolved => confirmed
2018-05-08 23:03 carl Target Version 2.13.x => 2.12.x
2018-05-08 23:03 carl Note Added: 0002414
2018-05-09 01:26 Carsten Note Added: 0002415
2018-05-14 22:24 carl Status confirmed => resolved
2018-05-14 22:24 carl Note Added: 0002429