Dolby DSS200 and test version

[gunnar]

Anyone here using Dolby DSS200 screen server?
And have been having problems with DCP made in the DoM test version?
The DCP that DoM test version make are having some playback error in the DSS200. The DCP loads in and is not corrupted, but when it is then played is randomly freeze and the picture and sound drop out and even sometimes come up with Transport not available error on the dolby interface.
And when i try to play stuff the time tisplay in the dolby control tap got stuck, it was stuck at 5 second for 40 second into a trailer i made.

I have also in the same cinema in other screening room DoReMi IMS1000 servers and there this is not problem at at but there is some bug about the DSS200.
I even contact another cinema that use DCP o o matic and have DSS200, asked them to make DCP from the test version in their own computers and it was exacly the same error there on the DSS200.

I have a DCP here that i made in the test version 2.11.22 and that is perfectly fine and workin very good.
That is the last test version i know for sure was not having this problem with Dolby DSS200.
I was first aware of this problem for Dolby DSS200 in the 2.11.26 release. So this was not problem in 2.11.22 so somewhere from the version 23-26 this started to happen.
I was testing this right now with the current test releash 2.11.30 and this is still problem there.
It looks like this is something about the encoding itself when DCP are made from other video format.
Because i was making new VF today from encrypted DCP from other and got DKDM. The new VF that was only subtitle (refer to existing DCP on both video and audio) Then the DSS200 play the VF very well.
So DSS200 is not crashing when the current 2.11.30 test release make new encrypted subtitle VF from encrypted OV with DKDM from others. But it does crash when DCP are made completely from scratch.

[Carsten]

Hmm. Carl should know what happened to MXF encoding between .22 and .26?

Which OS do you run DOM under?

Hmm, I was suspecting this earlier on the mailing list, but couldn't track it down to a specific version. Now that you confirm it's definitely okay in 2.11.22, I had a look again and found this:

http://dcpomatic.com/mantis/view.php?id=1125

Carl is doing all the programming and should know better, but anyway, as far as I followed the version history, the 4k layer issue was the only issue that resulted in the j2k/mxf encoding being touched recently. It seems something went wrong there - and it looks as if 2.11.23 is the version that introduced the changes in the j2k encoding.

The symptoms you describe in my opinion most certainly are caused by anomalies within either the video and/or audio mxf files, hence you don't get them when you reuse pre-2.11.23 or external mxf files in VFs.

Now how do we analyse/compare pre-2.11.23 and post-2.11.23 mxf files?


Maybe Carl can revoke this change for a special test version for you to first find out wether this was really the cause. Then it's easier to check the details of the problem. If that change is successful, it would probably be better to revoke these changes for the general test version as well until the detailed reason is found, as the 4k changes were introduced due to a formal complaint only, not a real playback issue, while the changes introduced with .23 seem to have caused incompatible mxf files to be created. Even if so far the issue only shows on the DSS200, there is definitely something wrong with these files. It's better to create files that do not cause issues in the field but fail to comply formally, than to create files that comply in one formal aspect but cause actual trouble in the field.

- Carsten

[DerAlSem]

Seems, i found what the problem is. The same things happens with Barco servers.

Wait a little, i'll post some images.

[DerAlSem]

https://yadi.sk/d/FgA-O_Af3Qrb4d

check this archive.

BEFORE - encoded with DOM
AFTER - the files from "before" reencoded with DAVINCI. I think, DSS220 and Barco "see" this files this way.

Seems the problem is in open jpeg2000 library (or how it called...).

[Carsten]

Today I did some tests, using DCPs created with 2.10.5 and 2.11.31, both in IOP and SMPTE. 2.10.5 DCPs played without issues on our Barco ICMP (running on most recent software), both IOP and SMPTE would not play or play stuttering/pausing in their 2.11.31 versions.

I guess we need to track this down quickly. Yes, 2.11.x are test versions and people are not encouraged to use them for production work, but we never before had such a long period (if at all) where multiple test versions created bad DCPs over such a long time.

At least we should issue a clear warning. What if people create DCPs with 2.11.x, test them on a Doremi with no issues, then start distribution...

Maybe unwrap and analyze with http://dsplab.diei.unipg.it/software/op ... 000_viewer

- Carsten

[carl]

I think it's some change in openjpeg. I can investigate it more when I get back to my JPEG2000 book in a few days. Perhaps I should add a warning to the download page, although there's no way anyone should be using test versions for production (and they are quite well hidden...)

Thanks to everyone for your investigations. I hope to have some more ideas within the next week.

[DerAlSem]

.

At least we should issue a clear warning. What if people create DCPs with 2.11.x, test them on a Doremi with no issues, then start distribution...

Maybe unwrap and analyze with http://dsplab.diei.unipg.it/software/op ... 000_viewer

- Carsten

Bad advice. DCPs created with 2.11.x are playing perfectly on DOREMI/GDC/DSS100/DSS200 servers. Issues are only on BARCO/DSS220.

So actual test should be on Barco, not on Doremi...

[Carsten]

What I found quite disturbing is that our Barco sometimes refuses to play (immediate stop at 00:00:00), but sometimes will play, but with stuttering, dropped frames etc., and all using exactly the same files and procedures. But, what gives...

I didn't try wether 4k makes a difference. Carl, I understand there was not just a change to the 4k wavelet level scheme in 2.11.23 (http://dcpomatic.com/mantis/view.php?id=1125), but a new version of openjpeg. But is it possible that the additional 6th level for 4k is now also created in 2k, thus confusing the decoder?

- Carsten

[Carsten]

Did some more tests - 4k 2.11.31 makes no difference, Barco won't play. I reused a 2.10.5 MXF in a 2.11.31 project - played fine. I reused a 2.11.31 MXF in 2.10.5 - won't play. I did the same using not MXF, but unwrapped J2Cs from these MXFs, reimported as an image sequence. In both cases, the encoding speed clearly indicated that no recompression was happening, reassuring me that the original image data structure was maintained. In both variants, audio was created from scratch (no audio/silent tracks), so it's clearly the video file.

Issue remains with content j2c encoded originally through 2.11.31.

I prepared a ZIP file with some details. However, at 2MB, I can not attach it to this forum post?

The latest ASDCPLIB contains a basic J2C test tool, j2c-test.exe. Results are included in the ZIP.

What puzzles me is that the file sizes of both the MXF as well as J2C files seem to be 100% identical between 2.10.5 and 2.11.31...

To me it looks as if there is something wrong about the internal structure of the J2Cs.

I tried to feed two unwrapped J2C images from 2.10.5. and 2.11.31 with the same frame number into DIFFMERGE, but as it stands, DIFFMERGE can not deal with binary files and will not show an analysis. At least, DIFFMERGE claims that both J2C files are different (the size being identical). Carl, I will email the ZIP with the test files to you, I guess you have no trouble to find the differences.

Carl - what did you do to enable the 6 decomposition levels for 4k in 11.23? Did that go automatically with the bumped openjpeg version, or did you also change encoding parameters?

- Carsten

[Carsten]

Hmm, I may be walking on thin ice here, but I found a hex editor that seems to be able to compare binary files (HEX FIEND). It only detects two tiny differences between the two frames being encoded with 2.10.5. and 2.11.31. Now, what do these two positions mean...


- Carsten

Bildschirmfoto 2018-01-01 um 21.45.04.png