View Bug Details

IDProjectCategoryView StatusLast Update
0001545DCP-o-maticBugspublic2020-12-16 00:11
ReporterCarsten Assigned Tocarl  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformMacOSOS XOS Version10.12
Product Version2.14.0 
Target Version2.14.x 
Summary0001545: Player chokes on DCPs using PNG subs
Description

I just created a short DCP using PNG subtitles from a DVD/VOB. DCP looks okay, a couple of PNGs in subtitle folder.
However, standalone player shows no DCP properties for this DCP ('No DCP loaded'), and upon the first PNG, the screen goes black, playback stops and doesn't recover. DCP-o-matic main seems to have no problem showing and rewrapping the PNG'ed DCP - although, when I add the PNG'ed DCP to a new project, save and reload, I get an error upon loading (see attached screenshot).

  • Carsten
TagsNo tags attached.
Branch
Estimated weeks required
Estimated work requiredUndecided

Activities

Carsten

2019-05-03 09:50

manager  

carl

2019-05-03 15:01

administrator   ~0003304

Fixed the make_transparent() error in 46df210e1c25c3cdae664390efac8e60714ad635

carl

2019-05-03 15:02

administrator   ~0003305

Can't reproduce the failed playback, though; is it feasible to make the failing DCP available?

Carsten

2019-05-04 01:20

manager   ~0003307

Last edited: 2019-05-04 01:20

I guess, yes. I took a DVD-RIP, trimmed it to a few seconds containing a few subs, then created the DCP. Went without issues, I can load it into DCP-o-matic main, but it shows that behaviour in the player on my Mac. The DCP is about 1.2GB though. I could try with a tighter trimming to make it smaller? Maybe leaving out video and audio mxf would already help you?

  • Carsten

carl

2019-05-04 01:23

administrator   ~0003308

1.2Gb is fine with me if it's doable for you. If not, I can try again; perhaps it's a mac-only thing, I haven't tested my DCP on a Mac yet.

Carsten

2019-05-04 01:34

manager   ~0003309

Last edited: 2019-05-04 01:42

Let's see - I created the same DCP, but disabled subtitles, plays okay in both player 2.14 and 2.13.156. So it's not something else in that DCP or source. Both player 2.14 and 2.13.156 show the same behaviour with the PNG'd DCP. It's weird that after loading, the first frame appears, but the DCP content indicators at the bottom remain empty. It says 'No DCP'.

For now, here's the project file and DCP metadata:

PNGtest.zip (624,711 bytes)

Carsten

2019-05-04 01:49

manager  

PNGTestBlack.zip (652,849 bytes)

Carsten

2019-05-04 01:49

manager   ~0003310

Alright, I created another DCP, using the PNG/XML subtitles from the previous PNG test, but without video and audio content. DCP-o-matic put's the PNGs nicely over a black backgound with silent audio, render goes fast and delivers very small DCP. Exhibits the same behaviour in the player - but uploads in a breeze...

carl

2019-05-04 13:27

administrator   ~0003312

Thanks, I see that on my Mac, but not on Linux, oddly.

carl

2019-05-04 13:39

administrator   ~0003313

Sat 4 May 13:38:17 2019: 0.625 -> 0.5866770833333333; delay 38.32291666666665
Sat 4 May 13:38:17 2019: 0.6666666666666666 -> 0.63015625; delay 36.51041666666666
Sat 4 May 13:38:17 2019: 0.7083333333333334 -> 0.67221875; delay 36.11458333333339
Sat 4 May 13:38:18 2019: 0.75 -> 0.7129583333333334; delay 37.04166666666664
Sat 4 May 13:38:18 2019: 0.7916666666666666 -> 0.75490625; delay 36.76041666666663
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.7951666666666667; delay 38.16666666666669
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.835625; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8411979166666667; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8431145833333333; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8447395833333333; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8463958333333333; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8480416666666667; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8496770833333334; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8513958333333334; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8531145833333333; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8547604166666667; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.86315625; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8648645833333334; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.86646875; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.8682291666666667; delay 1
Sat 4 May 13:38:18 2019: 0.8333333333333334 -> 0.87009375; delay 1

carl

2019-05-04 13:40

administrator   ~0003314

i.e. _video_position is never getting updated; i.e. ::get() isn't successfully fetching a new frame.

carl

2019-05-04 22:43

administrator   ~0003317

Seems maybe to have been fixed by the pixel_format() patch; perhaps you can test 2.14.1.

Bug History

Date Modified Username Field Change
2019-05-03 09:39 Carsten New Bug
2019-05-03 09:49 Carsten Description Updated
2019-05-03 09:50 Carsten File Added: Bildschirmfoto 2019-05-03 um 10.49.11.png
2019-05-03 15:01 carl Assigned To => carl
2019-05-03 15:01 carl Status new => feedback
2019-05-03 15:01 carl Note Added: 0003304
2019-05-03 15:02 carl Note Added: 0003305
2019-05-04 01:20 Carsten Note Added: 0003307
2019-05-04 01:20 Carsten Status feedback => assigned
2019-05-04 01:20 Carsten Note Edited: 0003307
2019-05-04 01:23 carl Note Added: 0003308
2019-05-04 01:34 Carsten File Added: PNGtest.zip
2019-05-04 01:34 Carsten Note Added: 0003309
2019-05-04 01:36 Carsten Note Edited: 0003309
2019-05-04 01:42 Carsten Note Edited: 0003309
2019-05-04 01:49 Carsten File Added: PNGTestBlack.zip
2019-05-04 01:49 Carsten Note Added: 0003310
2019-05-04 13:27 carl Note Added: 0003312
2019-05-04 13:27 carl Status assigned => confirmed
2019-05-04 13:39 carl Note Added: 0003313
2019-05-04 13:40 carl Note Added: 0003314
2019-05-04 22:43 carl Status confirmed => resolved
2019-05-04 22:43 carl Resolution open => fixed
2019-05-04 22:43 carl Note Added: 0003317
2020-12-16 00:11 carl Status resolved => closed