Repository navigation
Wrapper Script & Packaging #39
Description
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:
- git clone git://github.com/graphific/DeepDreamVideo.git
- cd DeepDreamVideo
- ./configure --with-ffmpeg --with-gm --with-of --with-mlt
- 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.
Activity
graphific commentedon Jul 13, 2015
@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 commentedon Jul 13, 2015
I'm a big fan of this idea. It would speed up my workflow significantly.
denjello commentedon Jul 13, 2015
@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;.mp4would become_exit_0_cat__dev_null___home__disown_.mp4Additionally, it would be better practice to detect media type with the
fileutility, accepting onlyvideo/*types. (I have a write up on this general issue here.)graphific commentedon Jul 29, 2015
@denjello any luck on some of these ideas? :)
denjello commentedon Jul 30, 2015
I've been busy with a few other things - sorry. Have not forgotten and will make a pull-request ASAP.