Vapoursynth

[Chikuzen]

Here's a new vsvfw.dll (https://dl.dropbox.com/u/73468194/vsvfw.dll) that should work. I hope you enjoy my ugly hack.

seems new vsvfw.dll solved that. :thanks:

[Chikuzen]

http://www.vapoursynth.com/doc/pythonbindings.html#raw-access-to-frame-data
"Accessing the data is a bit trickier as get_data() only returns a pointer."

get_data() has already removed because it was deplicate of get_read_ptr()

http://www.vapoursynth.com/doc/functions/planedifference.html
- std.PlaneDifference(clip[] clips, int plane[, string prop = 'PlaneAverage'])
+ std.PlaneDifference(clip[] clips, int plane[, string prop = 'PlaneDifference'])

[osgZach]

GPU stuff is overhyped. Proper coding and common sense will get you almost as far for most filters. I'll probably add support for it in some form one day anyway just to prove that I'm right.
A few facts about python. It's really slow and in practice single threaded. The c libraries behind the calculation modules will run much faster if used directly in a c plugin.
Maybe it could be usable for filter prototyping for some people but I predict a huge yawn there. Video filters also aren't really "scientific calculations", they're more of an exercise in stuffing as many pixels into an xmm register as possible.

I don't know... Sure todays CPU's are pretty powerful, and a good multi-threaded app would be able to do a lot.. But if its one thing video filtering with Avisynth has taught me, it is that when you need to do a lot of heavy filtering on a source, it can bring even a beefy CPU to its knees. I can only imagine what such work on an HD source might be like, but still, I also am reminded that a lot of users here are using not necessarily top-end/modern gear.

So it seems to me any opportunity to dump additional workload off onto other systems, such as a GPU, is still something worth investigating in many circumstances. Especially if that means a given job might go at 5 or 10 FPS, vs 1 FPS (depending on what you are doing).

Sure, GPU accelerated encoding has kind of turned out to be marketing hype / a bit of a flop. But I still would like to think there is potential to be uncovered in GPU assisted filtering and processing of video.

Should it be a high development priority? No, I wouldn't be stupid enough to suggest such a thing. But I don't think it should be overlooked or so easily written off, on the other hand. Of course I could totally be wrong. I don't pretend to be a professional, or extremely knowledgeable about programming (especially as it pertains to video processing), but I guess that's just my simple opinion of things.

[Myrsloik]

Here's something new, a code doodle just to see what people think. It works a lot like mt_lut(xy(z)) but instead of using a lut it directly computes the expression. It has most of the same operators too with the most notable exception that ^ is written pow.

