DCP-o-matic users

users@lists.dcpomatic.com

1 participants
633 discussions

Re: [DCP-o-matic] code optimizations and encoding speed

by Carsten Kurz

Am 16.03.2016 um 18:25 schrieb Nimesh Shrestha: > Hi Carl/Carsten, > I have a HP Z840 single CPU 8 core workstation. Can you guys please guide me the uptimum settings in DOM, to fast encode DCPs? Use v2.7.1 or v2.7.4, set 20 threads in preferences. Adding a second CPU to your workstation will double the speed. Or buy a second hand Z600 Dual-6core machine and use as network encode server. - Carsten

9 years, 1 month

[DCP-o-matic] code optimizations and encoding speed

by Carsten Kurz

Wow, I had the time to re-run my benchmarks with DCP-o-matic 2.74 and compare against my previous tests - these new code optimizations really pay out. v1.83 Bunny: 12.3fps (20 threads on master +28 threads on localhost encode server) v2.74 Bunny: 19.3fps (32threads on master GUI only) v1.83 Sintel: 9.9fps (20 threads on master +28 threads on localhost encode server) v2.74 Sintel: 14.6fps (32 threads on master GUI only) These were done on a dual Xeon-5660 (2*6Core + HT) machine using the standard BigBuckBunny and Sintel benchmark metafile data: http://dcpomatic.com/benchmarks/ Aside from the J2C code optimizations brought in by Aaron Boxer, Carl also improved the thread handling for machines with many logical cores (e.g. multi CPU/Core Systems). Before, you needed to start a local encode server together with the DCP-o-matic master GUI on the same machine to fully load your CPU during encoding, that penalty grew worse and worse with the number of logical cores. Now, running only the Master GUI already maxes out the CPU load, and with fewer threads configured in preferences. DCP-o-matic's default thread setting (equals the number of logical cores found in the machine) already comes very close to the optimum. 'Overthreading' (setting more encoding threads than the machine has logical cores) is no longer necessary, or yields very small further improvements. That also means, on multi-core machines, you get away with fewer threads set, which also means less memory usage (every thread needs a decent amount of memory). So, now especially with 4k encodes (4k needs even more memory per thread), you don't need as much memory as previously to max out your CPU. Encoding 4k at +48 threads would bring most machines into swapping, even with lot's of RAM. Now you get the same encoding performance using only half this thread setting, thus needing only half as much RAM (roughly). On not-so-fast machines, like legacy systems that you might use as encoding servers or for the occasional still conversion, there is improvement as well: v1.83 Bunny: 0.82fps (4 threads Core2D-T7200) v2.74 Bunny: 1.15fps (4 threads Core2D-T7200) That's approaching a 40% speed increase from the last 1.x release. Well done Carl and Aaron! - Carsten

9 years, 1 month

[DCP-o-matic] cinema KDM timezones

by Carsten Kurz

I noticed v2.72 establishes timezones in the cinema database. Please check your cinema database, as per default it seems that DCP-o-matic will update all cinema entries with UTC as default. That could bring trouble if you are already creating KDMs within a time zone with a large offset from UTC. So go through them one by one and get them right. Carl - I expected the time window in the KDM creation dialog to change per local UTC offset variation when I select a screen within a cinema with different UTC offset. I know it is not a must, of course. But maybe it would be helpful to indicate the UTC offset when selecting a specific screen? Hmm, I just noticed it is possible to create multiple KDMs at once by selecting multiple screens simultaneously, so that wouldn't work, as there can be multiple different time zones involved... Well I DO know it is not a good idea to create KDMs with very short time windows anyway, still it is now becoming a bit complicated to actually know what actual time frame is created because the offset is 'hidden' in the database. Hmm, maybe you can display the UTC offset after the cinema name in the list? Selecting a specific screen would always make the UTC offset visible because of the list expanding necessary to select that screen. For clarification, I extended the german translation of 'Timing' in the KDM dialog to 'Time window (local time of THIS machine!)' a while ago. I assume this is still valid (but not exclusively now)...and what the time zones now do is to adjust the displayed time window to the UTC adjusted remote locations? That is, if I choose a time frame of 03/14/2016 12:00 to 03/17/2016 12:00 there, and create a KDM for a cinema with an UTC offset of +11, it WILL result in exactly that time frame of 03/14/2016 12:00 to 03/17/2016 12:00 AT that specified location? Seems I need to adjust OR extend that translation again ;-) Well, whatever, I just played around with it and adjusted some known cinemas with fictional UTC offsets (+11 and +2) and created two KDMs simultaneously. The indicated time frame of: 03/14/2016 12:00 to 03/17/2016 12:00 resulted in the following KDM details to be created: <ContentKeysNotValidBefore>2016-03-14T12:00:00+11:00</ContentKeysNotValidBefore><ContentKeysNotValidAfter>2016-03-17T12:00:00+11:00< <ContentKeysNotValidBefore>2016-03-14T12:00:00+02:00</ContentKeysNotValidBefore><ContentKeysNotValidAfter>2016-03-17T12:00:00+02:00< When I check my database of KDMs we received over the years, there is a wild mix of time frames given either with UTC-offset=zero and absolute time adjusted, or with UTC offset. So it seems both methods are used and both work. When I send these KDMs as email, the time window is expressed as local time in the email text, so that is also what the local recipient expect, as he will always refer to these time frames in local time: 'Der Schluessel ist vom 2016-03-14 12:00:00 bis zum 2016-03-17 12:00:00 gueltig fuer:' - Carsten

