21 Oct
2015
21 Oct
'15
6:27 p.m.
Hi Carl.
Brilliant. I'll have a look.
By the way, cine-matic.com is an interesting concept. But as you say,
the problem is the volume of data that has to go up to, and down again
from the cloud. I'm kind of working on something similar - a web app
that controls DCP creation, but my approach has been that the web app in
the cloud only acts as command-and-control - the actual DCP-encoding
happens on worker machines down here in the "real world", with big
drives attached. So the video data never needs to go via the cloud.
I'm still working on it and road-testing it with this big batch of
films, but I'll let you all know when it's in workable shape.
Jim
It looks like that is left over from before
DCP-o-matic did better
guessing of ratio from the input size. It can probably be made
optional. Are you using a 1.x version
Yes, I'm on v1.83.0. --content-ratio does have an effect, just not the
effect I expected! It dictates the container (scope, flat etc). The
--container-ratio argument isn't compulsory and I didn't try it.
Can you
possibly point me to the part of the DCP-o-matic code base which
analyses the audio? If it's not too complex, I could maybe port it and
get it running stand-alone.
Mostly it is in src/lib/analyse_audio_job.cc. If you
want to do the
same thing standalone you might find it easier to do something like
ffmpeg -i audio.mxf -af "volumedetect" -f null /dev/null