Hi Carsten,
Interesting... do you have any CPLs from encrypted DCPs that do play?
Alternatively, maybe it's the signature of the KDM that it is
complaining about... it's odd that only encrypted ones fail. There's
no difference between unencrypted and encrypted CPLs coming out of DoM
apart from the key ids for the assets.
If only that error said "not supported this signaturemethod attribute X." ;)
Regards,
Carl
On Tue, 8 Sep 2015 12:47:38 +0200
Carsten Kurz via DCPomatic <dcpomatic(a)carlh.net> wrote:
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