9 years, 1 month

[DCP-o-matic] How to un-letterbox content with non-square pixels without distortion?

by Christian Hove

Hi, A problem that I have run into a few times: I can't find a convenient way to remove the black bars from letterboxed content with non-square pixels and non standard aspect ratio. An example: Content with letterbox (62 pixels top and bottom) is 720x576 and has a pixel aspect ratio of 1.42:1 Display aspect ratio is 1.78:1 (16:9), so the displayed image is 1024*576 including the letterbox and 1024*452 with the letterbox removed. This gives a aspect ratio of 2.27:1 which to my knowledge does not fit any of the predefined containers. - With "Scale to" set to 16:9 the picture is not distorted but shown with letterbox and not filling the container. - Cropping top and bottom bar distorts the image because the display aspect ratio is fixed and not the pixel aspect ratio. - Changing "Scale to" to "no stretch" distorts the image because the pixels are displayed square (which they really are not). So what I need is a "Scale to" option that keep the pixel aspect ratio fixed to whatever is reported with ffprobe (specified in the video header?) - That way I can crop the image without distorting it. Have I overlooked an obvious way to make the useful part of the image fit the height of the container without distortion? The example content is available here: https://www.dropbox.com/s/2qeex6oautq8vlj/06_Oscar_1.mpg?dl=0 Cheers, Christian

9 years, 1 month

[DCP-o-matic] Editing subtitles

by Carsten Kurz

Okay, got a first grip on subtitles, was never able to do much testing on this, but after teaching myself the simple Subrip format, I am able now to create test files for various issues. Now, the 'Show' Option under the Subtitle tab opens a nice list of the titles. I'm wondering wether it would be too much work to actually transform this table display into a basic editor? All one needs would be to create/delete/edit entries in start/stop/content columns, nothing fancy... I know most people will prefer external 'real' Subtitle editors for doing substantial subtitle work, but having a simple editor to clean up glitches or create individual titles would still be nice, no? - Carsten

9 years, 1 month

[DCP-o-matic] DCP-o-matic 2.7.0 released

by Carl Hetherington

