[HN Gopher] Programmatic Video Editing with Python
___________________________________________________________________
Programmatic Video Editing with Python
Author : selvan
Score : 111 points
Date : 2021-07-21 05:42 UTC (17 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| popotamonga wrote:
| Hm could this be used to make a clone of https://pirsonal.com/ ?
|
| Have video templates then render them on the cloud filling the
| template placeholders with images, text, etc.
| kall wrote:
| If you are comfortable with javascript instead of python, I
| think Remotion [0] could get you to something like that pretty
| quickly.
|
| It's more data driven motion graphics instead of non-linear
| video editing, but it looks like that's what pirsonal is doing
| pretty much.
|
| [0] https://www.remotion.dev
| PufPufPuf wrote:
| I love MoviePy! It's great when you have a lot of bits of audio,
| video, and text you need to glue together. I have used it to
| create some GPT-2-generated Peppa Pig cartoons
| (https://www.youtube.com/watch?v=1TEwCA3KDtg) -- stick the image,
| text, and speech together (aligned to the speech length), concat
| all the clips, and finally apply some fancy ffmpeg effects.
| yuy910616 wrote:
| I've always thought "from lib import star" is somewhat of a anti-
| pattern.
|
| Personally I think that makes sense - because sometimes when I
| read code, I just have no idea where something comes from.
|
| But I've seen import star everywhere, couple of examples:
|
| Doc for this product
|
| FastAI's course
|
| Bing ads code base
|
| So I'm guessing it is more of accepted than I expected? What does
| HackerNews think?
| amelius wrote:
| Side question: how do you prevent import statements from being
| imported by "from lib import star"? (Without explicitly
| mentioning all the stuff that is not import statements).
|
| For example, this is mymod.py: import numpy
| as np def f(x): return 2*x
|
| And here it is imported: from mymod import *
| f(10) # Works as expected. np.sum([10, 20]) # Works,
| but shouldn't work.
| qbasic_forever wrote:
| Any non-trivial python module is going to be broken up into
| multiple files and have an __init__.py which you can
| explicitly define what's imported and exposed. You can hoist
| a single file module into a folder-based module if you need
| direct control and don't want to split it apart into multiple
| files yet too.
| connorbrinton wrote:
| The best you can do (without doing crazy introspection) is to
| set `__all__` in `mymod`. It still requires listing
| everything you want to be exported from `mymod`, but at least
| you only need to do it once.
|
| Docs:
| https://docs.python.org/3/tutorial/modules.html#importing-
| fr...
| formerly_proven wrote:
| Linters will also complain about importing stuff that's not
| listed in a module's __all__, so it's overall good API
| hygiene to have one.
| comradesmith wrote:
| Python modules can define a list named `__all__` which of
| present will define the behaviour of importing "everything".
|
| The `from x import y` syntax is unaffected
| dbieber wrote:
| Here's my take: Don't use "import-star" in library code. Like
| you say, it obscures where elements of the namespace came from.
|
| When using Python interactively, esp. if the interactive
| session is to be thrown away at the end, then import-star can
| be fine and can be a good time-saver. Video editing is a great
| example of when this is appropriate. See also manim. Other
| examples might be one-off html parsing or one-off data
| manipulation tasks.
|
| Similar to "import-star" is multiple inheritance. Just like
| import-star, multiple inheritance can make it ambiguous where
| methods come from, and imo it should similarly be avoided by
| default unless there's a compelling reason to use it.
| detaro wrote:
| An anti-pattern, but I think it's somewhat acceptable for one-
| offs, examples, ... where there is really only one thing it can
| come from.
| qbasic_forever wrote:
| pep8 discourages it, but context matters. a half page readme
| example trying to demonstrate API usage succinctly is not the
| sames as a 10 year old 40k line codebase that 25 devs work on
| dragonwriter wrote:
| > I've always thought "from lib import star" is somewhat of a
| anti-pattern
|
| Like patterns, anti-patterns are context sensitive. "from lib
| import *" is _usually_ an anti-pattern, but doing it _exactly
| once_ in a source file, especially a short one, and especially
| for demonstration code for the library so imported, is not a
| problem.
|
| But if you do it two or more times in the same source file...
| Daiz wrote:
| If you're interested in high performance video processing with
| Python and want something more than just a fancy ffmpeg wrapper,
| then I can highly recommend checking out Vapoursynth:
| https://www.vapoursynth.com/
|
| It's been around for ~9 years and has a relatively large
| community around it, most visibly found on the Doom9 forums:
| http://forum.doom9.org/forumdisplay.php?f=82
|
| I'm personally still mostly using Avisynth these days since it's
| what I'm most familiar with, but I've also used Vapoursynth and
| it's definitely the one to learn if you want to get into
| programmatic video processing these days.
| fareesh wrote:
| What are some good / mature / performant libraries to
| programmatically achieve compositions of text, audio and image
| files, perhaps with a timeline in which these can be declared at
| various timestamps, and the output is a video file?
|
| Does this one do it?
| wizzwizz4 wrote:
| AviSynth+ [0] is one of the most mature libraries around. It's
| performant enough to run live (usually), though I don't imagine
| it's heavily optimised.
|
| [0]: https://avs-plus.net/
| qbasic_forever wrote:
| gstreamer is mature... still hard to say if it matches the
| other requirements (it is notoriously difficult to figure out
| and use from its docs)
| minimaxir wrote:
| Essentially this repo is a robust wrapper for FFMPEG, which is
| what most programmatic video editing tools use in one way or
| another.
| mr-wendel wrote:
| I've had a lot of fun with https://github.com/mifi/editly. It
| seems a bit RAM hungry as you define lots (dozens?) of clips
| thought.
|
| I found it super useful to write a quick Python script to auto-
| generate JSON in the format it wants, combining screenshots,
| headers, footers, and such into a nice demo-video.
| zwieback wrote:
| this looks great. I normally use Premiere Elements but the
| overhead for short compositing is too high and there's little
| automation (at least I don't know how) so something like this is
| great. The example of compositing using regions found with a
| template line drawing is intriguing.
| 35mm wrote:
| If you move to Premiere Pro and After Effects, you can automate
| almost everything that you might want to edit and or composite.
|
| Both have their own scripting language based on JavaScript and
| After Effects also uses plain JS.
|
| There are also a number of paid plugins which provide varying
| levels of no-code automation. For example there is one which
| connects to Google Sheets and creates a new AE comp from each
| spreadsheet row, replacing text, images from URLs, changing
| dimensions of objects, etc. all based on the values of the
| spreadsheet cells.
___________________________________________________________________
(page generated 2021-07-21 23:00 UTC)