Usually, you wouldn't find metadata or headers in J2K, it is a stream only. However - in this specific case, the problematic data structure is a marker by itself. The problem is, there is no simple tool available to identify these files just by pointing or dropping a file onto it. You need to unwrap a J2C image and look into it with a HEX Editor or the like. One could probably use e.g. grep as well. I don't know though wether the problem is indicated by a very unique byte pattern so that it would suffice to look for that pattern, or wether you need to detect start of file structures to begin with.
In theory, Carl could add such a test to 'Verify DCP' in DCP-o-matic player, but I don't know wether it's worth the effort to test for such a limited issue?
There are other potential issues with J2K that may cause playback issues e.g. Resolves J2C are notorious for causing issues. It would be far to complicated to implement a tool that is able to detect all potential issues. J2K is just too complex I guess, and each servers tolerance is different. OPENJPEG has support for cinema profiles, and as long as you don't break these constraints, you should be safe. In that special case, a specific optimization caused an isolated issue.
- Carsten
JPEG encoding result differs between buiding version and deb version (Dcpomatic 2.12.4)
-
- Posts: 2804
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
-
- Posts: 32
- Joined: Thu Apr 19, 2018 1:58 am
Re: JPEG encoding result differs between buiding version and deb version (Dcpomatic 2.12.4)
OK, I get it. Thanks a lot for all your help!