There seems to be an issue with encrypted SMPTE DCPs on Sony SRX-R510/515 (XCT-S10 Server) machines.
While unencrypted and encrypted INTEROP DCPs work, as well as unencrypted SMPTE DCPs, encrypted SMPTE DCPs do not work. They seem to ingest fine, and the KDM is properly attached to the content, but when trying to play, it gives an error: 'CPL xxx is not playable. Time period of the CPL or KDM is not present.'
KDM type is Modified Transitional 1.
This may be a Sony specific issue, but maybe someone has an idea what is going on. Seems that a signature method for the CPL or MXF is not supported or handled properly?
Logs show:
--- bad log ---
imb.log
Sep 3 16:07:36 sh local1.notice mba[1592]: ply:parser_cpl.c:0581::ContentTitleText: "test for Sony"
Sep 3 16:07:36 sh local1.notice mba[1592]: ply:play_check_func.c:0110::MbPlayIsEncryptedCPL:Enc(v)
Sep 3 16:07:36 sh local1.notice mba[1592]: ply:play_check_func.c:1083::SMPTE format CPL [64F16A5977B842A88116E8EDBE8B01AC] Enc:1
Sep 3 16:07:36 sh local1.err mba[1592]: agt:common/xml_verify.c:0329::__checkFormatType: Not Supported this SignatureMethod attribute.
Sep 3 16:07:36 sh local1.err mba[1592]: agt:common/xml_verify.c:0330::__checkFormatType: sigAlgType = [0].
Sep 3 16:07:36 sh local1.err mba[1592]: agt:common/xml_verify.c:0729::mandatory field [fomatType] error
Sep 3 16:07:36 sh local1.err mba[1592]: ply:validation.c:0793::MbPlayVerifyCPLData(): Cert Format Error
Sep 3 16:07:36 sh local1.notice mba[1592]: ply:validation.c:0393::GetHashValuefromCPL(): CPLID = urn:uuid:64f16a59-77b8-42a8-8116-e8edbe8b01ac
Sep 3 16:07:36 sh local1.notice mba[1592]: ply:validation.c:0533::Number of Assets 2 from CLIENT, 2 in CPL. res = 0
Sep 3 16:07:36 sh local1.notice mba[1592]: ply:play_check_func.c:0892::mode[2] 0:low 1:middle 2:high
Sep 3 16:07:36 sh local1.err mba[1592]: ply:play_check_func.c:0914::SHOW START FAILED VERIFY: Verify=NG cpl_id=64F16A5977B842A88116E8EDBE8B01AC
--- end bad log ---
While with proper CPL/KDM, this should be (this example is provided by Sony, but it seems this is unencrypted, so, no proof):
--- good log ---
imb.log.6
Aug 26 08:56:09 sh local1.notice mba[1585]: ply:parser_cpl.c:0581::ContentTitleText: "SKYFALL_TLR-C-CCAP_S_EN-MULTI_51_4K_SPE_20121005_SMPTE_TDC"
Aug 26 08:56:09 sh local1.notice mba[1585]: ply:play_check_func.c:1083::SMPTE format CPL [5868E4BDA14744E898AD8F928F4B1AC0] Enc:0
Aug 26 08:56:09 sh local1.err mba[1585]: agt:common/xml_verify.c:0452::mandatory property of Reference URI=[]
Aug 26 08:56:09 sh local1.notice mba[1585]: agt:common/xml_verify.c:0615::mandatory field of Reference DigestValue=[t8lSROJD8AO3pJJOFyiAJZAsr7w=]
Aug 26 08:56:09 sh local1.notice mba[1585]: agt:common/xml_verify.c:0616::Reference Validation of DigestValue =[t8lSROJD8AO3pJJOFyiAJZAsr7w=]
Aug 26 08:56:09 sh local1.err mba[1585]: agt:common/xml_verify.c:0623::DigestValue validation is success
Aug 26 08:56:09 sh local1.notice mba[1585]: ply:validation.c:0805::MbPlayVerifyCPLData(): MtXMLVerifyCertChain() res = [0]
Aug 26 08:56:09 sh local1.notice mba[1585]: ply:validation.c:0393::GetHashValuefromCPL(): CPLID = urn:uuid:5868e4bd-a147-44e8-98ad-8f928f4b1ac0
Aug 26 08:56:09 sh local1.notice mba[1585]: ply:validation.c:0533::Number of Assets 8 from CLIENT, 8 in CPL. res = 0
Aug 26 08:56:09 sh local1.notice mba[1585]: ply:play_func.c:0932::mbPlayPrepCplVerify(): CPL Check rtn = 0 (0x00)
Aug 26 08:56:09 sh local1.notice mba[1585]: ply:play_func.c:0941::mbPlayPrepCplVerify(): KDM Check rtn = 0 (0x00)
Aug 26 08:56:09 sh local1.notice mba[1585]: com:btp/btp_log.c:0188::ES PLAY PREP CPL 0x9166 rs 0x0000 0x00000004
--- end good log ---
- Carsten
Hello!
I tried to import a video file with the cineform codec inside.
Dcp-o-matic 1.82 does not import it, just saying "could not find video
decoder", dcp-o-matic 2.1.5 crashes while importing. Is there a trick to
do it, or is it just not possible to import cineform codec?
Thank you
Andi
Hi all,
DCP-o-matic 1.82.0 is released, and it includes:
Fix for crashes or colour errors on left/right crop in some circumstances.
Fix to recognise .w64 and .flac as audio files.
New da_DK translation from Anders Uhl Pedersen.
Fix display of non-Latin characters in some cases on Windows.
Use 96kHz DCP audio when sources are sampled at more than 48kHz.
Thanks to Anders Uhl Pedersen and Patrick Haderer.
Get it from http://dcpomatic.com/download
All the best,
Carl
Hi all,
The 2.x branch of DCP-o-matic is now in "string freeze" for the 2.2.0
release. That means that none of the translatable strings will change
before 2.2.0, so now would be a good time for translators to send any
updates to their i18n files.
I know we experimented with Zanata but there weren't really any positive
remarks about it so if it's ok with everyone I will stick with the old
method of editing .po files...
Current i18n status and information is here:
http://dcpomatic.com/i18n
Please don't hesitate to send any queries to the list or to me directly.
Thanks and best regards,
Carl
Hello all.
I just realised that I sent the message below a while back only to Carl
and not the list.
Can anyone shed any light on how to deal with video which has "headroom"
in the signal (i.e. white is not completely white, black is not
completely black)?
Many thanks,
Jim
On 22/06/2015 17:19, Jim Dummett wrote:
> Hi Carl.
>
> Hmm... I must admit I'm a bit baffled. We've been using sRGB setting
> as standard and found it gives the best results. I'm going to have to
> do further tests in a cinema.
>
> This may be related to another question which I've been meaning to ask
> for a while...
>
> As far as I'm aware, standard output from Final Cut Pro 7 to ProRes
> Quicktime places black at value of 16, white at 235 (out of full gamut
> of 0-255 for 8-bit encoding). i.e. it leaves headroom above white and
> below black, so there can technically be levels which are "whiter than
> white". This I guess is to be compatible with the broadcast TV world,
> where levels below 16 and above 235 are considered out of gamut and
> illegal.
>
> Presumably, though, a DCP can use the full spectrum of 0-255. So pixel
> which has luminance level of 16 would be dark grey rather than
> completely black.
>
> So... how does one take that into account in the colour conversion to
> XYZ space? Does DCP-o-Matic's transform do this already? I believe in
> DVS Clipster there is an option for this where you select whether the
> source's black and white levels are "full" (0-255) or "head" (16-235)
> and performs the transform accordingly.
>
> I wonder if the reason why we've found sRGB encoding works is that the
> gamma skew it introduces roughly compensates for the input not being
> full gamut? But, even if that is the case, it's clearly not the right
> way to do it.
>
> Apologies if the above is a bit confused or erroneous. In truth I find
> the intricacies of colour space hard to get my head around (tried to
> read your and Dennis Couzin's paper on the subject, but the maths were
> well above my level). But if anyone has any ideas on this subject,
> would love to hear them.
>
> Many thanks,
>
> Jim
>
>
> On 21/06/2015 16:42, Carl Hetherington via DCPomatic wrote:
>> Hi Jim,
>>
>>> While teaching a group of people how to use DCP-o-matic last weekend
>>> (DCP-o-matic is now on the syllabus at London Film School!), I came
>>> across the change in v1.79.0 that default colour space conversion is
>>> now
>>> Rec709.
>>>
>>> For the majority of the people who'd brought their film to test on, we
>>> found that sRGB was the best setting for them. We were comparing their
>>> source files (mostly Quicktime) to the resulting DCP viewed in Doremi
>>> Cineplayer (evaluation version) and found that Rec709 was changing the
>>> colour balance of the image (most notably, making it darker).
>>>
>>> What was the rationale for changing the default to Rec709?
>> Rec. 709 is thought to be the best guess for HD (i.e. roughly 2K pixels
>> across) material; it is the default output from Final Cut Pro 7, for
>> example.
>>
>>> And is there any way to examine a Quicktime file to find out what
>>> colour
>>> space it's in? With shorts filmmakers, they often don't know
>>> themselves!
>> There is, unfortunately, no easy way to do this. There are some
>> QuickTime headers that you can read with tools such as QT Edit
>> (http://www.digitalrebellion.com/promedia/) but I haven't personally
>> tried that.
>>
>>> Presumably the default output from Final Cut Pro, Premiere Pro etc
>>> remains sRGB rather than Rec709?
>> This would seem unlikely. Almost all "video" formats represent colour
>> as YUV, not RGB, so use of the sRGB colour conversion settings doesn't
>> make much sense.
>>
>> It's strange that sRGB is closer to Cineplayer for you than Rec. 709.
>> If you use sRGB with DCP-o-matic you are going to get a gamma
>> correction which results in a lighter image than that for Rec. 709, and
>> it is odd that Cineplayer "agrees" with that lighter gamma.
>>
>> Have you ever compared the output of Cineplayer on your system to a
>> projected image? Is it accurate?
>>
>> Best regards,
>> Carl
>>
>>
>> _______________________________________________
>> DCPomatic mailing list
>> DCPomatic(a)carlh.net
>> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
>
I am away from the cinema from 5th August until 25th August and will have limited access to emails.
For business related matters please contact rebecca(a)saffronscreen.com.
For technical matters please contact andy(a)saffronscreen.com.
Thanks
Paul
I am away from the cinema from 5th August until 25th August and will have limited access to emails.
For business related matters please contact rebecca(a)saffronscreen.com.
For technical matters please contact andy(a)saffronscreen.com.
Thanks
Paul
I am away from the cinema from 5th August until 25th August and will have limited access to emails.
For business related matters please contact rebecca(a)saffronscreen.com.
For technical matters please contact andy(a)saffronscreen.com.
Thanks
Paul
I am away from the cinema from 5th August until 25th August and will have limited access to emails.
For business related matters please contact rebecca(a)saffronscreen.com.
For technical matters please contact andy(a)saffronscreen.com.
Thanks
Paul
