Even though MoviePy is an "older" library (original HN discussion from back in 2014: https://news.ycombinator.com/item?id=7121104), it still works pretty well, although you may have to fuss around with the low-level FFMPEG settings to get what you want. I'm surprised that there hasn't been more usage of MoviePy actually.
If this did DNxHD codec transcoding I would love it forever. I need to ask and look to see if this is possible to add. When you edit videos you SHOULD transcode your videos into a format that actually uses one image per frame (DNxHD or PreRes (On Mac)) and than then deliver it back into a compressed format like H.264.
Yes, you should transcode your videos to an intra-frame codec (i use ProRes at 540p). But (and this is important), this is only a proxy format. When you export your creation the video editor should automatically use the original files for rendering. Premiere this very well nowadays.
ProRes 540p is HUGE. Are you working with 4k? If not I would knock that down. Apple ProRes 422 is only 147 Mbs. https://www.premiumbeat.com/blog/5-things-you-should-know-ab...
540p means 540 pixels on the short side (height). That is very low res and they're not big.
> Are you working with 4k?
Very close, UHD resolution.
Funny enough, MoviePy makes it so easy to edit videos that we also use it to edit images. But the way it works is when a user uploads an image, we convert the image into a video format, edit it with MoviePy, then convert it back into an image. A little inefficient, but it works better for us than writing a completely different branch of code to handle images.
Having worked with MoviePy for a while my main ideas for improvement would be: 1) Create a callback for video editing progress so that it could be outputted to the frontend, etc, 2) Make predefined transitions - currently transitions need to be manually calculated, would be nice to have smarter presets to make it easier to create something like a slideshow, 3) improve threading over multiple CPUs - not sure how possible it would be for the library itself to handle this but from our initial tests ffmpeg by itself seems to handle threading more effectively
AFAIK, Vapoursynth is more powerful thanks to its module system, however the ability to integrate with IPython notebooks of MoviePy seems nice.
Apple provides a nice set of apis to achieve this as well:
Traditional science education videos are created by sort of a waterfall process. Throw the script/footage/video over the wall, and just hope it kind of works when it hits users. But it seems this usually doesn't work - prolifically creating misconceptions, while failing to provide transferable understanding. Ok for a "motivational speaker" role, but not for a "tutor". Someone at a leading educational video shop once told me 'sure, it would be great to make user testing part of our development - just as soon as we find anyone willing to fund that'.
Regrettably, my videos didn't user test well. The exercise didn't converge, and was abandoned. I had envisioned an incremental process, of informal testing for appeal, understanding and misconceptions, while improving clarity of explanation.
Instead, what I found was a minefield. Bacteria and viruses get bad press, so for some "a fun story about bacteria!" has the emotion tone of "a fun story about genocide!". An elderly British gentleman was distressed by the mention of "millimeters", which brought back unhappy memories of learning metric as a child. An MIT student was disturbed by the viscerals of breaking off the head of a T4 phage (zoomed to chicken-size). Someone ran away exclaiming "how could you show me something so disgusting?!", for reasons unknown, but perhaps from having not understood anything, and thus seeing a pile of E.coli, as a pile of poo. Lot's of "oh my, I certainly didn't anticipate that failure mode". And this wasn't long-tail variance - I wasn't testing enough to see any. This kind of nonlinearity seemed common case.
I also hit some newby with "insufficient domain expertise on tap" mistakes, like underestimating the interference effects between spoken and written input - having a character speaking visible text works startlingly poorly.
I wrapped moviepy in a framework to create lots of minor variants for testing...
class NovX4 (FilmCommon2):
default_shots = 'context','question','realsize','zooming','views','playset','buildings','measure','stories'
question_shots = 'question_how','question_sizes','question_planets','question_atoms'
question_how_script = aka(am18.HowCanYouRemember)
question_sizes_script = aka(am18.TheSizesOfThings)
class NovX6 (NovX4):
def question_sizes_frame (self,t,d):
ca = self.setup_table()
if t > d * .5:
 The stick-figure videos, in the top How to remember sizes section, of the slowly-loading wasn't-intended-to-be-public page http://www.clarifyscience.info/part/Atoms .
