6 May
2015
6 May
'15
12:26 p.m.
Am 06.05.2015 um 13:42 schrieb Jim Dummett via DCPomatic:
Carsten - seems like a good idea to test it on 1 PI before buying a job lot. But if
performance does turn out to be economical, I'd be very happy to buy a few of your
test PIs from you. But at the moment it does look too good to be true!
I received my model 2B yesterday, I would be happy to test it with different material to
see wether it's a viable option. I'm not fit to compile it myself, though, so I
need a working image.
Does anyone have any guess as to how long it's likely to be before an open source
GPU-accelerated JPEG2000 encoder comes to fruition? That would probably render this
approach obsolete anyway...
Carl will comment on that, but from my conversation with him and what I see on the net
regarding GPU j2k implementations, it may not be too far away.
Some opensource GPU accelerated j2k implementations are already available, but not a full
OPENJPEG port yet.
The problem is, DCI j2k has to follow stringent codestream rules to make sure content can
be played on every cinema server in the world. OPENJPEG has special DCI options to
accomplish that. The existing j2k implementations are not OPENJPEG ports, so currently
they lack these DCI constrained encoding parameters.
Before one of these existing GPU j2k projects can be embedded into DCP-o-matic, codestream
compliance has to be secured. I also think that additional thinking has to go into the
different platforms with their different GPU programing interfaces/models.
I did a lot of benchmarking recently after I received my new xeon machine, I am currently
preparing a longish post on performance optimization and machine selection. That could
help a bit waiting for GPU assisted J2k.
- Carsten