DCP acts weird when digested into a doremi server plugged to a RealD DLP

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create the DCP using Open Cinema Tools (SMPTE). I also made as Interop 
format with "using hand-made hacks" based on what I've read here (getting 
the UUID and Hash metatags and then editing the XML files (The Interop was 
done using the same J2C files generated by Open Cinema Tools GUI).
2. Load the DCP inside the doremi server + ??? = PROFIT! (just kidding).
3. The doremi server reads both SMPTE and Interop with no problems (tested 
it myself today, and also that information is available on the doremi 
documentation).

What is the expected output? What do you see instead?
Expected output is to watch the bloody movie on the silver screen.
I get no audio, and the screen only shows a flickering green screen.

What version of the product are you using? On what operating system?
The current downloadable version of OpenCinemaTools and the tools available 
in it. No third party/updated versions of asdcp or anything else since I 
don't have the tools to "build" them.
Using Windows Vista 64bit

Please provide any additional information below.
When I open any of the JPG2000 files on an image viewer, it looks like 
anything but the expected image (see attached image... that must surely 
look cool in Stereo...)
Also, my final images are at 1998x1080 because that's one of the framesizes 
created by the demo version of CineAsset I'm also using. I don't know if I 
should go for 2048x1080 as according to CineAsset "that resolution is not 
DCI-compliant"
While browsing the asdcp-test flags, I noticed there's one to encrypt the 
mxf headers (-e), and another one to create unencrypted mxf files (-E). The 
default is to create encrypted files so maybe that's why I didn't get any 
video nor audio whatsoever? I'm currently creating another set of DCPs, 
with encryption OFF just to see if that's the problem.

Anyway, any ideas would be very helpful

Original issue reported on code.google.com by sergio.o...@gmail.com on 5 Feb 2010 at 11:17

Attachments:

• Capture.JPG

[GoogleCodeExporter]

Hi Sergio

to help you please provide any useful info; is your project 2D or 3D?
What software and format used for the first stream output, i mean, did you 
export 
correctly 32bpc TIFF file from your editing suite and convert them with 
Openjpeg 
codec cinema2k 24 attribute?

The fickering green-screen appears as to be a codec problem cause CINECERT 
ASDCP 
tool is only a wrapper and Opencinematools (especially mkcpl) a parser.

Tim (Milan - Italy)

Original comment by timothy_...@hotmail.com on 6 Feb 2010 at 11:01

[GoogleCodeExporter]

Give me a reason to answer you and I'll do that ! I know the case  but must 
have a 
serious reason to answer for free.

Original comment by rado.mar...@gmail.com on 6 Feb 2010 at 11:05

[GoogleCodeExporter]

P.S. If the peoples here are deep profesionals they immediatelly must know what 
the 
reason is because is very simple.

Original comment by rado.mar...@gmail.com on 6 Feb 2010 at 11:07

[GoogleCodeExporter]

timothy: sorry I forgot to mention I was making a clip for 3D.
I use After Effects CS4 for color-space conversion and TIFF sequence generation 
at 
16bit files as the DCI specs state.
The J2000 file looks like that when I open it on an image editor, but if I use 
easyDCP Player, the movie looks just fine (although it does show the yellowish 
tone 
due to the XYZ conversion).
I am inclined to think I should have used the "-cinema2k 48" attribute because 
the 3D 
movies run at 48fps, so your j2000 files must be around 600kb each, while 2D 
movies 
allow for 1.3mb j2000 files :p

I could try to generate the J2000 files with a third party image viewer, but I 
don't 
think it's going to work since those apps don't really have a "save files as 
digital 
cinema compliant jpg 2000 images" heh

rado: judging by your posts on this board I think you should give me a serious 
reason 
to ask you for the answer, as you simply are the troll around here and seem not 
to 
know much about this subject.

Thanks for playing, though, but I'd rather exchange ideas with those who know 
what 
they talk about and don't waste everybody else's time with useless comments :)

Original comment by sergio.o...@gmail.com on 6 Feb 2010 at 8:45

[GoogleCodeExporter]

Hi Sergio

in that case you're right; you must use cinema2k 48 argument in j2k coding and 
also 
asdcp wrapping should be done using 48 frame rate argument switch. (and due to 
the 
rule of actual opencinematools release SMPTE UL instead of INTEROP one)
Then re-create package with opencinematools and try to playback again; report a 
feed!

Tim

Original comment by timothy_...@hotmail.com on 7 Feb 2010 at 2:25

[GoogleCodeExporter]

well I encoded the J2K files at 48fps, however when I use the "-p 48" flag on 
asdcp I 
get this:
Stereoscopic wrapping requires 24 fps input str
Program stopped on error.
The file format is not proper OP-Atom/AS-DCP.

The xml files set a framerate of 48, though:
<FrameRate>48 1</FrameRate>

So, in theory it should work, maybe :p
The only way to know is by feeding this DCP into the server.

Original comment by sergio.o...@gmail.com on 7 Feb 2010 at 5:38

[GoogleCodeExporter]

