DCP from DPX sequence and separate sound elements

[rtX]

It's a gigabit ethernet network. There's not a lot of other traffic on the network - bit of e-mail and light web surfing. The machines are only a few feet from the router and are all wired. I was watching the status of the encode servers and they all seemed to be receiving frames within a fraction of a second, encoding at about 2.8 seconds per frame and sending the frame back significantly faster than received. The 2 core machine was operating at a similar rate to the 4 cores.

[carl]

The new test version should give better performance with image-file source such as yours; before, the source image decoding was single-threaded, but in newer versions the decoding is multi-threaded.

[rtX]

They are networked on a gigabit network within a few feet of the router. I watched the reported (by the encoding servers) timings of each frame. Generally, receipt (by the server) of the frame took 0.1 seconds or less, encoding about 2.8 seconds, transmission back 0.02 seconds, sometimes less. Watching the CPU usage on the server machines, it was never 'stressed' or near 100% usage. On the main Linux machine I installed some monitoring software. Network transmissions and receipts seemed to be evenly spaced and supported the figures given by the encoding servers, both in frequency of spikes and amplitude. I increased performance of the main program by increasing the process's priority to be "Very High". This seemed to increase the usage over the four CPU cores and the frame rate increased (using one other server) to a reported 0.7 frames per second.

I'll try 1.69.9 to which you've made adjustments for my sort of set up and see what the difference is like.

Incidentally, I screened my most recently created (by DCP-o-matic) DCP in a small professional screening room yesterday afternoon with a professional colourist who had graded the film. The KDM worked with the DCP and the film looked great - thank you for your help making this happen.

[carl]

I'll try 1.69.9 to which you've made adjustments for my sort of set up and see what the difference is like.

Cool, thanks.

Incidentally, I screened my most recently created (by DCP-o-matic) DCP in a small professional screening room yesterday afternoon with a professional colourist who had graded the film. The KDM worked with the DCP and the film looked great - thank you for your help making this happen.

Great! I'm glad it worked!

[rtX]

Just reporting back: The speed of processing has dramatically increased in recent versions of the software. I've not tried 1.72.0 yet, but the immediately preceding test versions were processing a DPX data set much faster. Using two machines (ie. one encode server and one main program), I was encoding a film in about 22 hours. With earlier versions it had taken about 90 hours with three encode servers.

Thank you, Carl!

[Carsten]

Can you tell us more about the specific machines you used? If you look up the current benchmark tables on the DCP-o-matic website, you can see that some tests were done with more threads configured than the machine physically has available - and it improved the encoding speed. A good rule of thumb is double the number of encoding threads on modern CPUs. I don't know if that works the same under Linux, but at least for windows it is a useful suggestion. Of course, if you overdo it, you get slower results (and in the case of the WIN32 version, crashes). You may also need more RAM.

- Carsten

[cinema.saudia]

Hello.

Is there any one here experiencing problem adding folder (DPX files) and then the sequence is kinda messed up?

Any solution for this one?

I'm using DCP-O-MATIC in Mac Pro.

Thank you!

[carl]

What are your filenames like?

[cinema.saudia]

Hi Carl,

ap_trlr_178_uhd_bt1886_txt_e5c1_033115.86352

thank you in advance!

[carl]

Which one is the frame number there?