Re: [dev] Request for name suggestions: suckless video editor

From: Mattias Andrée <>
Date: Thu, 12 Jan 2017 14:20:06 +0100

On Thu, 12 Jan 2017 13:55:36 +0100
Laslo Hunhold <> wrote:

> On Thu, 12 Jan 2017 02:12:11 +0100
> Mattias Andrée <> wrote:
> Hey Mattias,
> > I'm working a non-graphical video editor. However, I
> > need a proper name for the project, and I have no idea
> > what to call it, so I'm taking suggestions from you.
> just call it "blind", the name is not taken afaik.

That's a fun name. I'll use it unless someone comes
up with something even better.

> > Currently there is no support for audio, I'm not sure
> > it's actually needed, but I will investigate this
> > later. If it's added, I will only add tools for audio,
> > it will not be for audio effects, such tools already
> > exists and are not needed.
> Well, audio should be in it in case you want to anything
> with it other than uploading webm's to 4chan which are
> silent by default.

I meant, that I don't think there is a need for the project
to support audio, ffmpeg and tools for effects are probably

> > The video editor uses it's own format, it is a simply
> > container with the metadata: number of frames, width,
> > heights, and pixel format, followed by a magic value
> > and the video in a raw format. Currently the only
> > support pixel format is CIE XYZ with alpha expressed in
> > `double`:s, but in the future I may also add support
> > for `float`:s for faster computations. So the format is
> > not portable between machines.
> single- and double-precision floating-point numbers are
> standardized and thus portable, however, you have to deal
> with endianness one way or another. I would generally
> recommend using doubles despite the speed-tradeoff,
> because rounding errors are horrible enough, especially
> if we're talking about an editing-pipeline.

Yes, that's why I choose to use it, and it will be
the default even if single-precision is added.

> Also, keep in mind that the data-format is the most
> crucial component of your software. If you get it right
> and make it "network-safe", you can do anything with it.
> If you mess it up, make it too complex or too simple, you
> might as well not start working on a video editor. If you
> store each frame in a raw format anyway, you might just
> think about using ffmpeg to extract all keyframes,
> convert them to farbfeld and align them in memory in some
> way (as a suggestion). As discussed at the last slcon, I
> am still in the process of finding the right approach
> with farbfeld, so stay tuned.
> Keep us updated here, but keep in mind that video editing
> is a monumental task. I have been working on multiple
> concepts for a suckless image editor for two years now
> and just a few weeks ago I was able to hit a breakthrough
> I hope to be able to pursue in the next months. Image
> editing is a much simpler task than video editing,
> especially given the sucky containers that are used in
> the industry.
> Cheers
> Laslo

Received on Thu Jan 12 2017 - 14:20:06 CET

This archive was generated by hypermail 2.3.0 : Thu Jan 12 2017 - 14:24:13 CET