just in order to show that I know MORE than lot of peoples here. There was 
clear 
that JPEG encoding was done using -cinema2k 24 instead of -cinema2k 48 that is 
right 
because 3D is 48 fps and sumary bit rate must not esceed rate for 24fps. Also 
please 
read CAREFULLY asdcp=test manual and after that do stupid experiments ! Just 
for 
your informations not all the server a "angry" on double rate Sony for example 
accept also double bit rate (2x 24 fps) becasue sony work with 4k bit rate (4 
times 
2K bit rate) but doremi labs in not best one on the market and he cannot proces 
JPEG2000 stream if he oversize DCI specs.(e.g. have double rate of 24 fps. For 
that 
reason I said in my previous post that reason is very simpleand you MUST know 
DCI 
specs and SMPTE standarts before deal with open cienmatools. Unfortunatelly 
with 
EVERY post you PROOVE that you don't know him and ask questions that you must 
not 
ask if you are experiences in the domain. And YOU loosing time (and money) to 
other 
peoples asking autoanswering question here. Please remember there are nofree 
lunch i 
n the earth. Also if you understand DCI you will not ask question and just do 
nussiness with profesional tools. If you don'tknow DCI/SMPTE you will ask a lot 
of 
questions loosing our (and others) time,but without any sense - nobody can help 
you 
in every stupid step/actionyou can do. So understanding DCI - DO yourself DCP - 
C+OCTaperfect for experienced peoples - Don't know DCI/SMPTE go and buy 
profesional 
software as I say nobody can(and willing to) help you.

Original comment by rado.mar...@gmail.com on 8 Feb 2010 at 10:57

[GoogleCodeExporter]

Hey Tim, I was going to write earlier but I've been super busy.
As I thought, using the 48fps flag was all I needed. the clip played back just 
fine and  
I have to say it looked very nice in 3D (I made a conversion to 3D of a part of 
the 
short film I directed last year).

Original comment by sergio.o...@gmail.com on 22 Feb 2010 at 3:35

[GoogleCodeExporter]

Hi sergion 
can u tell me use open cinema tools for MXF interop.
I have tried for J2k its working fine with doremi server 
But open cinema tools does not support MPEG

Thanks

Original comment by thelovem...@gmail.com on 24 Feb 2010 at 2:05

[GoogleCodeExporter]

I've used them for MXF Interop but there are a lot of things you have to do, 
since open 
cinema tools doesn't support interop.
Pretty much you have to create the xml files by hand (I just create a SMPTE 
package 
first, and then the Interop using the same source files, and copy the xml 
files), and 
then you have to use 2 tools to extract the UUID and HASH from the MXF Interop 
files
Then you replace the asset UUID and HASH from the copied xml files with the new 
ones.

Pretty complicated so if SMPTE works for you stick with it, heh.

Original comment by sergio.o...@gmail.com on 24 Feb 2010 at 2:20

[GoogleCodeExporter]

I forgot to mention that if you don't replace the correct UUID or HASH values, 
the DCP 
will not work, although this is pretty obvious.

Anyway according to what I've been reading around here, the only servers that 
don't 
support SMPTE are the non-DCI-compliant ones (people here complain a lot about 
Dolby 
servers, for example).

Original comment by sergio.o...@gmail.com on 24 Feb 2010 at 2:32

[GoogleCodeExporter]

Ya i got ur point which tools u have used to  extract UUID and hash from MXF 
Interop 

Original comment by thelovem...@gmail.com on 24 Feb 2010 at 5:08

[GoogleCodeExporter]

asdcp-test for the UUID, there's the -i -H flag that returns a bunch of data 
(and I 
mean A BUNCH) including the ASSET UUID that appears somewhere in the end of the 

returned data.

Then I use openssl to extract the HASH. There's a thread around here that 
explains how 
to extract the HASH.

Original comment by sergio.o...@gmail.com on 24 Feb 2010 at 5:22

[GoogleCodeExporter]

I noticed in the cpl.xml their multiple UUID is mentioned Asset UUID i got from 
asdcp
-i -H command and how i will obtain others. I am not getting HAS process can u 
tell
me in which thread its explained .

Original comment by thelovem...@gmail.com on 26 Feb 2010 at 12:36

[GoogleCodeExporter]

http://code.google.com/p/opencinematools/issues/detail?id=17&q=openssl

that one

Original comment by sergio.o...@gmail.com on 26 Feb 2010 at 1:13

[GoogleCodeExporter]

I tried it work properly on doremi server , but it needs a lot of changes to do 
.
I am trying on a script through which changes made easy , 
"Any Ideas most welcome"   

Original comment by thelovem...@gmail.com on 3 Mar 2010 at 6:39

[GoogleCodeExporter]

Does anyone know if cross talk cancellation (ghostbusting) is necessary in realD
systems??

Original comment by chris...@rezq.se on 11 Mar 2010 at 7:31

[GoogleCodeExporter]

Yes unless they've installed the RealD 3D EQ update or whatever.

According to my experience, I can get away with it by not making stuff pop out 
too 
much, specially if I have high contrast areas.

BTW according to what I'm reading, the RealD system is the only one that needs 
a 
ghostbusted master (blame it on the silver screen).

Original comment by sergio.o...@gmail.com on 30 Mar 2010 at 2:07