Hi all, DCP-o-matic 2.7.0 is now available from: http://dcpomatic.com/download Thanks to everyone who has helped with this release, and especially Rob van Nieuwkerk, Carsten Kurz, Igor Voytovich, Tomáš Hlaváč, Tomáš Begeni, Manuel AC and Thierry Journet. Thanks also to the 19 new financial supporters we have gained since 2.6.3: Dave Fleegel, Kert Kiima, Mobiles Kino e.V., Gerhard Gruber, Desiderio Garcia Ramirez, Stéphane Wagneur, Aditya Pratama, Thierry Journet, George Mazarakis, Yohann Dedy, Karl Jacob, Gerard Manshanden, Nathan Carpenter, Juan Marin Lorenzo, Gregg Smith, the film Mandorla, Tito Oliveira, Denis Postle and Stefan Massopust. Changes in this release: New sk_SK translation from Tomáš Hlaváč. New cs_CZ translation from Tomáš Begeni. New uk_UA translation from Igor Voytovich. Updated nl_NL translation from Rob van Nieuwkerk. Updated de_DE translation from Carsten Kurz. Updated ru_RU translation from Igor Voytovich. Updated es_ES translation from Manuel AC. Updated fr_FR translation from Thierry Journet. Fix crash on seek in some cases. Fix encode progress being stuck at 99% for a (potentially) long time. Fix loading of certificates with a preamble before the BEGIN CERTIFICATE (#774). Fix problems with content file paths when using dcpomatic2_create on Windows. Fix incorrect fades when also using trim. Fix errors with embedded subtitles in some cases (#787). Fix various problems after moving content in the timeline. Fix hangs during encoding in some cases (#783). Fix estimate of required disk space to take referencing of existing DCPs into account. Fix invalid tags in Interop DCPs in some cases. Fix exception when analysing the audio of DCPs with more than 8 channels. Fix duplicate tags in output subtitle files. Fix crash when FFmpeg doesn't recognise a file's pixel format. Fix download of certificates for Dolby CAT745 and CP850 devices. Fix layout of KDM CC configuration (#793). Fix some failures to recognise image sequences in directories, especially on OS X. Fix erroneous auto-analysis of audio with non-audio content. Attempt to fix slow encodes on Windows XP (#771). Allow changes to colours of FFmpeg subtitles (#795). Add basic support for SSA subtitles, both as text files and embedded in video files (#128). Remove multi-track behaviour of the timeline for video and subtitles. Improve auto-sequencing of subtitle content. Various fixes to behaviour with repeated content (having the same text in the content list). Improve content properties for audio files (#791) Slightly improve behaviour of ‘scale to fit’ options. Use a separate file (in a configurable location) to store cinema / screen certificates (#796). Snap content to reel split points and optimise snapping speed. Add option to auto-upload to the TMS (#794). Add delete-key shortcut to remove content. Allow removal of multiple pieces of content in one click. Synchronise content list / timeline selection when the content list selection changes. Move the preview to the start of a piece of content when selecting it. Adjust sorting of image files added using ‘Add file(s)...’ Add a stored list of DKDMs to the KDM creator rather than just a load button (#767). Improve speed of encoding with high numbers of threads or encode servers (#748). Use new Dolby FTP site for both Dolby and Doremi certificates (#775). Basics of a send-to-batch-converter option (#770). Put ISDCF subtitle language in lower case if the subtitles are burnt in, as per new ISDCF name specification. Add search button to the screens list when making KDMs. Make subtitle view resizeable on all platforms (#781). Don't expand all cinemas on opening KDM dialogs (#779). Add fps count to the log on transcode finish (#786). Allow multiple CC addresses for KDM emails (#785). Add option to disable EBUR128 analysis. All the best, Carl

9 years, 1 month

Re: [DCP-o-matic] Creating DKDMs

by Carl Hetherington

On Mon, 7 Mar 2016 23:53:49 +0100 Carsten Kurz <audiovisual(a)t-online.de> wrote: > > Am 07.03.2016 um 23:31 schrieb Carl Hetherington via DCPomatic: > > > Do you have another use for those DKDMs? I mean other than > > subsequently using them in the KDM creator? > > Ah, alright... I thought I could store that DKDM as a separate file > together with the DCP, then re-open BOTH in KDM creator and proceed > from there. > > I recently had an issue where I did not create a KDM directly after > creating the encrypted DCP. So, after doing other things in DOM, I > later went into the KDM creation dialog in DOM, looked up the CPL I > wanted, then created the KDM. But it didn't work, it seems it was > using the wrong key. So I thought creating and storing a DKDM would > be the safer way to create KDMs later from the DCP and a single DKDM > file. As I create encrypted DCP rarely (actually most of the time for > testing purposes only, like for this Barco issue...), I never really > used KDM creator so far, just went in and checked the translations ;-) Yes, that's all a bit clumsy. If you make a KDM later you have to open the original project as the key for the MXFs is stored in the metadata.xml. Your approach is better in a lot of ways (in particular, the CPL details and keys are kept in one place), but it depends on the DCP-o-matic certificate/private key not changing. If you recreate those keys your DKDMs will no longer work and your DCP will be lost (as you won't have the key to decrypt it). Regards, Carl

9 years, 1 month

[DCP-o-matic] Creating DKDMs

by Carsten Kurz

Hmm, when I create an encrypted DCP, and afterwards 'Make DKDM for DCP-o-matic' - I get a dialog with the current CPL data (or browse for it) - I can click 'OK' - but where can I find that DKDM then? There is no option to set a save location for the DKDM?! At least not on my Mac... - Carsten

9 years, 1 month

[DCP-o-matic] Closed captions support

by Manuel AC

Saw a message on the forum about this. To my knowledge there is not support yet. If that's the case, I will try to prepare some test materiel and search the marking needed or other specificities to make it work. Thanks! Manuel AC -- http://akadcp.com/ https://www.facebook.com/akadcp

9 years, 1 month

[DCP-o-matic] Feature request: Automate upload to TMS

by Christian Hove

Hi, Would it be possible and make sense to add an option to the DCP tab called somethin like "Upload to TMS", that if checked would make DOM upload the DCP to the TMS after successful completion? It would be nice if this feature also worked when doing batch conversions. Cheers, Christian

9 years, 1 month

← Newer
1
...
26
27
28
29
30
31
32
...
64
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

DCP-o-matic users