The local path the dev used was "d:\ffmpeg\zcam_ffmpeg\ffmpeg_3.4" and like codec_bayer_v1_圆4.dll this contains mentions of DCMP ( "\dcmp_raw\libdcmp_raw\src\libdcmp_raw.c") right where there are Z CAM-specific strings. The local path the dev used was "F:\project2\codec_all\codec_ICE_V3R1\cmp_dcmp_dll_prj\codec_bayer_v1_dll_create_prj"ĭespite the generic name, this is actually a custom-compiled FFmpeg dll. Or maybe it just stands for compress/decompress. I wonder if that's the LeadTools CMP image compression SDK. There are several mentions of CMP and DCMP in this file. If you look at the ZRAW plugins for Premiere and Assimilate Scratch they provide, as well as ZRAW VideoSuite, the common libraries they use are these: Here's the xor'd stco atom to save everyone the work (offsets start after the 0圆C 108 frames):Ĭode: Select all 00000000 0000006C 000445F8 002B8445 Notable atoms at the start of that chunk are 'ptsb', and 'n3a ' (which is a 0x28A8 atom with 'IMVT' at bytes 4-8 ImageVision Technology is the company behind Z Cam). The 4th byte is rarely a printable character however.Īnother observation is that each frame has a 0x2904 byte chunk preceeding it that appears some kind of descriptor. Taking a quick look at a few random frames and they all continue the pattern of 'WVx', and x is always a printable ascii character but not necessarily alphanumeric. The first frame is 20b larger than the next 7, and its first 20b are 'PVVVMVVV~VVV', 'Y', 'Z', 'Y', 'B'. Taking a look at the first 8 frames there are a few interesting things. One of the non-standard atoms at the start of the file is 'jpeg', a thumbnail.
There are some non-standard atoms, but it's a normal QuickTime file otherwise. If you reverse the process by repeating the xor, it's a valid file and you can then access the frame data directly. In the case of the sample zraw file above, it's 0xDC286E56.
They've xor'd the stco (frame offsets) atom/chunk of the 'vide' track with the creation timestamp (in the mvhd atom) of the file.
0 kommentar(er)
