Home

Welcome to the vapoursynth-classic wiki!

VS-C is a fork of VapourSynth and we sincerely thank and appreciate each and every one who contributes to VS. In open source world, sometimes though, we have to agree to disagree, so here we are.

VS-C has no intention to replace VS and we do this to support an orderly transition from R54 to R55 for our users. There is no plan to advertise the fork publicly.

Originally the goal is to add compatibility patches alone, however, after extensive benchmarking we have identified some particular performance degrading commits in the upstream that we just have to revert. Therefore, VS-C will also contain some tiny performance tweaks that should make it strictly better than the upstream in terms of performance. That being said, the primary focus of VS-C is compatibility, not performance, and if you require the ultimate performance over stock R55, please see VapourSynth-Modern, which provides significant performance improvement over stock R55.

Goals

• doodle2 branch: we strive to provide a bridge between R54 (api3) and R55 (api4) vpy scripts by being compatible with both versions whenever possible. See #2 for a list of fixed (and not-yet-fixed) incompatibilities.
• master2 branch: it turns out R54 still beats R55 on all of the production scripts we have tested. We intend to backport important bugfixes from upstream R55. Occasionally, there might be other tweaks to better suit our internal users.
• dev2 branch: aka. VS-C Next. this is where significant development happens. The short-term goals are:
  • Migrate to meson-based build system (reusing the rejected https://github.com/vapoursynth/vapoursynth/pull/825 started by @HolyWu)
  • Replace std.Expr with feature-rich and more portable lexpr
  • Replace existing x86-only assembly implementations with lexpr-based implementations so that VS-C works and performs well on non-x86 systems (initial focus is arm64)

Branches

• Upstream tracking branches
  • master tracks https://github.com/vapoursynth/vapoursynth/tree/api3 (previously master)
  • doodle1 tracks https://github.com/vapoursynth/vapoursynth/tree/master (previously doodle1)
• vs-c modification branches: all these branches are LGPL-v3 (for Apache 2 compatibility)
  • master2 is vs-c.R54 (API3) development branch, which tracks changes from master
  • doodle2 is vs-c.R55 (API4) development branch, which tracks changes from doodle1

FAQ

1. Why forking VS? There are some fundamental disagreements:

• vpy-level backward compatibility. The upstream has chosen a path where breaking the user visible API is always justified. Sorry, but we simply can't agree with that. For example, see the discussion on PR 739 and Issue 736 for a prime example where API is broken with no justifiable reason whatsoever (basically, because I think the old API does not look nice, so let's break it). Other examples includes get_read_array removal without deprecation, removing/deprecating filters despite active usages. Or, just see how many new API breaks since RC has been released.
• testing. It is clear to us that the upstream barely tests new code/functionalities (e.g. #742, #740, #732, #729, #725, #719, #716, #713) and sometimes, new code does not even compile (e.g. #728 and more). After introducing a new filter, testing the simplest use case using all default arguments should not be that much a burden, I assume, yet SplitPlanes, BlankAudio, PlaneStats fails even this.

2. Why relicense as LGPL v3? Some necessary packages are Apache 2, e.g. ImageMagick, in order to legally link and distribute the resulting binaries, VS-C must use a license that is compatible with Apache 2, and unfortunately, LGPL v2.1 does not provide this, so we have to upgrade to v3, as allowed by the license header in the source files.