Hi all.
Is it possible to "re-pack" an existing DCP without re-encoding the video?
I have a couple of DCPs which have problems with the sound so I'd like
to make a new DCP using the existing DCP video MXF and replace just the
audio tracks.
I think this came up before and I thought it was supported in DCPomatic
2. But I tried it in v2.7.1 and couldn't work out how to do it.
Importing the J2K MXF file works fine, but with colour conversion set to
"none", when it came to make the DCP, from the slowness of the process
it appeared that the video was being re-encoded rather than copied.
Did I use the wrong options, or is this not supported in DCP-o-matic at
present?
Any help much appreciated...
Jim
Hi all,
Did anyone receive an email entitled "DCP Dr. Stefan" to the email
address that you use to subscribe to the DCP-o-matic mailing list?
If so, please could you drop me an email off-list.
If you did, I apologise: it appears that the spammer may have joined
the list and then downloaded the list of subscribers. I have now
stopped this from being possible.
Kind regards,
Carl
Hi,
I'm currently trying to compile DoM on ARM CPU - Debian Jessie.
Everything go relatively smooth except for libasdcp-cth dependency which
is needed for libdcp and libsub.
Where can I get this packet?
Thanks,
Fred
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
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
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
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
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
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
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
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
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
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
Has anyone been successful in creating encrypted IOP or SMPTE DCPs for a Barco Alchemy ICMP? I have tried with 2.6.16, both in IOP and SMPTE format, SMPTE with Modified Transitional 1 and DCI specific.
DCP and KDM is ingested successfully, and the interface shows them associated, the key validity window is displayed, properties shows 'valid' 'no errors'. I can load the clip into the player, but when I hit 'Play', nothing appears, the player claims it is playing, but silently goes to stop after 5s - this is the same for every variant I tried.
I can play commercial unencrypted and unencrypted DCP-o-matic content without a problem. I also tried one time with 1.81, same result. We have not yet registered the certificate with a distributor or mastering service, so we have never received a commercial encrypted feature + KDM. Actually I was just trying to create a successful enrcypted DCP and KDM to test wether the certificate is working.
Any idea?
I have tried with both certificate downloaded from Barco database, as well as from the ICMP itself using Communicator.
The syslog contains a lot of this stuff:
---
FFBARCO user.warn SM: SM- PlayoutEventsHandler::checkFrame It is not a smpte content
Jan 21 17:23:05 FFBARCO user.warn SM: SM- PlayoutEventsHandler::checkFrame It is not a smpte content
Jan 21 17:23:06 FFBARCO user.warn SM: SM- PlayoutEventsHandler::checkFrame It is not a smpte content
Jan 21 17:23:06 FFBARCO user.warn SM: SM- PlayoutEventsHandler::addFrame No BER data, playout event cannot be logged
Jan 21 17:23:06 FFBARCO user.warn SM: SM- PlayoutEventsHandler::checkFrame It is not a smpte content
Jan 21 17:23:06 FFBARCO user.warn SM: SM- PlayoutEventsHandler::addFrame No BER data, playout event cannot be logged
Jan 21 17:23:06 FFBARCO user.warn SM: SM- PlayoutEventsHandler::checkFrame It is not a smpte content
Jan 21 17:23:06 FFBARCO user.err SM: IMB Event- Security decryption error starting at FrameId=479 on Channel=0 playBack=2
Jan 21 17:23:06 FFBARCO user.err SM: IMB Event- Audio data error pcieDataCountError=0 ddrWriteCountError=0 channelCountError=0 audioBufferIsEmpty=0 audioEnableTimeout=1
Jan 21 17:23:06 FFBARCO user.debug SM: IMB Controller- debug info 1e00: 0bad0add 00000001 60010101 00bb801c 00000080 00001001 00000000 00100000
Jan 21 17:23:06 FFBARCO user.debug SM: IMB Controller- debug info 1e20: 10000000 00000000 00000000 10000000 00000540 00010320 00010320 00000211
Jan 21 17:23:06 FFBARCO user.debug SM: IMB Controller- debug info 1e40: 00000000 1500001e 00000000 00000000 00000000 00000000 00000000 0bad0add
Jan 21 17:23:06 FFBARCO user.debug SM: IMB Controller- debug info 1e60: 00000400 0bad0add 0bad0add 0bad0add 00410505 0bad0add 0bad0add 0bad0add
Jan 21 17:23:06 FFBARCO user.debug SM: IMB Controller- debug info 1e80: 0bad0add 0bad0add 0bad0add 0bad0add 0bad0add 0bad0add 0bad0add 0bad0add
Jan 21 17:23:06 FFBARCO user.debug SM: IMB Controller- debug info 1ea0: 0bad0add 0bad0add 00000000 00400000 0000c012 00000040 00000040 0000270e
Jan 21 17:23:06 FFBARCO user.debug SM: IMB Controller- debug info 1ec0: 00000000 00ffffff 00000001 00000000 0040019f 00003333 00081000 00000333
Jan 21 17:23:06 FFBARCO user.debug SM: IMB Controller- debug info 1ee0: d3e230e2 0050f947 c19bffff 00ffffff 00000400 00000000 00000000 0bad0add
Jan 21 17:23:06 FFBARCO user.err SM: IMB Event- Security decryption error starting at FrameId=300 on Channel=2 playBack=1
Jan 21 17:23:06 FFBARCO user.err SM: IMB Event- Security decryption error starting at FrameId=479 on Channel=2 playBack=2
Jan 21 17:23:06 FFBARCO user.debug SM: IMB Controller- Notify STOPPED state for frame 8388607
---
- Carsten
>Actually I though that was possible using the frame rate input box under 'Content'->'Audio'
Sorry, that of course should read 'Content'->'Timing'->'Video frame rate'.
- Carsten
Hi all,
DoM 2.6.32:
http://dcpomatic.com/test-download
is a release candidate for 2.7.0, within the next couple of days if all is
well. Do let me know if you see any problems with this version, or have
any last-minute translation updates.
All the best,
Carl
Hi,
I have manage to convert 1 of the file to J2K format successfully. But i
need your guidance how to convert the 30second file in to the MPEG2D
(E-Cinema) format.
Kindly advice
*.*
Regards,
Pradeep
It seems the reason for this issue has been a flaw in the ICMP. Barco issued a new software service release a few days ago with the documentation listing exactly the error I was getting in the syslog:
Does anyone know what 'frame HMACs' are?
I have yet to install this software and test it with a DOM DCP, but I do assume it will be fixed with it.
- Carsten
Still trying to get a grip on our Barco certificate issue.
What I don't understand is - there seem to be certificate/pem files with one, or multiple certificate blocks in them (multiple '-----BEGIN CERTIFICATE-----' '-----END CERTIFICATE-----' blocks).
Sometimes when I request a certificate, I get a single .pem file, sometimes I get multiple files. I understand there are separate certificates for J2K and MPEG-2, and also certificates that include the root chain or not.
E.g. when I download my ICMP certificate from the ICMP itself, I get an 8KB BARCO-ICMP-9730000916.pem.
When I request it from Barco, I get a ZIP file with two files:
Barco-ICMP.9730000916_cert.pem 4kB
Barco-ICMP.9730000916_chain.pem 8kB
Which of the two are actually needed for KDM creation? DOM seems to accept both - but when I create encrypted DCPs, neither works.
The two 8kB files are bit-identical.
I received a Doremi certificate file that I used sucessfully with DOM to create and play an encrypted DCP - but that file only contained a single certificate block. How can it be those certificate files are so different?
For this Doremi server, the Doremi FTP site delivers a ZIP with SIX certificate files:
dcp2000-254124.cert.mpeg.pem - 4kB
dcp2000-254124.cert.sha256.pem - 4kB
dcp2000-254124.cert.sms.pem - 4kB
dcp2000-254124.chain.mpeg.pem - 12kB
dcp2000-254124.chain.sha256.pem - 12kB
dcp2000-254124.chain.sms.pem - 12kB
I would think that the mpeg.pem is for MPEG2-Interop KDMs, sha256.pem is for J2C-SMPTE-KDMs, and that sms.pem is for verifying signed log files from the server?
I understand that chains will not only contain the device certificate itself, but also it's parent-certificate, in the case of the Barco ICMP e.g. leading the device cetificate back to Barco. As such, I would assume that for KDM creation, a software would be able to work with both types of files? How will a software know which is which, when the number of certificate blocks differ between devices?
- Carsten
Hi all,
Has somebody any experience with loudness audio normalisation?
I personally use it in case of BD / DVD authoring to normalise all the
sounds.
It seems to be the most recent for broadcasting, as the mean audio level
does not analyse the audio frequency spectrum.
Loudness seems to be the closest to the human response.
ffmpeg has this filter: (https://ffmpeg.org/ffmpeg-filters.html#ebur128-1)
ffmpeg -nostats -i input -filter_complex ebur128 -f null -
"I" gives the value of the integrated loudness. The optimal value for
broadcasting seems to be -23 LUFS.
This filter does not give any indication of the peak, so the classic
analyse would be necessary to avoid saturation.
Anyone thinks that this analyse could be useful for DoM?
Lilian
Recently an Indie film has been distributed to german cinemas which seems to mix Interop and SMPTE packaging. This is, of course, forbidden, but I think DOM currently doesn't block this approach. I guess that currently it is possible to refer to an SMPTE wrapped MXF from within an Interop VF or vice versa.
I guess DOM should look at the MXF headers and/or Metadata and at least issue a warning immediately and demands to adjust the DCP type.
- Carsten
Hi,
I have received an error report of a dcp made with DoM 2.6.3 on Windows.
The report came from the easyDCP player software.
There seems to be something wrong with the subtitle track.
Does anyone had something like this before?
Attached you’ll find the report.
All the best,
Tom
<http://www.aceimagefactory.net/>
TOM MULDER
DI COLORIST
tom(a)aceimagefactory.net <mailto:tom@aceimagefactory.net>
+32 498 35 88 09 | LinkedIn <https://be.linkedin.com/in/muldertom>
www.aceimagefactory.net <http://www.aceimagefactory.net/>Fabriekstraat 43 | 1930 Zaventem - Belgium | +32 2 735 60 20
Not sure if DOM already respects this, but if really some systems
counts the underscores, may be worth a look. It's from the ISDCF list.
"There MUST be an entry in EVERY field. Some systems count the
number of "_" (underscores) to parse the information (NOT
RECOMMENDED - BUT it's done). If you have a non- relevant field,
fill it with the letters "NULL"
This may explain all the naming errors we get from dcp_inspect that
are not really errors.
Manuel AC