Video: A Language for Making Movies | Hacker News Reader

Video: A Language for Making Movies

lang.video

149 pointsbrudgers40 comments

The "Getting Started" page of the documentation seems to be a better introduction to the project than the home page. It has a tutorial with screenshots and code snippets, and is overall a better description of what the language does:

https://docs.racket-lang.org/video@video/Getting_Started.htm...

About a decade and a half ago, Microsoft had this DirectShow interface called "Timeline" that would provide a similar though non-programmable interface to constructing movies via an XML document spec. The characteristic representation snafu there was the limited way in which "transition" worked and how we couldn't extend that notion. When I worked at muvee, we found that approach limiting and built an entire engine programmable via a scheme-like embedded programming language we called muSE.

While muvee was about automatic video construction, the language had the necessary primitives to programmatically construct video. The basic abstraction on top of which everything from video clips to effects, transitions and layers were built was a "Show" which is a function from time to image.

More here -

[1] Authoring muvee styles - describes how to make your own automatic video "styles" and includes the lower level api too - https://srikumarks.github.io/muvee-style-authoring/index.htm...

[2] muSE the core open sourced language - https://github.com/srikumarks/muSE

edit: muvee Reveal - https://www.muvee.com/products/muvee-reveal-encore-automatic...

disclosure: I used to work for muvee.

Take this feedback as constructive, because Racket is cool and a movie-making language is interesting and I want you to succeed.

Good software design is about anticipating what your user will need to know to move forward. Your project failed to do that at step 0: the project home page doesn't show the information people will need to move forward. Some indication of what the project does, what it looks like...

What I thought when clicking on the HN link:

Video-making with a programming language! How interesting! Lots of potential with animation, concurrency, etc. What does that look like? I want to see a session with the tool. At the very least I want to see the output of the tool, and some code snippets. If I like it I'd like to know who made it, and why, and what they've done with it so far, and where the money's coming from. Well, at least there's a getting started button, nice and big and red! Oh, all it's telling me to do is install this thing. Is the author crazy? I'm not installing something without a single goddamn screenshot! Lets write an HN comment...

The thing is I am not going to install your program without this information, and I think you need to spend some time thinking about what visitors to your project will need to see before they take the plunge and look at your stuff.

I agree they ought to show what it’s like to use this on the landing page.

Meanwhile, for anyone curious there are some screenshots and demonstrations of usage in the docs, starting with this page:

https://docs.racket-lang.org/video@video/Getting_Started.htm...

I disagree. A link to documentation is at the start of the page. That's where I expect to see code samples and output which is all there

Which covers, reasonably, people who have an idea of what the product is and enough motivation (i.e. working in the space, or a serious hobbyist) to click in more deeply.

Myself -- little more than an enthusiast -- clicked the homepage link, the documentation link, the blog and ended up landing at the point where the line on my "interest in the product" part of the graph met my "time I'm willing to spend figuring out if I'm going to be more interested" before I ever got the answer to "would I want to use this?"

That's fine -- the author is within his rights to target what s/he wants. Perhaps it's so Alpha that the author doesn't desire people other than "serious hobbyists" to dig in deeper (there's valid reasons to do this). But if the goal was to get larger traction (as posting to HN is likely to cause), that didn't happen, for me.

I posted it to HN. It's not my project. I found it interesting because I have some level of current interest in ffmpeg. I googled "ffmpeg racket" probably because I saw this or (something like it) at some point in the past several years. I went about as deep into the project as you did and concluded "it's not for me" too. It was still intellectually interesting, hence the submission.

The reason I concluded "it's not for me" is I've realized that trying to avoid learning big heaps of pain like ffmpeg takes more energy than just climbing the steep learning curve of the original tool...and in theory writing my own abstractions over it. To put it another way, I can probably automate ffmpeg using Babel in emacs org-mode and get tooling that hews closely to what I am trying to do.

FWIW I also posted a link to a Python repository wrapping ffmpeg. Similar reasons. Similar conclusion. But the Python tool is much more mature and would probably be a better engineering choice than an org-mode document in a team environment with a normal distribution of tool preferences among its members.

>The reason I concluded "it's not for me" is I've realized that trying to avoid learning big heaps of pain like ffmpeg takes more energy than just climbing the steep learning curve of the original tool

Well, then, a valuable lesson. I would suggest that writing a blog post about that experience and posting to HN about that would actually have been more interesting, for me.

Even though I know that its better for me to just learn the base technology doesn't mean I don't try to avoid reading the manual. Knowing there are no silver bullets doesn't mean I don't want one. It's just that this time it only took me a few hours and a night's sleep to stop looking. Unfortunately, by that time, both articles were on the front page. Or fortunately to the degree my self worth is tied to my HN karma.

Ah, another person experiencing `ffmpeg fatigue`. Holy cow is that a language-in-a-command-line. I ended up using 11/17 graph paper to write out a mess of notes trying to understand how everything is put together.

There are some solid wrappers, now, but in the past most of the libraries I've run into (at least on the C# side) exposed a limited feature set as a way of reducing the complexity. The features omitted, of course, were ones I needed. So I always ended up back using a ba/zsh script and the command-line.

Based on my notes, I've always felt that it wouldn't take much to represent the command-line options in a more elegant way using a YAML definition (with more descriptive property names than the CLI options use). Inputs, Outputs, Filters and their Relationships between each. Seems like it'd be easy to validate outside of ffmpeg... I went down the path, briefly, but got side-tracked.

