26 Oct
2015
26 Oct
'15
10:15 a.m.
On Fri, 23 Oct 2015, Carsten Kurz via DCPomatic wrote:
Am 22.10.2015 um 16:35 schrieb Jonathan K. F. Jensen via DCPomatic:
1. Upload the material for conversion (still/video/separate audio).
2. Create project and Input metadata (dcp name, kind, bitrate, etc)
3. Be able to choose Audio Analyse and get either just the peak or maybe even a
graphical representation (like in DOM).
4. Choose to put the DCP in queue (that doesn't start until you tell it to) or
encode it right away. (transfer DCP to FTP/SFTP)
Encoding would happen on local machines on the LAN or on just one machine. It would
basically be a web frontend for DOM
[snip]
But they can do all this already now by running their
local copy of
DCP-o-matic? Yes, you would say that with a web-frontend, no local
installation would be necessary. But who would think of a work scenario
where multiple people would routinely do DCP creation/conversion, but
would not be allowed a local installation of a DCP conversion software
(and one that is more or less free of side-effects like DOM is)?
[snip]
Carl, usually we talk about one DOM Master GUI talking
to many render
nodes. What if two DOM Master GUIs try to talk to the same render node?
It should work fine. The only thing that I think will happen with the
current code is each render node will offer all its cores to anyone who
asks, so it may end up taking on too much work. But you could just run
some render nodes and then let anyone in an organisation connect to them.
Settting these projects up for conversion is not such
a big deal and HAS
to be done manually, the J2k coding is still the major time consuming
part of this job. Preparing 300 films for presentation simply needs
time. Shooting them took it's time as well. That's just the way it goes
- after all, an all-DCP presentation scheme does save a lot of time and
hassle already, that can be invested in proper preparation.
Maybe there is scope to improve the workflow of DCP-o-matic for this kind
of application.
Regards,
Carl