21 Nov
2014
21 Nov
'14
8:55 p.m.
Hello all.
I'm doing tech on the London Short Film Festival which is January. We
are delivering all the films to cinemas on DCP this year (all 350 of
them) and will be using DCP-o-matic to use them.
We're holding a workshop tomorrow and Sunday where we're going to train
100 film-makers on DCP-o-matic, and then guide them through the process
so that by the end of the weekend, they will hopefully all have DCPs of
their films.
I have a couple of last-minute questions that I would very much
appreciate it if anyone would be able to help with.
_1. Encoding servers_
We have a network of 30 iMacs, all networked together with Gigabit
ethernet. We intend to run dcpomatic_server_cli on all of those, with
DCP-o-matic itself running on the laptops of the film-makers and using
the encoding servers to do the heavy lifting.
a. Will it work with 30 encoding servers?
b. What happens if two instances of DCP-o-matic try to send jobs to the
encoding servers simultaneously? Is it first-come-first-served and
whoever submits their job first gets control of all the encoding servers
until their job is complete? Or do the encoding servers get shared out
between different jobs so multiple jobs can run concurrently? Or,
terror-of-terrors, will the whole thing crash?
_2. Best version to use_
How stable is v1.76.13 likely to be? Or should we use v1.76.0?
I've been told that some issues with colour space conversion are being
resolved in recent test releases. Is v1.76.13 going to give a better
result in terms of colour than the 1.76stable?
Sorry for the barrage of last-minute queries. I hope someone may have
some pointers?
Many thanks,
Jim
22 Nov
22 Nov
1:10 a.m.
Hi Jim,
On Fri, 21 Nov 2014 20:55:57 +0000
Jim Dummett <j(a)dummett.org> wrote:
That sounds fun!
It should. I haven't tested it with quite that many. A single master
can saturate a Gbit ethernet quite quickly (around 8 servers, or so) but
if you are talking about multiple masters with 30 servers it should be
ok.
Are you connecting the laptops with Gigabit cabled ethernet? Things
would be much slower if you relied on wireless, especially if you have
100 laptops all sharing the same channel.
In theory, each server should tell each master that it is available,
and then each master should send each server frames to encode. The
servers should share their power out amongst any masters which ask them
to do encoding work. In short: it should share out the encoding
servers so multiple jobs can run concurrently.
This has not been tested, though (by me, at least).
The significant change in 1.76.13 wrt 1.76.0 is that 1.76.0 truncates
all its video to 24-bits-per-pixel RGB as part of the processing
chain. This is less than the 36-bits-per-pixel that DCP allows.
For stability, I would choose 1.76.0. On the other hand, I'm not aware
of any new bugs in 1.76.13. It depends on how likely your users are
to have source material in high bit depths.
Do let me know how you get on, and please feel free to impress upon
your film-makers that this mailing list (or the forum at
dcpomatic.com/forum) is the best place to come if they have any problems
with DCP-o-matic: if we know about them, we can try to fix them.
Best of luck!
Regards,
Carl
7:40 a.m.
Thanks all for your replies - really helpful. I'll reply to individual
comments and give a general update on how it all goes with the workshop
at the end of the weekend, but right now I'm running out the door to go
to the first session.
But in the meantime, one more quick question if anyone is up and about
to read it...
What is the target for peak audio level? I mean we can find out what the
peak audio level of the incoming material is using the "Show audio"
button (or other tools). And then we can adjust it up or down using the
gain control. But what is the target? Everything peaking right at the
top 0dB so the full headroom is used, or at a lower level something like
-6dB like preparing tapes for broadcast, or something else?
I'd like to get everything to roughly the same sound level. Of course,
it's more complicated than that, because of perceived loudness versus
"actual" loudness, but without going into applying compression etc to
some of the soundtracks etc, that's the closest we're going to get.
Please let me know oh font of knowledge!
Jim
On 22/11/2014 01:10, Carl Hetherington wrote:
7:51 a.m.
I have found that if you keep your RMS level around -25 dB, it works well. You definitely
wouldn't want your peak levels to be hitting 0 dB.
Sumit
----- Original Message -----
From: "Jim Dummett" <j(a)dummett.org>
To: "Carl Hetherington" <cth(a)carlh.net>et>, dcpomatic(a)carlh.net
Sent: Friday, November 21, 2014 11:40:59 PM
Subject: Re: [DCP-o-matic] How many encoding servers?
Thanks all for your replies - really helpful. I'll reply to individual
comments and give a general update on how it all goes with the workshop
at the end of the weekend, but right now I'm running out the door to go
to the first session.
But in the meantime, one more quick question if anyone is up and about
to read it...
What is the target for peak audio level? I mean we can find out what the
peak audio level of the incoming material is using the "Show audio"
button (or other tools). And then we can adjust it up or down using the
gain control. But what is the target? Everything peaking right at the
top 0dB so the full headroom is used, or at a lower level something like
-6dB like preparing tapes for broadcast, or something else?
I'd like to get everything to roughly the same sound level. Of course,
it's more complicated than that, because of perceived loudness versus
"actual" loudness, but without going into applying compression etc to
some of the soundtracks etc, that's the closest we're going to get.
Please let me know oh font of knowledge!
Jim
On 22/11/2014 01:10, Carl Hetherington wrote:
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
1:12 a.m.
Happy to see that more festivals are going full DCP. <shamelessPlug> I
started a company for helping in this process
akadcp.com</shamelessPlug> after having a great experience during my
festival in Quebec City fcvq.ca and sharing that experience in a few
other places.
I understand that you are doing this training as a workshop? That will
be great, let's also teach them how to make a torrent or use btsync! I
dont want to ship around more usb memories! hehehe
For short films, specially having so many computers available, forget
the networked servers, your bottleneck will be checking the source
material, checking and correcting volume and creating the project. And
managing all the files, both source and DCP. Render time will be fine
with single computer.
If you want to benefit from the the network render, you will need to
use batches, like work with the people creating the projets, and then
let the computers do their thing overnight. Probably in a few
independent networks.
As for the best version, I'm sure before January there will be new
ones, or I hope so!! I'm so excited with v2, already did a couple
subtitled dcps with it. And 12 bits processing is also great news.
Carl, maybe this is a good moment to ask for a long-dreamed feature:
having the option to specify the destination for the finished DCP, and
not inside the projet directory. I understand that this breaks your
cool hardlink trick.
And Carl, once started to ask for christmas presents :) All that
little md5 files can be somehow packaged in a single file? It's a pain
to delete or move all of them. And quite usually dcpomatic-made DCPs
are mistakenly sent with the whole projet directory, making the ingest
insanely slow, as the server checks all that md5 as ingest candidate
files.
Jim and any other one in a similar situation, please please! keep in contact.
Manuel AC
On Fri, Nov 21, 2014 at 3:55 PM, Jim Dummett <j(a)dummett.org> wrote:
24 Nov
24 Nov
11:01 a.m.
Hi Manuel,
[snip]
As you say, the question here is how to handle the video MXF. I guess the
best that could be done is create it in the destination folder, keep a
note of where it is, and then try to re-use the MXF from that folder if
a second transcode is requested.
I think that's possible... I'll have a look.
Best,
Carl
22 Nov
22 Nov
1:45 a.m.
Am 21.11.2014 um 21:55 schrieb Jim Dummett:
Wow, really sounds like fun. And teaching film-makers how to make DCPs properly for
festivals comes close in benefit to feeding the world ;-)
All I can say that from my testing with an 8-machine Mac network is that I never had any
issues with crashes or lost frames when I did my nightly benchmarking session. I was
adding machines, taking them out, restarting jobs, etc,, not a single hickup. So I really
think Carl did a good job there. I never tried to utilize multiple encoding servers from
multiple encoding masters in a workshop-style, though.
The only issue could indeed be that the new 12Bit processing has not received too much
testing. For just a training session, I wouldn't bother to use an older stable
version, but if they want to prepare their final work into DCP on this occasion, some of
them may be concerned about this if they use 10 or 12 Bit footage from some of the more
advanced cameras. It is not easy to say where this would really be a visible issue. The
problem is - once you offer a choice of two numbers indicating 'image quality' to
them, they will naturally prefer the higher number. Honestly I can't give advice here.
Will the participants use only these 30 iMacs for the whole workshop, or will they bring
their own machines as well to be integrated into the workshop network?
- Carsten
6:33 a.m.
Jim, hi,
great project, should be exciting.
On a related note let me suggest you setup at least one dedicated workstation for DCP
inspection and validation. Doing that will save you _a lot_ of headaches.
There are essentially three useful/capable solutions for DCP validation:
* CineCert's Wailua (authoring suite with DCP validation/fixing)
* FhG's easyDCP Player+ (playback app with DCP validation)
* dcp_inspect (DCP deep inspection and validation)
The former two are commercial solutions. I consider CineCert's Wailua to be the
benchmark system for all matters DCP. Both systems involve significant costs, though, so
they may not be for everyone.
The latter, dcp_inspect, is open source/free-to-use (I'm the author). A fair bunch of
festivals and facilities use it, e.g. Sundance, GIFF. See
https://github.com/wolfgangw/backports#readme for a quick start wrt installation and
usage.
Wolfgang
3809
days inactive
3812
days old
7 comments
6 participants
participants (6)
-
Carl Hetherington -
Carsten Kurz -
Jim Dummett -
Manuel AC -
sguha -
Wolfgang Woehl