DCP Player - Hardware Specification

[rtX]

Hi,

Would anyone have a suggestion as to a hardware specification that is necessary to use DOM Player to decode encrypted 2K and 4K DCPs for feeding to a projector? I have gleaned from https://wolfcrow.com/blog/what-is-a-dig ... -part-two/
A DCI server isn’t any different from any low-end computer server. All it needs to do is be reliable, stable and have fast sequential disk read access. If you open up a few servers, you’ll find:

Usually a low-end Supermicro motherboard with a Xeon processor and 8 GB RAM
A RAID 5 array enterprise-class hard drive (7,200 rpm), with an additional SATA expansion card if necessary. Usually you have four drives. It should be able to sustain 307 Mbps.
A hardware RAID card
Redundant power supply
Gigabit Ethernet Interface for connectivity
BNC interface card for HD-SDI
Software – Playback, Management and Security

That’s about it.You could put together such a system for about $1,500 or less. The projectors and lamps are expensive, as I’ve mentioned here. A typical 2-hour movie will come in under 500 GB, playing back at less than 75 MB/s, including audio (16-channel uncompressed audio is less than 20 Mbps, and a 2-hour movie will be less than 20 GB).

I know no claims are made regarding the speed of the relatively new DOM Player, but wonder if anyone has had success building their own server and running the software on it?

Many thanks,
Richard

[Carsten]

A DCI server consists of all that, yes. Plus a dedicated hardware J2K decoder card and secure processing block. Currently, DCP-o-matic player can not be used in front of a cinema audience. I suggest you try NeoDCP player.

- Carsten

[carl]

It is something I'd like to make happen but I think we're a little way off. I'd be interested to know how close anyone has got to real time playback with DoM on a high performance CPU.

The other development avenues are code optimization and/or GPU acceleration.

[Carsten]

Carl - in another thread, someone mentioned that the playback performance would also depend on the relation between display size/resolution and decoding resolution - one would think that, after decoding, the scaling to the display window would be a piece of cake. Maybe you can test this. In case the scaling is relevant, it would be nice to be able to set the display resolution to integer multiples or fractions of the decoding resolution. Maybe add another option 'Set display resolution to decoding resolution'. Or only allow/set display size in simple multiples of decoding resolution. The trouble is, few graphics cards/displays offer DCI resolutions, so, typically, you can't get away without some scaling, especially if someone want's fullscreen.

Yes, NeoDCP Player is not free, but the necessary hardware to enable full realtime performance with DCP-o-matic player is also not free, so, currently, better spend that money into the most capable player that allows cheaper hardware to be used.

Again, that said only to show DCPs in front of a paying audience.

- Carsten

[mytbyte]

Thank you, Carl, for including the Player to check the playback aspect . However, I find the performance weirdly lacking on a Ryzen 7 and AMD RX580, a 2K DCP can only be played smoothly, (no dropped frames) @ quarter resolution, while CPU usage @ full resolution is kept under 100% at all times. Is this something that's expected, could there be a bottleneck elsewhere (not CPU) or am I doing something wrong?

Concerning the discussion on possible avenues for performance increase, GPU/OpenCL decoding is probably the best way because even a lowly GPU can bring about tremendous speed-up with this kind of operations.

Also, have you considered including some basic anaglyph processing for 3D DCPs?

[Carsten]

I guess currently the only way to improve this is by adding more/faster local cores to your CPU setup. Like a Dual HT server CPU. We have some threadripper benchmarks for encoding. Would be interesting to learn how a threadripper performs during playback.

Optimizing J2K or adding GPU acceleration is a heck of work. Carl (and others) have already optimized the code, but there are limits. And unlike other popular areas of open source development, accelerating J2K is not a prominent goal of the open source community.

- Carsten

[mytbyte]

I understand. I'm just surprised that it won't play smoothly even though none of the cores are saturated. 3dtv.com's JPEG2000 decoder runs through 2K DCPs like hot knife through butter so I expected about the same. Not sure if they even use the help of a GPU (GPU usage hovers around 5%).

[Carsten]

Yes, that's the unsatisfying effect of non-optimized code. It could go faster in theory, but, it can't. I'm wondering wether Carl could compensate a bit for this by requesting more frames multithreaded than there are physical threads available. That was a strategy that worked to a certain extent as long as encoding wasn't optimized. But, while probably easy, that won't make it much faster than it is now. Yes there are some seemingly extremely capable decoders/players out there, but they are not open source, and they will probably not tell us what they do. We don't have much data about the performance of various CPUs in the player either.

- Carsten

[carl]

Thank you, Carl, for including the Player to check the playback aspect . However, I find the performance weirdly lacking on a Ryzen 7 and AMD RX580, a 2K DCP can only be played smoothly, (no dropped frames) @ quarter resolution, while CPU usage @ full resolution is kept under 100% at all times. Is this something that's expected, could there be a bottleneck elsewhere (not CPU) or am I doing something wrong?

Sounds like some kind of bug / inefficiency in the code. It should max CPU out (or close to it). I will try to add some logging to the playback code so we can analyze the timing of the playback internals. I usually test on a i7-7700 which does more-or-less max out playing a 2K DCP (and still drops frames).

Also, have you considered including some basic anaglyph processing for 3D DCPs?

Not yet: do you think it would be useful?

[mytbyte]

Sounds like some kind of bug / inefficiency in the code. It should max CPU out (or close to it). I will try to add some logging to the playback code so we can analyze the timing of the playback internals. I usually test on a i7-7700 which does more-or-less max out playing a 2K DCP (and still drops frames).

I will try an AMD FX tomorrow so will let you know if it saturates.

Also, have you considered including some basic anaglyph processing for 3D DCPs?

Not yet: do you think it would be useful?

Well it would be useful to confirm the 3D view sync on final 3D DCP during playback because you can see both views simultaneously plus whether the effect is right, or you have swapped the views. It would just be a convenience - one can do that in Stereoscopic player anyway so i think it's not that important.