Hi, I guess Kakadu is neither free nor open-source, hence licensing issues ?

G. Le 27/06/2014 13:20, Carsten Kurz a écrit : _______________________________________________ DCPomatic mailing list DCPomatic(a)carlh.net http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic

Well anyway that might be possible as OpenDCP gives (or gave ?) that option with Kakadu. In my mind it was actually more about rightful attitudes towards open-source and licenses than about money indeed. (the ability to re-arrange mxf may finds more suppporters too) G. Le 27/06/2014 13:52, Carsten Kurz a écrit : Am 27.06.2014 um 13:35 schrieb Gérald Maruccia: Hi, I guess Kakadu is neither free nor open-source, hence licensing issues ? Yes, it costs money, but It could be an optional item. As a matter of fact, adding machines to speed up J2K encoding also costs money and the hardware is not open source ;-) I understand there's some pros and cons in it. I'm not sure wether the current Kakadu licensing models are 'compatible' with DCP-o-matic license or Carls rightful attitude towards it at all. But kakadu comes from an academic environment (UNSW), and they would probably be flexible with special licensing conditions. I guess Carl would prefer a GPU/OpenCL assisted OpenJPEG implementation. - Carsten G. Le 27/06/2014 13:20, Carsten Kurz a écrit : Am 27.06.2014 um 09:58 schrieb Jonathan K. F. Jensen: Hi Carsten. Thanks for the explanation, I see your point. My source material is everything from a single tiff/jpg/png (for slides), to Prores 10bit, 4:4:4. I have been wondering if it could speed up the encode on the 'Master' by adding a SSD and be able to point DCP-OMatic to that as a 'Scratch' disk. Just a thought :) SSDs will certainly add something to performance when going from that class of source content to J2k, but as every machine's J2k coding capabilities quickly max out, it won't be a massive boost I guess. Some of those machines I gave Carl benchmark data had SSDs, but it wasn't really visible from the results. But then again, they were all only testing on 'tiny' big buck bunny ;-) When a GPU assisted OpenJPEG will be there, mass storage performance might become more important. Carl - did you ever think about implementing support for e.g. Kakadu? I'm quite okay with the current coding speed and options for network rendering, but I'm not using it for large projects on a daily basis like others might do. - Carsten _______________________________________________ DCPomatic mailing list DCPomatic(a)carlh.net http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic _______________________________________________ DCPomatic mailing list DCPomatic(a)carlh.net http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic _______________________________________________ DCPomatic mailing list DCPomatic(a)carlh.net http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic _______________________________________________ DCPomatic mailing list DCPomatic(a)carlh.net http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic

There is also this chap: https://groups.google.com/forum/#!topic/openjpeg/6i5m5keoW8w working on OpenCL support in libopenjpeg, if you want to send him some encouragement / chocolates / money ;) Regards Carl

Hi everyone ! Here is my latest fabulous script. It now takes a stereo video file as input and outputs one video file with 6 channels ready to use in dcp-o-matic. It does not "change" video settings, only copy. It uses sox and ffmpeg so checks if they are present on system and eventually install them. Because of that, it will work only on Ubuntu and derivatives (mint, elementary a.s.o.) as it installs ffmpeg from Jon Sverrinson ppa on launchpad. (but the settings of sox and ffmpeg can be re-used anywhere else !) There are 3 styles of upmixing : 1 - only dispatches bands of frequencies amongst 6 channels : it's a "soft" way which never gave (me) bad surprise. 2 - dispatches band of frequencies + mixes : quite "boom-boom" style which fit well for music, concerts, video clips. Not really good for movies as there is "much" sound on every channel. 3 - a little more complex, dispatches band of frequencies, uses phase inversion, delay : nice results so far (for me). Former version used a too low peak level - because of phase inversion. (more explanation about how and where I've found informations following the links provided at the beginning of the script, mostly in french, sorry) At the end of the process, it will ask if you want to save all the temporary files allowing to deal with each separate channels, the "dumb" video and others files created during the process. So why do I post this again ? It needs improvements : - when using the script, you have to be in the same folder as your initial video, and the paths and files names must be without spaces and other special characters. You also have to specify the output extension .mov It seems to me more convenient to enter entire path to file(s) but not skilled enough yet. - it's only (fake) 5.1 channels, but is 7.1 usefull when upmixing from stereo ? - a "zenity" graphical version of this script might be easier to use but might not work everywhere and once again I'm not skilled enough for the moment. - the output file is not seen as a 5.1 in audio properties. I guess it's relative to -map in ffmpeg but what I've tested until now was not good. - it's written in french Thanks for reading, and don't hesitate to contact me, all suggestions and pieces of advice welcome ! Still hope my english is understandable… Best regards, Gérald _______________________________________________ DCPomatic mailing list DCPomatic(a)carlh.net http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic