Coffee Space


Video Latex

The Problem

I want to create a video in such a format that in years to come I can create the video again and know that it will appear in exactly the same format. I don’t want this format to take lots of space unless it’s needed and I don’t want to loose information about the original data. What’s more is I don’t want to have to use a GUI to generate this and I want my format to be understandable in a text editor so that other could make changes without ever having to worry about how it looks. Media can also easily be swapped out as and when required without difficulty.


So we can see some requirements popping out:

And some additional features:


So, LaTeX doesn’t even come close to what I need and would require an awful amount of modification in order to do so. This sort of modification would require too much effort for any sort benefit you could expect.

Thinking again about some of the requirements the program will have:

My solution is one where the program runs like Java essentially, with methods etc. The difference is that events can be added to “frame space”. All variables will be global so that the program can keep track.

My idea so far:

0001 /* All imports done at the beginning */
0002 import "style.vid"
0004 /* Main method is execution entry point */
0005 main(){
0006   /* Run the main method for the style class (defined by it's filename) */
0007   style.main();
0008   /* Use variables without first defining them */
0009   /* NOTE: 'core' is a reserved word for features offered by the language */
0010   for(i = 0; i < 5; i++){
0011     image = core.image.load("image" + inc + ".png");
0012     methodName();
0013   }
0014   /* NOTE: Once here program is terminated */
0015 }
0017 methodName(){
0018   /* NOTE: fs = Frame Space, which is the video being created */
0019   fs.add(image);
0020 }

One limitation I can see is that at least for the main part of the program the execution is limited to one core. Multi-threaded execution in all of the language would allow for undetermined results and therefore breaks our requirement to run exactly the same every time. Core functions may be multi-threaded though, so much power could be generated from there.


This is possible, but requires a language to be designed from scratch. Possibly this will add much overhead. I would initially be tempted to write this in Java, although a custom language on top of a Java VM on top of native code is going to be slow. The only way this will run with real speed will be in something like C++.