Wrapper Script & Packaging

[denjello]

After working with this for a few days, I would like to propose:

• an install script that tries to install minimal dependencies
• a linker that puts symlinks into /usr/local/share
• a wrapper script that uses delimited command line args and calls the other scripts in succession

So the workflow would be like:

1. git clone git://github.com/graphific/DeepDreamVideo.git
2. cd DeepDreamVideo
3. ./configure --with-ffmpeg --with-gm --with-of --with-mlt
4. make && make install

ddv --input "video.mp4" --workingfolder "~/Videos/test"   \ 
    --args="ffmpeg:gm:png:verbose=3:opticalFlow=true:iterations=5"  \
    --melt="-consumer avformat:prores"

So in this case, first it would create the frames as pngs, then run deepdream (with opticalflow) and finally create a prores version of the dreamed material using the MLT-Framework.

[graphific]

@denjello yes sounds like a good idea, if were happy with the current state, we could turn it into a pip-installable package as well. I believe however that before we do so, its better to plug in all the missing stuff we've been discussing + do some major refactoring of the code (ie deepdream & step function are kinda duplicated for "normal" dreaming, and "guided" dreaming)

[3mcd]

I'm a big fan of this idea. It would speed up my workflow significantly.

[denjello]

@graphific I totally agree that it should first become stable before final packaging is undertaken. @ericmcdaniel Tonight I'll write a quick wrapper script that accepts all CLI args for the various steps (there is after all quite a bit of overlap) so that just one executable script needs to be run.

At the same time I would recommend including user selected verbosity reporting in stages 1 & 3.

Furthermore, as I often work on remote headless systems with shared access, I think it is important to sanitize filenames before they are touched by any other piece of software. e.g. a malicious file named ;exit 0;cat /dev/null > /home &disown;.mp4 would become _exit_0_cat__dev_null___home__disown_.mp4

Additionally, it would be better practice to detect media type with the file utility, accepting only video/* types. (I have a write up on this general issue here.)

[graphific]

@denjello any luck on some of these ideas? :)

[denjello]

I've been busy with a few other things - sorry. Have not forgotten and will make a pull-request ASAP.