For the moment, I rely on the idea that the input DPX file is conform to specification, including annexes.
For DPX 10-bit Filled A, the pixel format should be, per 32-bit:
- bit 31-22: datum 2
- bit 21-12: datum 1
- bit 11-02: datum 0
- bit 01-00: zeroes (padding bits)
SMPTE ST 268:2014, Annex C.
Up to now it was the case for all the files I tested and all the files tested by users, but one of the users found 1 DPX file (in a complete sequence!) with bits 1 & 0 are not zeroed! Obviously a corrupted file but it exists.
I could test and store the padding bits, but it would be double the read on the disk:
- first pass with RAWcooked, full read of files (for the moment I read only the DPX header) in order to catch files with non zero padding and store the metadata.
- second pass with FFmpeg for encoding.
at least until I implement my own encoder.
I am reluctant on that, as it is an extra read (so costly in time) for only buggy files but without that we could not guaranty the same hash for the file.
Another way is to force the verification of the reversibility after compression, so we are more sure it is reversible but similar issue about speed (double read of the input) so wondering if it should be activated by default.
Is something worth it to be changed here?
Thoughts from users?
For the moment, I rely on the idea that the input DPX file is conform to specification, including annexes.
For DPX 10-bit Filled A, the pixel format should be, per 32-bit:
SMPTE ST 268:2014, Annex C.
Up to now it was the case for all the files I tested and all the files tested by users, but one of the users found 1 DPX file (in a complete sequence!) with bits 1 & 0 are not zeroed! Obviously a corrupted file but it exists.
I could test and store the padding bits, but it would be double the read on the disk:
at least until I implement my own encoder.
I am reluctant on that, as it is an extra read (so costly in time) for only buggy files but without that we could not guaranty the same hash for the file.
Another way is to force the verification of the reversibility after compression, so we are more sure it is reversible but similar issue about speed (double read of the input) so wondering if it should be activated by default.
Is something worth it to be changed here?
Thoughts from users?