Error: could not read video frame (-101)

[fabelton]

Hi,

I'm trying to transcode an encrypted 4K DCP to an open 4K DCP, but I keep getting the error message mentioned in the subject.
When playing the DCP back in DCP-o-matic the same error pops up at the same frame saying: Could not get video for view.

The OV DCP is on an brand new 4GB external NTFS HDD.
I'm using version 2.10.5 (I could not understand how to transfer my decrypt certs into a new version)

Could somebody help me out with this problem?

Thanks.

[Carsten]

Does that mean the DCP is playing correctly until a certain frame, or does it fail right from the start? To me it sounds as if the video mxf is corrupt. I could also imagine an issue with a specific encryption method.

Transferring your certs into 2.11/2.12/2.13 should work by simply updating to a current version. Of course it is always advisable to create one or two independent backups of the previous config before updating.

- Carsten

[fabelton]

The DCP is playing correctly until frame 18525 and then the error message pops up.

Looking at one of the video MXFs with mediainfo I see the this:
Package name: AS-DCP Material Package / File Package: SMPTE 429-4 frame wrapping of JPEG 2000 codestreams
Writing application: Rohde and Schwarz DVS GmbH Clipster asdcplib 1.12.51

Should I ask the lab a replacement mxf? Just for the affected reel?

Thanks.

[Carsten]

Is there a way for you to find out wether that frame is 'anywhere' within a reel (if there are multiple reels), or the first frame of e.g, the second reel? Looking at the CPL should tell you that. If it's in fact a corrupt reel, requesting a new copy should solve the issue. Comparing file hashes should also give an indication.

- Carsten

[carl]

It might be interesting to load it into the player and do "verify".

[Carsten]

I remember I tried verifying an obviously corrupted DCP (the one that had a Sony server freak out a few months ago). If I remember right, running verification on that one caused the player/verfication to crash with a similar error, however, I remember there were some changes done to verification afterwards and I can't remember what the outcome was with this specific file. As it was obviously corrupt, I may not have tested it with a later player.

Still worth a try though in this case. However, verifying a full length DCP can take very long, and I got the impression it takes even longer when it is encrypted? Although, for just a hash run, it shouldn't make a difference right?

- Carsten

[fabelton]

The frame in question is in the first reel (frame no. 18525). The DCP consists of seven reels, each with around 30.000 frames/30-34GBs.

Also of note: the DCP has been uploaded to a NAS through FTP from the other side of the globe and not sent with Aspera. The lab didn't say if there was a problem whit the upload. I copied the files from the NAS to another NTFS HDD and to an EXT3 HDD but got the same problem with both of them.

I started the verification, will let you know how it goes.

[fabelton]

The verification did not took too long, about an hour for a 142min. long film.

I got to error messages:
! Picture asset hash is incorrect.
! Picture asset hash is incorrect.

Which probably means that there are two inconsistencies in the video MXFs. Does it also mean that all the audio MXFs are good to go?

I compared the hash values in the PKL of the first and second video reels to the values of the downloaded file and while the values of the second reels are the same, the values of the first video reel don't match. I guess verifying the DCP with the player does the same comparison (?)
I'll do the same for all of the reels and will get back to you.

[Carsten]

Yup. Looks as if the FTP upload or the NAS handling broke the file. Best thing now is of course to request that reel again. Online dedicated/proprietary transfer protocols like FASP offer inband file verify and retransmission.

Audio reels should be okay.
Maybe this will also help in the future:

https://dcpomatic.com/mantis/view.php?id=1348

I regularly download large tamilish films from a google drive account with a browser. Our Sony projector does SOME verification during ingest, but it has proven to miss certain things that only show during presentation. So I started to verify the downloads with DCP-o-matic player. Which takes quite a while for those nearly three hour features, but I think it's a good idea.
For some reason it seems the Sony only does a full verify on SMPTE features, not on Interop.


- Carsten

[fabelton]

Two video files were damaged, after replacing them with the newly uploaded replacements the DCP is flawless.
Thank you for drawing my attention to the verification feature of the Player, it is a life-saver.