Language is in the title. If your course of evaluating a language does not include at least taking a glance at the documentation then you really aren't evaluating anything. I could put a pretty little demonstration on my homepage and you'd think it's all great and meanwhile have no documentation at all.

This link is hidden under a hamburger menu on Firefox for Android, and it's not even visible on the screen unless you scroll to the right. I didn't even realize it existed until you mentioned it because the page seems to be formatted deliberately to keep you from knowing it's there on mobile devices.

How does this compare to AVISynth? http://avisynth.nl/index.php/Main_Page

Or http://www.vapoursynth.com/doc/avisynthcomp.html

It's a DrRacket plugin language so it probably has good Scheme inter-op.

Holy crap it's terrible naming hour-o-clock.

If you're creating a project like this, Use a unique name. This is basically going to be completely impossible to search for.

Videolang? DuckDuckGo also includes results to VideoLAN of VLC fame. Google does better and shows, well, what this comment section is about.

I can agree but there are plenty of lame programming language and project names: Rust, Go , C, Julia, Salt, Chrome, etc. Then very generic company and product names: Amazon, Windows, Apple, and so on. Plenty of boring, generic names.

One really annoying thing is that can make searching for information very difficult if the thing in question isn't very popular. E.g. I wanted to buy valves for a project rated for steam service. It was almost impossible at first as using steam and valve in the same search term bought up Valve the gaming company and their Steam gaming platform. I then had to use specific technical terms such as steam "gate valve" and so on plus throwing in -game or -gaming to weed out erroneous results.

In the past I have used moviepy (https://github.com/Zulko/moviepy) to programatically create videos in Python. At a very high level, it manages creation of image frames that are ultimately fed into ffmpeg. It is (was?) a bit buggy sometimes, but it gets the job done.

Initially I used it because I couldn't bother with learning any of the free nonlinear video editors on Linux (many of which are pretty flaky/hard to use, or at least were back then). Having become actually become semi-familiar with a couple of NLEs since then, I can say moviepy is a bad NLE replacement for most use cases, but for others it's a real time saver.

Why call it "Video" to be drowned by other search results and never to show up on Google?

Would you make another suggestion? Video editing is low on keywords.

Full disclosure: Making an online video editor at https://www.mixcut.com

Btw, Mixcut is a great name.

"Video" is such a bad name that literally anything is better than it. Its like calling a photo editing app, called "Photo" or a car company called "Car". Uff!

Pick an animal. A tree species. Something from the periodic table. Or, something made up like "Mixcut".

  * Lion video editor
  * Juniper video editor
  * Tungsten video editor
  * Superion video editor

Thank you!

Id' say use real screenshots on your home page.

Almost there, we will launch very soon.

How is this better than calling ffmpeg?

it uses racket and ffmpeg under the hood apparently.

Let's not forget Javascript + Video web api + WebGL, insanely powerful when it comes to real time video manipulation.

WebGL is good but has limitations around video editing, WebGPU and some improvements by browsers will address a lot of these though in the coming years.

Full disclosure: Making an online video editor at https://www.mixcut.com with web technologies.

How does this compare to ffmpeg, Nuke, davinci resolve, handbrake, AviSynth etc. etc. This is like making a language called math that is made for doing math. It's incredibly pretentious to name your project something that is confusing, difficult to find, raises more questions than answers on what it does, and definitely doesn't tell you why it exists.

It says it combines racket with a video editor. What needs to be automated in a video editor? Why does it call itself a new language?

From the docs (https://docs.racket-lang.org/video@video-v0-2/index.html):

> Video Language (or VidLang, sometimes referred to as just Video) is a DSL for editing...videos. It aims to merge the capabilities of a traditional graphical non-linear video editor (NLVE), with the power of a programming language.

I saw that and don't think it answers any of my questions.

> It aims to merge the capabilities of a traditional graphical non-linear video editor (NLVE), with the power of a programming language

Which is exactly what AviSynth and VapourSynth have been doing successfully for years.

I would love to see a running list of languages named like this. There are many, but I guess I can’t find or remember them since they’re all named so generically. Processing is the only other one I can think of at the moment.

Well I mean... Go, D, Rust, Monkey, and so on. In the case of Rust I sometimes get more results about Rust the game than I do Rust the language.

I think they mean languages named pretentiously not languages whose name is reused. Not many things (non-programming included) are named after putting letters into a blender and seeing what comes out.

"Basic" might be another example.

edit: from Wikipedia's list of languages I found the following:

"Action!", "Basic", "BLISS", "Cool", "Hack", "Pure", "SMALL". Some of them are acronyms/retronyms. Special mentions: Smalltalk and High level shader language (HLSL).

wrt why video editing needs automating: there are a host of repetitive tasks in video editing that are very tedious to do with GUI editors. For instance, labelling shots with shot number overlay text. At the moment you can get quick results for this specific task using other tools such as FFmpeg. Personally, the top item on my wishlist would be a video editing library (Python?) that outputs to Final Cut Pro XML so that I could do final tweaks in a GUI-based editor of my choice.

I've used moviepy (https://github.com/Zulko/moviepy) with some success. Doesn't do Final Cut export but it uses ffmpeg under the hood, so it could be used to create raw clips in some lossless format.

Soory for necro. Editors should know how to code. Lots of editing tools are extensible in Python pretty easily. Sadly, those parts of my career didn't intersect.

I don't find the Adobe Premiere SDK very intuitive or well documented, nor does it support Python. Looks like DaVinci Resolve does support Python and it seems well documented and intuitive. Thanks for the tip.

Reply on news.ycombinator.com