4 Dec
2015
4 Dec
'15
6:08 p.m.
Hi. This topic has been discussed on the forum, but I was wondering if any
of you have had DCPs work on Sony gear? I tested a 4K & 2K, encrypted & non
on Sony RX320 and 515 and all failed to play on both projectors. These were
SMPTE DCPs.
Has anyone had luck on these systems?
Do you think Interop would maybe work instead?
Thanks!
-Parke
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parke Gregg
Colorist/Editor/Project Finisher
Stuck On On
www.stuckonon.com
512.535.4760
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11:58 p.m.
There is an unresolved issue with encrypted SMPTE DCPs on Sony SRX-R515. I would assume
that the same problem exists for the R320. Unencrpyted SMPTEs and unencrypted/encrypted
IOPs should work, though.
- Carsten
5 Dec
5 Dec
2:44 a.m.
Thanks Carsten. On Monday I will be testing an interop and I'll report
back. In my past (limited) testing I could not get Unencrypted SMPTEs to
work either, but worked fine on Dolby and Doremi gear.
Thanks again for your and Ezequiel's help.
-Parke
On Fri, Dec 4, 2015 at 5:58 PM, Carsten Kurz via DCPomatic <
dcpomatic(a)carlh.net> wrote:
There is an unresolved issue with encrypted SMPTE DCPs
on Sony SRX-R515. I
would assume that the same problem exists for the R320. Unencrpyted SMPTEs
and unencrypted/encrypted IOPs should work, though.
- Carsten
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
--
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parke Gregg
Colorist/Editor/Project Finisher
Stuck On On
www.stuckonon.com
512.535.4760
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2:55 a.m.
Try to get out some kind of log or report, or at least note the error
reported. That will help a lot to figure out what's going on.
Maybe unsigned DCPs are the problem?
On Fri, Dec 4, 2015 at 9:44 PM, Parke Gregg via DCPomatic
<dcpomatic(a)carlh.net> wrote:
Thanks Carsten. On Monday I will be testing an interop
and I'll report back.
In my past (limited) testing I could not get Unencrypted SMPTEs to work
either, but worked fine on Dolby and Doremi gear.
Thanks again for your and Ezequiel's help.
-Parke
On Fri, Dec 4, 2015 at 5:58 PM, Carsten Kurz via DCPomatic
<dcpomatic(a)carlh.net> wrote:
There is an unresolved issue with encrypted SMPTE DCPs on Sony SRX-R515. I
would assume that the same problem exists for the R320. Unencrpyted SMPTEs
and unencrypted/encrypted IOPs should work, though.
- Carsten
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
--
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parke Gregg
Colorist/Editor/Project Finisher
Stuck On On
www.stuckonon.com
512.535.4760
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
10:36 a.m.
Am 05.12.2015 um 03:44 schrieb Parke Gregg:
Thanks Carsten. On Monday I will be testing an interop
and I'll report back. In my past (limited) testing I could not get Unencrypted SMPTEs
to work either, but worked fine on Dolby and Doremi gear.
The Sonys are a bit weird with their verification process. On the 220/320, this is an
additional pass.
On the 515, it's integrated with the ingest, as with other servers. Still, a lot of
(even commercial) DCPs are marked 'invalid', yet play. I have done some testing on
this, but did not get fully through. On our Sony 515 and others we never had a real issue
with any DCP created by DCP-o-matic though, except for some 25fps IOP that was created
with some version of DVD-o-matic. It may be that Sonys verification checks other things,
maybe a root chain or future SMPTE aspects. Or it's just broken.
For encrypted SMPTE DCPs, it complaints about a bad signing method in the KDM, if I
remember right, so it's not actually a problem with the DCP, but the KDM it seems.
We forwarded this issue to Sony already, but have gotten no answer so far. This is not
only an issue with DCP-o-matic, I know of one commercial DCP creation package with the
same problem.
When creating encrypted DCPs, either IOP or SMPTE, use only the KDM type 'Modified
Transitional 1'.
- Carsten
2:36 p.m.
On Sat, 5 Dec 2015, Carsten Kurz via DCPomatic wrote:
Am 05.12.2015 um 03:44 schrieb Parke Gregg:
Has anyone tested whether unsigned DCPs work any better?
Carl
Thanks Carsten. On Monday I will be testing an
interop and I'll report back. In my past (limited) testing I could not get Unencrypted
SMPTEs to work either, but worked fine on Dolby and Doremi gear.
The Sonys are a bit weird with their verification process. On the 220/320, this is an
additional pass.
3:49 p.m.
As unsigned is only an option for unencrypted, this never made a difference for me, as
unencrypted IOPs and SMPTEs always worked for me.
This 'failed' validation on the 515 is not a show stopper. It doesn't seem to
mean there is actually something wrong with the DCP. Even commercial trailers and movies
are sometimes flagged like that.
I also tried 'DCI any' and 'DCI specific' KDMs with SMPTE DCPs on the
Sony, but they didn't work at all.
The Modified Transitional 1 KDM ingests fine with an encrypted SMPTE DCP. It is also
'assigned' to that DCP in the library. But when you try to start playback, the
Sony says 'Time period of the CPL or KDM is not present', which is the Sonys
normal way of saying that there is no valid KDM for the current date and time.
In the log, you will find:
---
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
---
I have to say, though, that all my tests were with 1.xx. But I can do more tests now with
2.6.x.
- Carsten
11:05 p.m.
On Sat, 5 Dec 2015 16:49:06 +0100
Carsten Kurz via DCPomatic <dcpomatic(a)carlh.net> wrote:
[snip]
---
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
---
I can only imagine that this refers to the signature's SignatureMethod
tag, which contains a single (required) "Algorithm" attribute. Very
strange.
The apparent "fomatType" typo is odd as well...
Carl
7 Dec
7 Dec
9:09 p.m.
A signed unencrypted 4K interop DCP we created with 2.6.3 was tested today,
and put the projector into "Emergency State". This is the same problem
we've encountered in the past with SMPTE DCPs on Sony gear. I'm about to
make a couple more varieties for testing. Should I try it unsigned?
Carsten, where are these log files located? Possibly I can ask the
projectionist to send them. Previously he didn't know how to access them.
-Parke
On Sat, Dec 5, 2015 at 5:05 PM, Carl Hetherington via DCPomatic <
dcpomatic(a)carlh.net> wrote:
On Sat, 5 Dec 2015 16:49:06 +0100
Carsten Kurz via DCPomatic <dcpomatic(a)carlh.net> wrote:
[snip]
--
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parke Gregg
Colorist/Editor/Project Finisher
Stuck On On
www.stuckonon.com
512.535.4760
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
---
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
---
I can only imagine that this refers to the signature's SignatureMethod
tag, which contains a single (required) "Algorithm" attribute. Very
strange.
The apparent "fomatType" typo is odd as well...
Carl
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
9 Dec
9 Dec
10:20 p.m.
The problem occurred on play with a 515. But I've uncovered a few things
that may eliminate DCPomatic from being the cause of the recent problems I
am having. Just as Carsten has always said, I too have now had success with
unencrypted 4K and 2K, signed and unsigned interop DCPs on Sony gear (515).
Our workflow has always been to export XYZ J2C files from our DI tools.
Import them into our DCP tools for wrapping, audio, etc. This works great
for 2K but always had problems with 4K on Sony gear. I now know there is
something the Sony gear does not like about my 4K images. This last test, I
had a version with my normal process and also I exported an XYZ tif
sequence and used DCPoM to generate the j2c/mxf compression. Using DCPoM
for compression worked perfectly for playback. Using my DI tools for 4K j2c
caused the "Emergency State". I've tried this with other authoring tools
and all did the same thing. 2K with this old process (and making interop
DCPs) works great, it's just 4K, and only on Sony gear. I have not tested
encryption, so I don't know if a problem still persists there.
I'm going to be trying to figure out my 4K j2c problem, but in the interim
use DCPoM for compression.
One question... Is there any downside to making Interop DCPs? To date, I've
always made SMPTE, but seem to need to shift for full compatibility.
Thanks,
Parke
On Mon, Dec 7, 2015 at 5:31 PM, Carsten Kurz via DCPomatic <
dcpomatic(a)carlh.net> wrote:
Am 07.12.2015 um 22:09 schrieb Parke Gregg via DCPomatic:
--
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parke Gregg
Colorist/Editor/Project Finisher
Stuck On On
www.stuckonon.com
512.535.4760
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A signed unencrypted 4K interop DCP we created
with 2.6.3 was tested
today, and put the projector into "Emergency
State".
Wow, was that an R220/R320? On play, or during ingest?
- Carsten
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
11:18 p.m.
New subject: [DCP-o-matic] SMPTE DCPs
Am 09.12.2015 um 23:20 schrieb Parke Gregg:
One question... Is there any downside to making
Interop DCPs? To date, I've always made SMPTE, but seem to need to shift for full
compatibility.
Occasionally people show up and say 'IOP' is outdated, 'SMPTE' is the
future. While there is SOME truth in this, it is a fact that currently all (but some very
few) commercial DCPs delivered to cinemas are still IOP - features as well as trailers and
ads. I could browse through all our DCP CPL/KDM database of the last 3 years and
wouldn't find a single occurrence of SMPTE DCPs. Except for those that I created
myself with DCP-o-matic for test use only ;-)
There is no penalty with using Interop. Even 25fps Interop, which is 'formally'
wrong, works on most servers nowadays.
Some people mix the 'old' MPEG2-Interop with generic 'Interop'. And in so
far, they would be right, 'MPEG2-Interop' is not used anymore.
The only DCPs actually being delivered in SMPTE wrapping currently are ATMOS and HFR DCPs,
because SMPTE formatting is needed to support HFR and ATMOS. But then even the 5.1 and 7.1
or 24fps versions of these features are delivered in IOP again.
This is a statement from the recent ISDCF meeting notes, regarding the future switch to
SMPTE DCPs:
---
SMPTE-DCP:
Disney’s movie “Finest Hours” in January is planned to be issued in SMPTE-DCP over DCDC
locations. Norway and Holland for “Finest Hours” SMPTE-DCP as well. This should be with
feature set similar to Test Package B (including CPL metadata and markers).
Warner Bros. is going to release “How to be Single” on Valentines Day. - hard drive and
DCDC - fairly wide release - US for sure, probably Canada, not International. Plan for NO
Interop-DCP (except in emergency). First drive out 2 weeks prior WITH ISDCF Test content
B1/B2 with instructions for playback on all screens.
All other studios interested, but nothing planned at this time.
---
So, even in 2016, 'real' SMPTE-DCPs will only turn up in small controlled
environments.
Also, bear in mind that 'SMPTE-DCP' actually refers to some formal changes in the
wrapping, as well as certain optional extensions (like CPL Metadata, audio track
assignments, markers, etc.) .
However, a SMPTE DCP does not need to carry ANY of these extensions, while still being
formally correct. Carl may comment on this, but so far I think DCP-o-matic is only
creating that smallest denominator when creating SMPTE-DCPs. And that's why they work
on existing servers already now.
Even the first commercial SMPTE releases announced for early 2016 will probably be of this
type. It will be a long time until the full feature set will be seen in common use. Even
then, IOP will still have to be supported for compatibility reasons.
Long story short - use IOP!
- Carsten
11:41 p.m.
New subject: [DCP-o-matic] SMPTE DCPs
I completely disagree with perpetuating the Interop standard.
SMPTE keeps evolving, and it's not at a dead end like Interop. Proper
25 and 30 fps, more reliable subtitles, and hoping that the near
future brings more interesting metadata support and uses in the
servers and TMS.
My humble opinion.
Manuel AC
On Wed, Dec 9, 2015 at 6:18 PM, Carsten Kurz via DCPomatic
<dcpomatic(a)carlh.net> wrote:
Am 09.12.2015 um 23:20 schrieb Parke Gregg:
One question... Is there any downside to making Interop DCPs? To date, I've
always made SMPTE, but seem to need to shift for full compatibility.
Occasionally people show up and say 'IOP' is outdated, 'SMPTE' is the
future. While there is SOME truth in this, it is a fact that currently all
(but some very few) commercial DCPs delivered to cinemas are still IOP -
features as well as trailers and ads. I could browse through all our DCP
CPL/KDM database of the last 3 years and wouldn't find a single occurrence
of SMPTE DCPs. Except for those that I created myself with DCP-o-matic for
test use only ;-)
There is no penalty with using Interop. Even 25fps Interop, which is
'formally' wrong, works on most servers nowadays.
Some people mix the 'old' MPEG2-Interop with generic 'Interop'. And in so
far, they would be right, 'MPEG2-Interop' is not used anymore.
The only DCPs actually being delivered in SMPTE wrapping currently are ATMOS
and HFR DCPs, because SMPTE formatting is needed to support HFR and ATMOS.
But then even the 5.1 and 7.1 or 24fps versions of these features are
delivered in IOP again.
This is a statement from the recent ISDCF meeting notes, regarding the
future switch to SMPTE DCPs:
---
SMPTE-DCP:
Disney’s movie “Finest Hours” in January is planned to be issued in
SMPTE-DCP over DCDC locations. Norway and Holland for “Finest Hours”
SMPTE-DCP as well. This should be with feature set similar to Test Package B
(including CPL metadata and markers).
Warner Bros. is going to release “How to be Single” on Valentines Day. -
hard drive and DCDC - fairly wide release - US for sure, probably Canada,
not International. Plan for NO Interop-DCP (except in emergency). First
drive out 2 weeks prior WITH ISDCF Test content B1/B2 with instructions for
playback on all screens.
All other studios interested, but nothing planned at this time.
---
So, even in 2016, 'real' SMPTE-DCPs will only turn up in small controlled
environments.
Also, bear in mind that 'SMPTE-DCP' actually refers to some formal changes
in the wrapping, as well as certain optional extensions (like CPL Metadata,
audio track assignments, markers, etc.) .
However, a SMPTE DCP does not need to carry ANY of these extensions, while
still being formally correct. Carl may comment on this, but so far I think
DCP-o-matic is only creating that smallest denominator when creating
SMPTE-DCPs. And that's why they work on existing servers already now.
Even the first commercial SMPTE releases announced for early 2016 will
probably be of this type. It will be a long time until the full feature set
will be seen in common use. Even then, IOP will still have to be supported
for compatibility reasons.
Long story short - use IOP!
- Carsten
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
10 Dec
10 Dec
11:37 a.m.
New subject: [DCP-o-matic] SMPTE DCPs
However, a SMPTE DCP does not need to carry ANY of
these extensions, while still being formally correct. Carl may comment on this, but so far
I think DCP-o-matic is
only creating that smallest denominator when creating SMPTE-DCPs. And that's why they
work on existing servers already now.
Right, DoM is not currently putting anything in the SMPTE DCPs that it
can't put in the Interop ones (i.e. it's not doing anything fancy).
Cheers,
Carl
3426
days inactive
3432
days old
14 comments
5 participants
participants (5)
-
Carl Hetherington -
Carsten Kurz -
Ezequiel Gilardoni -
Manuel AC -
Parke Gregg