There was an interesting paper about SPED, a sound file editor , but I'm afraid this was just a proposal. And AudioRegent , and a few links, somewhere, to using makefiles in audio production, but I've lost track on these.
A quote from the SPED paper:
"The editor should be usable without graphical user
interface or it should not make any assumptions about
This feature may seem strange if we think of the modern
computer based editing systems which basically always
have some kind of graphical user interface. On the other
hand when comparing to analogue tape splicing one
might ask how mandatory the graphical user interface
(Yep, love sound editing; tired of screens or laptops in bags. I would love an "iPod Nano of non-destructive digital audio editing", but I am not the man to build one myself.)
3: https://tinyurl.com/y9s8mgme [pdf]
An example task: automatically detect cuts between different shots with high sensitivity, e.g. many false positives, show the user a clip of +/- 2 seconds around each proposed cut, user presses a key to confirm/deny that it's actually a cut.
Future users may consider today's restrictive GUI interfaces as quaint anachronism of the stupid ages.
- Non technical people lack the capacity to formalize their goal
- many document creators want wysiwyg applications
- programming languages are powerful but hard to "discover". People don't want to read the docs for something they will use once in a while
In moviepy's case I wouldn't use python to do describe simple video transformations as shown above, I'd use YAML. Unlike python, it's something that you can build by hand, can easily get a GUI or script to output and if you put it in version control you'll get readable diffs.
At the same time if you made every "video project" include the source media, the YAML file describing transformations used to build the output and by default include a stub 'plugin' python file, you could reduce the friction between people with coding skills seeing the need for an ad hoc custom transformation and creating it.
We used to have pretty small, simple languages in the past that were very effective in driving a simple text-based or stock-UI-component interface. These simple languages aren't difficult for people to be introduced to, preferably by accessible examples & demonstrations, and do just enough to be practical for common uses.
The only intuitive interface is the nipple, everything else is learned. It also seems you got stuck on the notion that 'programming languages' are hard. That does not need to be the case, not for native talkers. And REPL and 'wysiwyg' are certainly not mutually exclusive things, http://nbviewer.jupyter.org/url/jakevdp.github.com/downloads... that seems pretty what you see is what you get to me.
Consumers want GUIs. Show and don't tell is the way it goes.
As for notebook being wysiwyg, I also disagree. That would be like having a markup editor with a rendering window. Document creator like the "painting/sculptor" metaphor, where they interact directly with their creation. Want to modify a part of a document? click on it.
2007 was 11 years ago, in 10 years those iPhone reared people will enter the workplace. They will have instincts you and I do not. I suspect it will push general computing interface design to the 'power user' side.
As computer savvy people, I think we imagine how much better we could have been with more opportunity. It seems like the prevailing opinion is that the digital native is a myth and that just having technology doesn’t make the next generations experts in it.
I think the argument might there for interfaces to scale more fluidly from GUI to text (e.g. every GUI command is text mapped and shows you). But the on ramp to text is too difficult for new users...
Many applications on the Amiga had an ARexx Port that allowed scripts to drive all the same actions as the user.
Just imagine going to a chemical plant that makes fertilizer. Now imagine you have an operator that stares at 5 or 6 screens showing each IO process for making said paper. From the drying process, to the chemical rxns, heat, temp, water, pressure ,etc. Its a complex system to understand, and GUI's make it easier to break down.
Take away the GUI and throw in all python REPL and CLI. Things will go to shit so fast. Plants will shut down. Operators will need to be retrained and paid more to understand the inner workings of what the GUI was doing.
Thats not to say that CLI and REPL are necessarily worst than their GUI counterpart. A good example where CLI and REPL are significantlly better than its GUI counterpart outside of programming would be AutoCAD (AutoDesk). Any competent architect uses a list of well known shortcut hotkey commands, through its CLI. Such as "M" for move an object, "O" for offseting a line. It takes way longer to use a GUI to do this.
Arguably, some common GUI interfaces for programming like GIT makes it much easier to do things, like branch off, rebase, merge, and pull. I personally prefer Atom's built in GUI, or even a possible stand-alone, as I simply cannot remember every GIT command when I need too. Just the most common ones.
Lastly, windows/mac VS Linux. Its thanks to the GUI-based systems in windows/mac that make it much more popular and appealing to programmers and nonprogrammers a like, for focusing on things that actually matter (Business functions, persona life, etc).
Actually thinking about fairly advanced non developer applications. Mapping/GIS work is a lot like what you describe. GUI tooling with tool boxes of little functions that you can chain together to get the desired outcome.
Though its incredibly complex when you get the advanced use cases, it becomes not dissimilar to regular software development.
How would anyone know what commands are supported?
Pharo Smalltalk has a nifty feature whereby you can find methods by example.
'hello, world', 'HELLO, WORLD'
In a statically-typed language, you can just search by function signature (e.g. Clip -> RotatedClip (an effect) or Clip -> Time -> Clip * Clip (a cut)).
Not too sure the "artist types" will ever get very comfortable with the command line but they can usually describe what they need well enough for a techie to code up what they need given a good enough API.