Welcome to the new Film-Tech Forums!
The forum you are looking at is entirely new software. Because there was no good way to import all of the old archived data from the last 20 years on the old software, everyone will need to register for a new account to participate.
To access the original forums from 1999-2019 which are now a "read only" status, click on the "FORUM ARCHIVE" link above.
Please remember registering with your first and last REAL name is mandatory. This forum is for professionals and fake names are not permitted. To get to the registration page click here.
Once the registration has been approved, you will be able to login via the link in the upper right corner of this page.
Also, please remember while it is highly encouraged to upload an avatar image to your profile, is not a requirement. If you choose to upload an avatar image, please remember that it IS a requirement that the image must be a clear photo of your face.
Thank you!
The aforementioned OpenCube issue only manifested after the DCP had been played for some time. So for example, let's say I started the film from the beginning and the issue started at exactly 17 minutes… Then after the screening, I tried to reproduce it by starting playback from 17 min, but this time it looked just fine – unless I let it play continuously for a long time again.
Not 100% sure it's the same issue, but from what I know, it looks and sounds very similar.
After playing with it a bit more, it definitely does seem to get worse the longer you leave it running.
We've got the KDM for the new version already and the digital download of the DCP has started. We've swapped screens about in the meantime so it isn't playing on our DSS200 today.
Maybe this DCP is straining out the mediablock in the DSS200? We've seen in the past that some mediablocks handle high bitrate content better than others.
It's JPEG2000, so every singular frame is an individually compressed entity and is therefore not dependent on a previous frame, unlike in most MPEG and MPEG-related compression methods. So I suspect either an overheating problem or some memory leak causing those issues?
How large is the OV of MI-7? I have seen 4k Trailers - is this a 4k DCP? These trailers are also unusually large in size. Maybe they pushed it with this encoding? I would have expected Doremi/Dolphin HD-SDI based systems to fail before a CAT862 does.
I have seen datarates of DCPs rise considerably in recent years.
Last edited by Carsten Kurz; 07-10-2023, 08:20 AM.
Do we know that the affected sites are on the current software/firmware bundle (4.9.5.2 if a CP950A is not in use with the server; 4.9.6.4 if it is)? I'm wondering if it's possible that updating (or possibly even downgrading) could fix this. The gotcha is that you need a KDM from Dolby to update cat862s, so this won't be an instant process if this is a fix.
We have already received a response about this from one of our clients. Apparently, Paramount is creating a new 2K file with 5.1 audio only (and claiming that they didn't nothing wrong with the original). I suspect they came close (if not over) some theoretical maximum on some parameter. Sure, the CAT862 may be to blame as well but why would it take this long to show itself?
Paramount have been made aware of an issue with Dolby DSS200 CAT862 servers playing back the Mission Impossible 7 4K DCP incorrectly. From the information Paramount has to date, the 4K DCP provided is technically correct, and the issue appears to be on the server's part. Dolby has confirmed they can replicate the issue. These are legacy servers.
The remedy for this Dolby DSS200 issue that Dolby has confirmed is to re-supply the DCP in 2K. Dolby has tested the 2K DCP, and confirmed that the 2K DCP is playing back correctly on the DSS200.
Paramount is remastering only limited versions to be available in 2K for the DSS200. All remastered versions will be in 5.1 Interop only. The 2K DCP is being shipped overnight to theaters.
I should point out, Paramount/Deluxe does not seem to have an accurate list of theatres affected as one client, they properly identified one site, but not the other.
Thanks Steve (and Brad and others, for giving us the heads up about this).
Thankfully, I only have three regular service customers still using the cat862, and I am going to write to all of them proactively, suggesting that if they play this movie, to reach out to Deluxe now and let them know that they need the 2K IOP version. One of the three is an arthouse, and I'm pretty sure will be unaffected, but the others are an indie house that plays mainstream and a Bel-Air Circuit residence, both of which I suspect will be playing it.
Originally posted by Steve Guttag
...Paramount/Deluxe does not seem to have an accurate list of theatres...
That's a bit surprising, because whenever a theatre changes server/media block, they have to let Deluxe know the serial number of the new one in order to receive valid KDMs. So you would expect the process of maintaining their records for this purpose (identifying which theaters still use a cat862, and getting the new drives en route to them ASAP) to be automatic, and at least 99% accurate.
"...and the issue appears to be on the server's part."
"These are legacy servers?"
So, where they not, this DCP would have played O.K.?
(Replication on Dolby's part shows that it's not a random failure that causes the issue.)
Or Paramount doesn't bother complying to DCI equipment, as far as they are "legacy"?
Some more common sense and elegance would be well appreciated on this update.
I did mention it in my post earlier, but it may have been missed, but this exact same issue was present in the original teaser trailer released in May 2022, so there is obviously something unique to the mastering of MI7 in particular that is causing it.
I did mention it in my post earlier, but it may have been missed, but this exact same issue was present in the original teaser trailer released in May 2022, so there is obviously something unique to the mastering of MI7 in particular that is causing it.
Which is somewhat odd, because trailers are quite often mastered differently than the end-product. Trailers are often the product of the marketing department, not necessarily the same people that master the final product.
Also, this issue seems to only crop up after a certain runtime.
Since the problem is worse in scenes with a lot of movement, I suspect that something memory related is breaking. Since there is no relation between individual frames, the frame buffer has to be flushed after every frame to make room for the next. I suspect that something goes wrong there and that the new frames are somehow rendered over the existing frames, using a XOR function or something similar. If the buffer is filled with zeroes, that will work out fine, but if it contains data from a previous frame, the result will be a funky looking combined frame.
Whatever triggers such a situation is difficult or even impossible to asses, unless you'd be able to do a low-level debugging on the mediablock. Since the servers are EOL, nobody is going to do that anymore. The fact that it doesn't always occur, but only after a while, points more to a resource constraint on the cat862 than towards an illegal instruction inside the DCP.
Whoever claimed that digital would be perfect every single time, apparently forgot that this technology was developed by humans...
Well, they will certainly put more time into analysing this once the new DCPs have been distributed. For sure, studios will not wait for this to happen again. Legacy, yes, but still loads of them around, and 4k DCPs were always meant to be single inventory. In other countries, also dubbed VFs will have to be recreated. That will be a major pain.
DSS200's have played huge numbers of 4k DCPs without issues. It will certainly be possible to track the issue down to specific encoding parameters that were used this time.
We did an advance screening of "OPPENHEIMER" which has a 4K DCP of 300 Gb. Running time was close to 3 hrs. That gives a heavier DCP per hour than MI7. That DCP behaved nicely on the same system that had issues with MI7 (DSS200 & CAT 862). I am sure that MI7 has scenes with heaver movement within the frame vs OPPENHEIMER.
Well, they will certainly put more time into analysing this once the new DCPs have been distributed. For sure, studios will not wait for this to happen again. Legacy, yes, but still loads of them around, and 4k DCPs were always meant to be single inventory. In other countries, also dubbed VFs will have to be recreated. That will be a major pain.
DSS200's have played huge numbers of 4k DCPs without issues. It will certainly be possible to track the issue down to specific encoding parameters that were used this time.
Maybe... we'll see... apparently, there were trailers with similar issues. If so, then nobody learned anything from that. Their intermediate fix was to deliver a 2K version, which sounds more like a broad-side shot in front of the bow to me, than a narrow search for a specific problem. But how do they say in German? Was nicht ist, kann ja noch werden.
We did an advance screening of "OPPENHEIMER" which has a 4K DCP of 300 Gb. Running time was close to 3 hrs. That gives a heavier DCP per hour than MI7. That DCP behaved nicely on the same system that had issues with MI7 (DSS200 & CAT 862). I am sure that MI7 has scenes with heaver movement within the frame vs OPPENHEIMER.
That shouldn't matter much. As stated before, it's Motion JPEG2000, not MPEG. Every frame is individually compressed. A scene with heavy motion should, therefore, not be much heavier than a scene with constantly the same picture. Obviously, there are some nuances. A still frame may be less complex than a scene with heavy motion. But a scene with heavy motion usually contains a lot of motion blur, which compresses pretty well in most cases... so it depends on a lot of factors, but it usually averages out pretty nicely.
If you'd had the IMAX DCP version of Oppenheimer, then it could actually be pretty consistently true. Many of Nolan's high-octane action scenes have been shot on IMAX and will consume more bandwith than their scope scenes.
Tweet
Comment