[Coeur noir]: it's really ok if there's no XYZ→RGB color conversion 'cause it's enough to check
if a DCP works.
Well... this is an issue which hinders HandBrake because they rely upon Libav
(xyz color space input not supported), but not VLC which is using FFmpeg libraries.
[Coeur noir]: Any help and hints very welcome and would be useful to thousands of people
Mille e uno...
for our moonlight festival we receive short form films from all over the world, supposedly perfect DCPs.
In fact we must DCP-correct a lot of them ; we use the excellent Dcp-o-matic which unfortunately
is not able to playback in realtime (no sound), and thus is not usable for verification work.
We are considering the making of MP4 proxies with FFmpeg's CLI.
On a basic eight core CPU it should work at 10 fps. This would save us a lot of time --out of the
projection booth-- verifying at high speed ffwd and reverse the
video/audio/subtitle sync.
Bonus: we will be able to send back an mp4 clean copy to the happy selected applicants.
There is another solution for DCP reading on a slow computer that I proposed
to GPUless DCP makers: to keep real time playback necessary for sync sound verification,
only decode one frame every six or five and repeat it in the rgb display side
You get a 4 (5) samples per second film which seen at 24 (25) fps is surprisingly good to
smoothly follow body movements and displacements, certainly good enough to verify
the audio/subtitle sync. After a shortwhile you don't even realize you are looking at a 5 sps film,
and if you can go up to 8 sps (every 3 frames) nobody will ever see the trick.
PS: if you have a really slow machine you can extend the method to one sample every 12 frames,
but then the jumpiness makes the film tiring to watch.
