This repository has been archived by the owner on Jul 31, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
66 lines (59 loc) · 3.44 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Vsynth is a video processing system.
The goal for Vsynth is to become a replacement for the old Avisynth system.
Vsynth was started because Avisynth is starting to show its age and reveals
several flaws that makes it pointless to continue developing.
Goals:
* Have a minimal core. This basic core is already specified and implemented
in the vsynth.h/vsynth.c files.
* Not be bound up on any specific media frameworks. Avisynth heavily builds
on Microsoft's Video for Windows framework, which causes many inherent
limitations.
* Separate scripting from the core functionality. Being able to specify
processing graphs through a scripting language should be treated as an
add-on to the minimal core.
* No built-in filters per se. All parts of the system that are not the core
must be replaceable. However, a base package of filters for the simplest
operations should still be available.
* Extensible frame format/colorspace support. A "standard frame" type is
supplied, which should cover most common video processing tasks, but it
is possible to define other frame types, although a filter must know about
the details of a specific frame type to be able to do more than the simplest
operations on it.
* Variable frame rate support. Each frame has a timestamp attached, rather
than simply a frame number. Currently, there is no concept of frame rate.
* No audio support. This is not set in stone, and is a big departure from
Avisynth. Audio adds significant complexity, which is not desirable at
this time.
* API specified in plain C. It should be possible to use and extend Vsynth
using almost any language, instead of being limited to C++.
* No dependency on external libraries from the core. It must be portable.
* All code must be documented. Public interfaces must have good documentation
so they can be programmed against reliably, and any complex routines must
have their function and algorithm documented. All routines must at the very
least exist in a C or C++ implementation with no inline assembly, a routine
must not be implemented in assembly only.
There is no particular license attached to the code yet, but an MIT-style
permissive license is anticipated.
At this stage of the project, any and all inputs are welcome.
Things that need to be decided/discussed:
* Scripting language. Use an existing one (Lua?) or design a new one.
* Whether to actually have audio support or not.
* The StandardFrame type, whether the pixel formats supported now are enough
or more should be supported. The extent of methods available for it.
* Extent of standard filters in the project.
* Some standard frame caching mechanism is desirable.
* What to do about interlaced video. Have StandardFrame support interlaced
video or have a new frame type for interlaced video? Does it affect the core
in any way?
* A logging framework could be useful for many things.
Work that needs doing:
* Developing some tools for interactive testing.
* Some kind of compatibility interface for Avisynth. Ability to load filters
from Avisynth and/or ability to load Vsynth into Avisynth.
* Source filter. FFmpegSource?
* Other basic filters: Cropping, trimming, concatenation, resampling,
colour format conversion.
* Formal tests for the core and standard extensions.
* Develop a C++ wrapper (ideally header-only) for the core API.
* The current implementations are largely written with minimal amount of
effort and can be improved upon.