I simply call it Expr (https://dl.dropbox.com/u/73468194/expr.dll).
Usage:
core.expr.Expr([clipa, clipb], expr="x y +", plane=0)

You supply 1-3 input clips, these can then be referred to with x, y and z in the expression. It is allowed to mix and match the input clips quite a bit, the only requirement is that the plane that's being evaluated has the same width and height in all the inputs. The output format and dimensions are taken from the first clip.

All computations are done in float precision and the loaded values are not normalized in any way when loaded. So an 8 bit input will be in the 0-255 range, a float clip will be 0-1 or -0.5 to +0.5 and a 10 bit clip would be 0-1023.

NOTE THAT IT HAS ALMOST NO ERROR CHECKING SO A TYPO WILL GIVE UNPREDICTABLE RESULTS OR A CRASH
I DON'T WANT ANY REPORTS ABOUT THOSE PROBLEMS JUST OPINIONS ON THE IDEA AND EXECUTION

Operator list:
+ - * / max min
exp log pow sqrt abs
> < == ?
sin asin cos acos tan atan tanh

If people here like the structure and idea I'll go and write the whole thing in asm which should speed it up by quite a bit. Maybe a version that evaluates expressions in integer form would be interesting too? I don't know. Poke it a bit and say what you think about the idea.

[Myrsloik]

Can the vapoursynth.VideoNode.output() method write to an IO byte stream object like io.BytesIO()?

No. Only things with real file handles allowed. (Has a fileno method)
It kinda has to do with threading.

[Mug Funky]

Expr seems to (so far in my 10 mins of testing) only work as expected on YUV444P8.

P16 gives me a half-width picture with junk filling the rest of the space.

also, output seems restricted to 0-255 range on 10 or 16 bit input. from your post i would have expected 0-1023 for 10-bit and 0-65535 for 16-bit. exceeding 255 leads to wrap-around integer fun.

[edit]

not being ungrateful of course. it runs very fast and is pretty elegant. i expect bells and whistles to be included when you've decided whether to continue with it. it's good to have more tools in the ol' arsenal :). and processing per-pixel rather than building a big lut mans more CPU gives faster results rather than more memory. this can be a definite advantage :)

[Chikuzen]

How do I set the planes argument of VS's eedi3 to achieve the same result of original eedi3(Y=true, U=false, V=false) or eedi3(Y=false, U=true, V=true)? TIA.

eedi3(Y=true, U=false, V=false)
-> core.eedi3.EEDI3(clip, planes=0)

eedi3(Y=false, U=true, V=true)
-> core.eedi3.EEDI3(clip, planes=[1, 2])

[Eyldebrandt]

So, just a question.
Can we use vapoursynth in real time for post-processing, as we do with avisynth ?
How can we do, if appropriate ?

[ryrynz]

Can we use vapoursynth in real time for post-processing, as we do with avisynth ?


See below.

Are there any plans for a DirectShow filter that can serve as a replacement for ffdshow's AviSynth processing?


Not at this time. It'd be pretty easy to implement for someone who is familiar with dshow though.

[Mug Funky]

i'm having some trouble getting VS to compile on my msys environment.

it's stopping at "Checking for header QtCore/QtCore". i've dl'd, compiled and installed Qt opensource, but i've no idea where it installed to and whether i even compiled the right modules. it's a huge codebase and there's no configure option to just compile QtCore. i've also no idea where it decided to install to...

is there a trick to making qtcore visible to waf? most things i've installed use pkgconfig to find everything, but python and waf and qt are all quite new to me, so i can't make that assumption.

thanks!

[edit]

actually, if i knew exactly what qt tools the waf configure command was looking for, i could place them in mingw/bin or /lib, /include etc.

[Myrsloik]

i'm having some trouble getting VS to compile on my msys environment.

it's stopping at "Checking for header QtCore/QtCore". i've dl'd, compiled and installed Qt opensource, but i've no idea where it installed to and whether i even compiled the right modules. it's a huge codebase and there's no configure option to just compile QtCore. i've also no idea where it decided to install to...

is there a trick to making qtcore visible to waf? most things i've installed use pkgconfig to find everything, but python and waf and qt are all quite new to me, so i can't make that assumption.

thanks!

[edit]

actually, if i knew exactly what qt tools the waf configure command was looking for, i could place them in mingw/bin or /lib, /include etc.

It's not supported under windows. I see no reason for there to be inferior (no avisynth compatibility) binaries floating around.

[Myrsloik]

I made a new version of my Expr (https://dl.dropbox.com/u/73468194/expr.dll)filter. I'll probably add it to the core once it's stable since it's a good alternative to using a lut for higher bitdepths.

Here's a slightly modified recap from the previous post.

usage:
core.expr.Expr([clipa, clipb, clipc], expr=["x y + z +", ""], plane=0)

You supply 1-3 input clips, these can then be referred to with x, y and z in the expression. It is allowed to mix and match the input clips quite a bit, the only requirement is that the plane that's being evaluated has the same width and height in all the inputs. The output format and dimensions are taken from the first clip.

By default the expression is applied to all planes, supply an array to apply different expressions. The plane of the first clip (clipa) will be copid if an empty expression is given and the output format is the same as the format of clipa. (this can be changed with format=vs.YUV444P8 or any other format constant). In the cases the plane cannot be copied due to format mismatch the output will be undefined.

All computations are done in float precision and the loaded values are not normalized in any way when loaded. So an 8 bit input will be in the 0-255 range, a float clip will be 0-1 or -0.5 to +0.5 (Y and UV respectively) and a 10 bit clip would be 0-1023.

Operator list:
+ - * / max min
sqrt abs
Comparison: > < = ?
Comparisons return 1.0 for true and 0.0 for false. The ternary operator ? consider all values > 0.0 as true.
Logical: and or xor not
Logical operators consider all values > 0.0 as true and return 1.0 for true and 0.0 for false.

Missing but will probably be added some day: exp log pow

It is faster than mt_lutxy for very simple expressions such as "x y +" and equal for "x y - 128 +". Overall speed of course depends on both expression length and instruction complexity but is still very fast even on a complicated expression.

[Are_]

Ok, I gave it a try, and it worked fine for 8 bit clips, but failed for anything else.

This produced a clip with white horizontal stripes (and pink ones if applied to chroma):

src = core.ffms2.Source(source=r'D:\ENCODE\vs\vid.mkv')
res = src
res = core.fmtc.bitdepth(res, vs.YUV420P10)
res = core.expr.Expr(res, ['x 100 +','',''])
last = core.fmtc.bitdepth(res, vs.YUV420P8)

Changing the two last lines to:
res = core.expr.Expr(res, ['x 100 +','',''], format=vs.YUV420P8)
last = res

Produced a solid white/pink clip, no stripes (you can still see the picture, but hardly).

Am I doing anything wrong? :/

EDIT:Oh, and no plane argument:
VapourSynth Expr Filter
namespace: expr
identifier: com.vapoursynth.expr
Expr(clips:clip[]; expr:data[]; format:int:opt;)

[Myrsloik]

Ok, I gave it a try, and it worked fine for 8 bit clips, but failed for anything else.

This produced a clip with white horizontal stripes (and pink ones if applied to chroma):

src = core.ffms2.Source(source=r'D:\ENCODE\vs\vid.mkv')
res = src
res = core.fmtc.bitdepth(res, vs.YUV420P10)
res = core.expr.Expr(res, ['x 100 +','',''])
last = core.fmtc.bitdepth(res, vs.YUV420P8)

Changing the two last lines to:
res = core.expr.Expr(res, ['x 100 +','',''], format=vs.YUV420P8)
last = res


Produced a solid white/pink clip, no stripes (you can still see the picture, but hardly).

Am I doing anything wrong? :/

EDIT:Oh, and no plane argument:
VapourSynth Expr Filter
namespace: expr
identifier: com.vapoursynth.expr
Expr(clips:clip[]; expr:data[]; format:int:opt;)

Maybe. Remember that it's not normalized based on the input so a 10 bit clip with 8 bit output will be like x 4 * 100 + in your expression. Divide
X by 4 to get something equivalent. There could also be a bug in the 9-16 bit code

[ajp_anton]

Operator list:
+ - * / max min
sqrt abs
Comparison: > < = ?
Comparisons return 1.0 for true and 0.0 for false. The ternary operator ? consider all values > 0.0 as true.
Logical: and or xor not
Logical operators consider all values > 0.0 as true and return 1.0 for true and 0.0 for false.

Missing but will probably be added some day: exp log powpow should be named ^.
What about !=, >= and <=? Instead of combining =,<,> with a not.

[Myrsloik]

pow should be named ^.
What about !=, >= and <=? Instead of combining =,<,> with a not.

I suppose I should add the additional shades of equality. Just run off and test it and maybe I'll actually implement pow some day...

Since this is a fairly simple implementation I may add some stack manipulation operators too just to see what happens- I predict confused users.

[ajp_anton]

My programming knowledge is non-existant, but if I understood correctly from wikipedia what stack manipulation (or even a stack) is, then it's something I very much welcome =). At least what that one wiki page calls "dup" and "swap" would be useful.

[jmac698]

Why stop there? Write a Forth interpreter ;)

[fvisagie]

Apologies if this has been discussed, in which case I missed it. My question is: could VapourSynth be the way forward for Avisynth?

To me as an Avisynth user with limited understanding, it comprises the following main components:
1. frame server
2. rich built-in and external functions (filters)
3. rich programmability for user functions (parser)

Each of which represents a vast investment in development time and vested interests in terms of uers' tool chain and workflow.

There seem to issues holding up Avisynth development progress; specifically getting multi-threading to work correctly as I understand it. To me that would be a frame server issue, meaning nothing intrinsically wrong with its ecosystem of filters and functions - only the frame server.

On the other hand, a frame server technology refresh seems to be exactly one of the main goals of VapourSynth. Along with that comes the possibility to support (with extra development) Avisynth filters as well as its parser. It even seems possible for this support to come in various forms, e.g. creating an Avisynth emulation layer (most functionality available immediately but possibly with (future) restrictions) vs. porting individual filters and the parser to the VapourSynth Python environment (possibly longer time-to-market and also relying to some extent upon individual filter authors to contribute).

However, whichever way one looks at it, it seems technically *possible* for a future Avisynth based on the VapourSynth frame server to look, feel and work just like the current one, except without the issues plagueing the current one hopefully.

And, if it were possible to unify the two projects, everyone, absolutely everyone involved stands to benefit. On the face of it, that seems a very attractive prospect.

Therefore, to rephrase the question, has an analysis been done comparing the feasability of continuing with the Avisynth frame server vs. porting everything but the problematic part/s to VapourSynth, and what were the results and outcome? If nothing of the sort, what would be the merit of looking into it?

Thanks for your time,
Francois

[Myrsloik]

VaporSynth has a very clearly defined core library. You could fairly easily add another scripting front end. I actually considered adapting the script parser from avisynth but as a general language it also has a few issues too many (no arrays, ifs and butts).

Getting threading to work properly in avisynth has a lot of issues. The main one (from my understanding) being that the PClip and PVideoFrame smart pointer types aren't thread safe. They're also compiled into every plugin so breaking binary compatibility and recompiling all plugins is a must unless you're also willing to restructure the avisynth internals completely. For example by making each filter execute in its own virtual avisynth environment to keep binary compatibility and get reasonable multithreaded properties. (coincidentally what vs does)

Since a compatibility layer will be needed, we may as well modify the core part a bit too, right? Add those nice missing features such as arrays, a better C api, portability. Oh wait, the avisynth core is a mess where everything is tangled so let's separate the core from the scripting first. (coincidentally this is vapoursynth.dll)

While we're busy and binary compatibility is no longer an issue why not learn from the mistakes of avisynth 3? Writing a parser and scripting language is a lot of work and can kill the project. So let's adapt an existing one, like python or lua. (coincidentally what vs does)

So basically I see VapourSynth as the logical next step. If you go back and fix enough things this is what you'll get. As for uniting the projects there really isn't that much more that should be shared in my opinion, the only exception being ideas for filters and scripts.

The outcome: this?

[fvisagie]

Edit: I should have added: fair comment.

There is not an iota of truth in this.

That statement's already been idemnified ("To me as an Avisynth user with limited understanding") ;).

But seriously now, in my view Avisynth's wide appeal is due in large part to the ease and simplicity with which its power and flexibility can be accessed - in other words, to its accessibility. It does not need "programming". Avisynth arguably struck as close to the ideal balance between power and accessibility as can be done.

On the other hand, people who write Python code are seen as "programmers". So, while I do not claim to know in which direction Vapoursynth is headed, one thing seems fairly certain, and that is if it doesn't support a scripting interface of similar simplicity as Avisynth's, it won't have as wide an appeal.

So, while creating a technically superior framework no doubt is rewarding in its own right, in my opinion it would be a shame if it were to be self-limiting for lack of accessibility.

[sneaker_ger]

To be fair, creating simple vs scripts is not that much more difficult than creating simple AviSynth scripts. Working with high bit depth stuff is even easier. The biggest downside of vs (aside from lacking many plugins and scripts that AviSynth has) is the missing audio support.

The few people that can actually write powerful AviSynth scripts will have no problem figuring out Python.

[Revgen]

On the other hand, people who write Python code are seen as "programmers". So, while I do not claim to know in which direction Vapoursynth is headed, one thing seems fairly certain, and that is if it doesn't support a scripting interface of similar simplicity as Avisynth's, it won't have as wide an appeal.


I'm not a programmer and I don't find VS anymore difficult to use than avisynth. They are actually pretty similar. The only real downside is that VS's documentation isn't as robust.

[fvisagie]

The few people that can actually write powerful AviSynth scripts will have no problem figuring out Python.

No arguing with that; it's the other users where my concern lies.

But thanks for your response, valid as it is - I'm not here to argue, I simply wanted to make a point about user appeal for the Vapoursynth community to consider. Or not ;).

[JEEB]

Let's not forget that Python is just the language that was picked for the first Vapoursynth scripting mappings.

Anyone is free to add vapoursynth mappings for the language of their choice. The fact that the library itself is just something with a C API lets you do that.

[Myrsloik]

I updated Expr again.

Added operators: exp log (as in natural logarithm) <= >=

The only thing I think is really missing now is pow. Tanh could also be useful in some cases but apart from that consider it complete but somewhat untested.

If someone can give me an example where stack manipulation would speed up/simplify an expression a lot I'll add it. (such as duplicate top element on stack and swap top with second to top element)

Note that a clever person can now use Expr to do gamma aware resizing with fmtconv.

Download it (https://dl.dropbox.com/u/73468194/expr.dll)

[ajp_anton]

Say you have an expression for f(x,y,z) that is rather complicated so you don't want to repeat it. You need g(f) + h(f), where g and h are some simple operators.
"f dup g swap h +"
which I hope means it will duplicate f, apply g on one of them, swap them so you can use h on the other one, and them add them.

I don't really have a real-world example right now, but I've stumbled upon this scenario in the past.

[lansing]

any news on adding the load virtualdub plugin function yet?

[Mug Funky]

Note that a clever person can now use Expr to do gamma aware resizing with fmtconv.

hopefully i am clever enough.

thanks for the log and exp though - my plan for the moment was not so much gamma-aware but log aware (ie film land) resizing and whatnot.

this way one can manipulate 10-bit film scans without compromise.

now... if i can just get temporalsoften to play nice :)

[edit]

there still seem to be problems with 9-16 bits. looks like strips of 4 good pixels with YUV black in between.

[Gavino]

Say you have an expression for f(x,y,z) that is rather complicated so you don't want to repeat it. You need g(f) + h(f), where g and h are some simple operators.
"f dup g swap h +"
A simple way to do things like that is to save the f expression as a separate string and include it in the main expression where required.

f = " ... " # long string including x, y, z, etc
expr = f+" g "+f+" h +"

Of course, the f expression then gets calculated twice, but at least you don't have to copy it yourself and can more easily see if you have written the final expression correctly.

[ajp_anton]

Of course, the f expression then gets calculated twiceYes, that was the point, to make it faster. With mt_lut it didn't matter much, so I just made a string I could use multiple times, but that's not the case here.

[Reel.Deel]

It's a bug in mvtools. For some reason it doesn't use the emms instruction to restore the fpu state before returning when pel=1. Contact the mvtools author to get it fixed. I will never add a workaround for this in vs because it really is a fatal error.

MVTools SVP edition (2.5.11.9) has been updated (http://www.svp-team.com/forum/viewtopic.php?id=1069) to try to correct the bug with pel=1.

[Chikuzen]

I noticed a weird behavior of VFW.
Opened task manager after VirutalDub closed, the process was still on there and not gone without killing it manually.
Is this known issue ?

[Myrsloik]

I noticed that a weird behavior of VFW.
Opened task manager after VirutalDub closed, the process was still on there and not gone without killing it manually.
Is this known issue ?

Can't reproduce. It always happens?

[Chikuzen]

hmm, It always happens on my box.
and VirtualDub always crashes when I hit F2(Reopen video file).

[Myrsloik]

hmm, It always happen on my box.
and VirtualDub always crash when I hit F2(Reopen video file).

That's because the vsvfw.dll I posted is a bit buggy. I have improved the hack.

Here's the latest test build. (https://dl.dropbox.com/u/73468194/vsvfw.dll)

Debugging AVISource now but progress is slow...

[Keiyakusha]

hmm, It always happen on my box.
and VirtualDub always crash when I hit F2(Reopen video file).
Haven't noticed that the process stays there, need to check, but it crashes for me too.

[Chikuzen]

It seems that latest vsvfw.dll solved that.

[Keiyakusha]

Still crashes for me. But before it was each time I press F2 and crash was in msvcr100 (or something like that), now it crashes after I press F2 few times (3-4) and the crash in python33.dll

[Myrsloik]

Still crashes for me. But before it was each time I press F2 and crash was in msvcr100 (or something like that), now it crashes after I press F2 few times (3-4) and the crash in python33.dll

Never mind, reproduced. There's a big memory leak now instead.

[sneaker_ger]

You mean the one I reported on November 19th? :rolleyes:

[Myrsloik]

You mean the one I reported on November 19th? :rolleyes:

I thought it was only a problem related to the other deadlocks. I'll try to fix it quickly and then release a new version...

[pbristow]

Chikuzen:
Opened task manager after VirutalDub closed, the process was still on there and not gone without killing it manually.

A possibly relevant observation: Since moving to Win7 I see lots more instances of such zombie processes, that have to be killed manually, than I used to on WinXP (not just with VirtualDub, but with IE, Firefox, various games, and so on.) It may be due to change in the way Windows is handling certain error conditions...(?)

[Myrsloik]

A possibly relevent observation: Since moving to Win7 I see lots more instances of such zombie processes, that have to be killed manually, than I used to on WinXP (not just with VirtualDub, but with IE, Firefox, various games, and so on.) It may be due to change in the way Windows is handling certain error conditions...(?)

1. I use windows 7 too.
2. There's no shortage of actual bugs in python part. I hate cython now.

I've so far found half the reason for the leak. A reference leak in the core I added by accident together with the multiple output support. The other leak issue (bug on top of bug) I'm still huting...

[qyot27]

The new eedi3 failed to build when I tried yesterday on 64-bit Linux. Errored out with something about C99 and for loops.

Also, not sure what's going on here, but:
Source video is high bit depth H.264 (files were 12-bit and 14-bit, 4:2:0, 4:2:2, and 4:4:4)
Script:
#!/usr/bin/env python3
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin('/usr/local/lib/libffms2.so')
ret = core.ffms2.Source("12bit-420.mkv")
ret.output(sys.stdout, y4m=True)
The following fails (complains that it can't recognize file format):
./testscript.vpy | mpv -
I even tried going down to 10-bit in-script, just in case there was some weirdness concerning the file's bit depth, but it still couldn't do it.

This works though:
./testscript.vpy | ffmpeg -i - -f yuv4mpegpipe -strict -1 - | mpv -
And mpv correctly recognizes the y4m stream as yuv***p16le.

However, testing on Windows, the official build of R14 worked without me having to pipe through ffmpeg first.

[Are_]

for loops are c99, default mode for gcc is a flavour of c90 because c99 features are incomplete.

To fix your problems with mplayer you should specify the demuxer like this:
$ python3 testscript.vpy | mplayer2 -demuxer y4m -

I guess it's the same for mpv.

[Myrsloik]

The eedi3 error is because I committed jackoneill's conversion to c without testing it myself. Just revert that dir one commit and it will work. I'll make it proper old school c this evening.

[qyot27]

To fix your problems with mplayer you should specify the demuxer like this:
$ python3 testscript.vpy | mplayer2 -demuxer y4m -

I guess it's the same for mpv.
It's not. MPV has no discrete yuv4mpeg demuxer. It uses libavformat's.

But that's beside the point, because I figured out what the issue was after seeing it fail when I built R14 for Linux. I needed to update Python. The repo version pulled in by the python3 package is 3.2.3. After I installed 3.3 it started working as it should. 3.3 was the first/only version I have of the 3.x series on Windows, so that's why it was okay on there.

[Yellow_]

hi, currently trying to build vapoursynth on 64bit 12.10 Ubuntu Linux, done the .waf configure, think I've met all dependancies, failing on build at:

[12/17] c: src/filters/eedi3/eedi3.c -> build/src/filters/eedi3/eedi3.c.3.o
../src/filters/eedi3/eedi3.c: In function ‘interpLineFP’:
../src/filters/eedi3/eedi3.c:77:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:77:7: note: use option -std=c99 or -std=gnu99 to compile your code
../src/filters/eedi3/eedi3.c:80:10: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:83:13: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:96:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:99:10: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:102:13: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:110:16: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:119:16: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:135:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:142:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:147:10: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:164:13: error: redefinition of ‘x’
../src/filters/eedi3/eedi3.c:135:13: note: previous definition of ‘x’ was here
../src/filters/eedi3/eedi3.c:164:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:167:13: error: redefinition of ‘x’
../src/filters/eedi3/eedi3.c:164:13: note: previous definition of ‘x’ was here
../src/filters/eedi3/eedi3.c:167:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c: In function ‘interpLineHP’:
../src/filters/eedi3/eedi3.c:200:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:220:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:223:10: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:229:16: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:238:16: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:252:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:255:10: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:261:16: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:270:16: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:280:16: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:289:16: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:304:13: error: redefinition of ‘x’
../src/filters/eedi3/eedi3.c:200:13: note: previous definition of ‘x’ was here
../src/filters/eedi3/eedi3.c:304:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:311:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:316:10: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:333:13: error: redefinition of ‘x’
../src/filters/eedi3/eedi3.c:304:13: note: previous definition of ‘x’ was here
../src/filters/eedi3/eedi3.c:333:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:336:13: error: redefinition of ‘x’
../src/filters/eedi3/eedi3.c:333:13: note: previous definition of ‘x’ was here
../src/filters/eedi3/eedi3.c:336:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c: In function ‘copyPad’:
../src/filters/eedi3/eedi3.c:381:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:391:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:399:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:407:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:409:10: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:412:19: error: redefinition of ‘x’
../src/filters/eedi3/eedi3.c:409:19: note: previous definition of ‘x’ was here
../src/filters/eedi3/eedi3.c:412:10: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:417:16: error: redefinition of ‘y’
../src/filters/eedi3/eedi3.c:407:16: note: previous definition of ‘y’ was here
../src/filters/eedi3/eedi3.c:417:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:421:16: error: redefinition of ‘y’
../src/filters/eedi3/eedi3.c:417:16: note: previous definition of ‘y’ was here
../src/filters/eedi3/eedi3.c:421:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c: In function ‘eedi3GetFrame’:
../src/filters/eedi3/eedi3.c:468:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:485:10: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:507:13: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c:518:19: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c: In function ‘eedi3Create’:
../src/filters/eedi3/eedi3.c:679:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
../src/filters/eedi3/eedi3.c: In function ‘eedi3GetFrame’:
../src/filters/eedi3/eedi3.c:463:7: warning: ignoring return value of ‘posix_memalign’, declared with attribute warn_unused_result [-Wunused-result]
../src/filters/eedi3/eedi3.c:465:7: warning: ignoring return value of ‘posix_memalign’, declared with attribute warn_unused_result [-Wunused-result]
Waf: Leaving directory `/home/xeon/Apps/vpsynth/build'
Build failed
-> task in 'eedi3' failed (exit status 1):
{task 17620048: c eedi3.c -> eedi3.c.3.o}
['/usr/bin/gcc', '-DVSCORE_EXPORTS', '-fPIC', '-O3', '-I/home/xeon/Apps/vpsynth/build/include', '-I/home/xeon/Apps/vpsynth/include', '-DHAVE_QTCORE=1', '-DHAVE_QTGUI=1', '-DHAVE_QTUITOOLS=1', '-DHAVE_QTNETWORK=1', '-DHAVE_QTOPENGL=1', '-DHAVE_QTSQL=1', '-DHAVE_QTSVG=1', '-DHAVE_QTTEST=1', '-DHAVE_QTXML=1', '-DHAVE_QTXMLPATTERNS=1', '-DHAVE_QTWEBKIT=1', '-DHAVE_QT3SUPPORT=1', '-DHAVE_QTHELP=1', '-DHAVE_QTSCRIPT=1', '-DHAVE_QTDECLARATIVE=1', '-DFEATURE_SHARED=1', '-DFEATURE_STATIC=0', '-DFEATURE_FILTERS=1', '-DFEATURE_CYTHON=1', '-DFEATURE_AVISYNTH=1', '-DFEATURE_DOCS=0', '-DFEATURE_EXAMPLES=0', '-DPATH_PREFIX="/usr/local"', '-DPATH_LIBDIR="/usr/local/lib"', '-DPATH_PLUGINDIR="/usr/local/lib/vapoursynth"', '-DPATH_DOCDIR="/usr/local/share/doc/vapoursynth"', '-DPATH_INCLUDEDIR="/usr/local/include/vapoursynth"', '-DHAVE_QTCORE_QTCORE=1', '-DHAVE_QATOMICINT=1', '-DHAVE_LIBAVUTIL_AVUTIL_H=1', '-DHAVE_AVUTIL_LICENSE=1', '-DHAVE_LIBSWSCALE_SWSCALE_H=1', '-DHAVE_SWSCALE_LICENSE=1', '../src/filters/eedi3/eedi3.c', '-c', '-o', 'src/filters/eedi3/eedi3.c.3.o']


Cheers

[Youka]

Isn't the error message very clear?
You're using gcc to compile eedi3.c as C source code. Old C doesn't allow declarations inside a for-loop header, like it's the case in this file, so you have to add C99 mode to compiler options for modern C to allow it.