Vapoursynth

[Myrsloik]

It is encoded as interlaced which unfortunately is used for a lot of progressive content too. The built in resizer doesn't support interlaced because it's evil and a lot of extra effort. You can script your own interlaced resizer or simply remove the _fieldbased property which will make all video be treated as progressive.

[LigH]

Originally Posted by stax76

MediaInfo says interlaced

Means, the MPEG2 encoder had been set up for interlaced encoding mode (regardless of the content; usually a safety measure in DVD studios).

Unfortunately, no idea how different VapourSynth behaves here, but for me, "field based" sounds as if you would apply SeparateFields() right after MPEG2Source() in AviSynth, in comparison (maybe MPEG2Source() even supports decoding to separate fields directly?). Sorry for wild guessing here.

[stax76]

this works:

clip = mvsfunc.AssumeFrame(clip)

https://github.com/HomeOfVapourSynth...sfunc.py#L1942

[foxyshadis]

Originally Posted by stax76

this works:

clip = mvsfunc.AssumeFrame(clip)

https://github.com/HomeOfVapourSynth...sfunc.py#L1942

If this is going to be part of Staxrip, then you'll want to make sure it's actually fake-interlaced progressive and not actually interlaced first!

[stax76]

Originally Posted by foxyshadis

If this is going to be part of Staxrip, then you'll want to make sure it's actually fake-interlaced progressive and not actually interlaced first!

It's added whenever MediaInfo says interlaced, why is it a big problem adding it for real interlaced?

@Myrsloik

Latest release works without AviSynth installed and vice versa, the cut feature depends on AviSynth though, it just generates a 16x16 pixel avi without audio using BlankClip and ffmpeg because mkvmerge can only cut if there is a video stream present. I should be able to code a VS version, after that both scripting engines are both absolutely on par and first class citizens in StaxRip.

edit:

Next built supports cutting without AviSynth being installed, ffmpeg can do the job alone without any scripting engine, also for video cutting the cool slicing syntax is now used.

[dipje]

Because if it is really interlaced (so weaved) and you're telling vapoursynth and all the filters that it is NOT interlaced, none of the filters and resizers will do 'interlaced-correct' stuff, and probably make a mess of it.

If you want to mark a clip as progressive when it is _wrongly_ flagged as interlaced, the Vapoursynth way (that I use anyway) is:

c = core.std.SetFrameProp(c, "_FieldBased", intval = 0)

(c being the clip)

It basically means set the '_FieldBased' property of all the frames to '0' (meaning progressive).


But like how I opened: This is only for _wrongly_ tagged interlaced-but-really-progressive material. Real interlaced should be tagged as interlaced so filters and scripts know it is interlaced and handle it accordingly.

Knowing when it is wrongly tagged as interlaced is the trick, and not something I'm interested in. I'm not spending energy on fixing wrong metadata in source material. The source is in error then, there, done. (Or in your case it might be the source plugin, who knows).

That being said, MeGUI has a 'detector' where it tries to see what the source really is, no matter how it is tagged in metadata or properties. How it works and what it really does, no clue.

[Myrsloik]

R32 test2

Consider it RC quality. I plan to make another maintenance release soon since I haven't had time to actually make any bigger changes.

r32:
extended avisynth mvtools compatibility hack to work for 64bit version as well 
fixed regression from r29 that would make compatyuy2 conversions vertically flipped
vspipe now outputs planar rgb in gbr plane order to better match what other software expects as input
now has a slightly more informative error message when the wrong type is passed as an argument in python
vsvfw now prints per frame errors on the corresponding frame
splicing two incompatible clips could sometimes give a confusing error message
removed planeaverage

[rakan]

Hi there,

I was trying to compile vapoursynth on Ubuntu 14.04 and I got this error...

  CXX      src/core/libvapoursynth_la-cachefilter.lo
  CC       src/core/libvapoursynth_la-cpufeatures.lo
  CXX      src/core/libvapoursynth_la-exprfilter.lo
In file included from src/core/exprfilter.cpp:37:0:
src/core/jitasm.h: In constructor 'jitasm::detail::ResultT<float, 4>::ResultT(float)':
src/core/jitasm.h:8533:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   ResultT(const float imm) : val_(Imm32(*(uint32*)&imm)) {}
                                                    ^
src/core/jitasm.h: In member function 'void jitasm::detail::ResultT<double, 8>::StoreResult(jitasm::Frontend&, const jitasm::detail::ResultDest&)':
src/core/jitasm.h:8608:67: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     f.mov(f.dword_ptr[f.rsp - 8], *reinterpret_cast<uint32*>(&imm_));
                                                                   ^
In file included from /usr/include/string.h:640:0,
                 from ./include/VSHelper.h:17,
                 from src/core/exprfilter.cpp:32:
In function 'void* memset(void*, int, size_t)',
    inlined from 'jitasm::Backend::Backend()' at src/core/jitasm.h:1030:32,
    inlined from 'void jitasm::Frontend::ResolveJump()' at src/core/jitasm.h:1739:12:
/usr/include/x86_64-linux-gnu/bits/string3.h:81:32: warning: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [enabled by default]
       __warn_memset_zero_len ();
                                ^
In function 'void* memset(void*, int, size_t)',
    inlined from 'jitasm::Backend::Backend()' at src/core/jitasm.h:1030:32,
    inlined from 'void jitasm::Frontend::Assemble()' at src/core/jitasm.h:1807:11:
/usr/include/x86_64-linux-gnu/bits/string3.h:81:32: warning: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [enabled by default]
       __warn_memset_zero_len ();
                                ^
  CXX      src/core/libvapoursynth_la-genericfilters.lo
  CXX      src/core/libvapoursynth_la-lutfilters.lo
  CC       src/core/libvapoursynth_la-mergefilters.lo
  CC       src/core/libvapoursynth_la-reorderfilters.lo
  CXX      src/core/libvapoursynth_la-settings.lo
  CC       src/core/libvapoursynth_la-simplefilters.lo
src/core/simplefilters.c: In function 'separateFieldsGetframe':
src/core/simplefilters.c:659:13: error: too few arguments to function 'vsapi->setFilterError'
             vsapi->setFilterError("SeparateFields: no field order provided");
             ^
make: *** [src/core/libvapoursynth_la-simplefilters.lo] Error 1

I just pulled the latest from git. Git log starts with...

commit 109ce5968eeaea0f7e503f3a3d2265fdb32dbd5d
Author: myrsloik <fredrik.mellbin@gmail.com>
Date:   Mon Mar 14 20:18:59 2016 +0100

    Make tff argument optional for separatefields

I rolled back git by one commit and got a little bit farther...

  CXX      src/core/libvapoursynth_la-cachefilter.lo
  CC       src/core/libvapoursynth_la-cpufeatures.lo
  CXX      src/core/libvapoursynth_la-exprfilter.lo
In file included from src/core/exprfilter.cpp:37:0:
src/core/jitasm.h: In constructor 'jitasm::detail::ResultT<float, 4>::ResultT(float)':
src/core/jitasm.h:8533:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   ResultT(const float imm) : val_(Imm32(*(uint32*)&imm)) {}
                                                    ^
src/core/jitasm.h: In member function 'void jitasm::detail::ResultT<double, 8>::StoreResult(jitasm::Frontend&, const jitasm::detail::ResultDest&)':
src/core/jitasm.h:8608:67: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     f.mov(f.dword_ptr[f.rsp - 8], *reinterpret_cast<uint32*>(&imm_));
                                                                   ^
In file included from /usr/include/string.h:640:0,
                 from ./include/VSHelper.h:17,
                 from src/core/exprfilter.cpp:32:
In function 'void* memset(void*, int, size_t)',
    inlined from 'jitasm::Backend::Backend()' at src/core/jitasm.h:1030:32,
    inlined from 'void jitasm::Frontend::ResolveJump()' at src/core/jitasm.h:1739:12:
/usr/include/x86_64-linux-gnu/bits/string3.h:81:32: warning: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [enabled by default]
       __warn_memset_zero_len ();
                                ^
In function 'void* memset(void*, int, size_t)',
    inlined from 'jitasm::Backend::Backend()' at src/core/jitasm.h:1030:32,
    inlined from 'void jitasm::Frontend::Assemble()' at src/core/jitasm.h:1807:11:
/usr/include/x86_64-linux-gnu/bits/string3.h:81:32: warning: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [enabled by default]
       __warn_memset_zero_len ();
                                ^
  CXX      src/core/libvapoursynth_la-genericfilters.lo
  CXX      src/core/libvapoursynth_la-lutfilters.lo
  CC       src/core/libvapoursynth_la-mergefilters.lo
  CC       src/core/libvapoursynth_la-reorderfilters.lo
  CXX      src/core/libvapoursynth_la-settings.lo
  CC       src/core/libvapoursynth_la-simplefilters.lo
  CXX      src/core/libvapoursynth_la-textfilter.lo
  CXX      src/core/libvapoursynth_la-vsapi.lo
  CXX      src/core/libvapoursynth_la-vscore.lo
  CXX      src/core/libvapoursynth_la-vslog.lo
  CXX      src/core/libvapoursynth_la-vsresize.lo
src/core/vsresize.cpp: In member function 'std::shared_ptr<{anonymous}::vszimg::graph_data> {anonymous}::vszimg::get_graph_data(const zimg_image_format&, const zimg_image_format&)':
src/core/vsresize.cpp:759:48: error: 'atomic_load' is not a member of 'std'
             std::shared_ptr<graph_data> data = std::atomic_load(data_ptr);
                                                ^
src/core/vsresize.cpp:762:17: error: 'atomic_store' is not a member of 'std'
                 std::atomic_store(data_ptr, data);
                 ^
make: *** [src/core/libvapoursynth_la-vsresize.lo] Error 1

[TalasNetrag]

R30 Blogpost

For those of you who still can’t live without certain Avisynth filters there are great news. Avisynth 2.6 plugins are now supported in both 32 and 64 bit builds. Note that 64 bit builds can’t use 2.5 plugins. Which isn’t a real problem since almost none exist anyway.

Is it possible to use .avsi skripts by putting then into the plugins folder? I am trying to use WarpDeRing.

Trying to use a path with a dash in it ("H:\01 - Encoding\01.mkv") results in the error:
vapoursynth.Error: Index: Can't open "H:\
- Encoding\01.mkv"

[Are_]

As far as I know, no, you can't, but that script has not any logic on it, so porting it is almost a copy past exercise.

About your error with the path try with an "r" before the path, like this:

(r"H:\01 - Encoding\01.mkv")

[feisty2]

the simple plugin I wrote runs pretty slooow
is it like, inline simd is a must or like, my programming skill blows considering my major is theoretical physics not computer science..

[Mystery Keeper]

Originally Posted by feisty2

the simple plugin I wrote runs pretty slooow
is it like, inline simd is a must or like, my programming skill blows considering my major is theoretical physics not computer science..

The key to make filters run fast is to branch the code ("if" and "switch" statements) as little as possible. Writing several very similar routines is better (perfomance-wise) than branching inside loops.

[MonoS]

Originally Posted by feisty2

the simple plugin I wrote runs pretty slooow
is it like, inline simd is a must or like, my programming skill blows considering my major is theoretical physics not computer science..

In my test with MVTools, GCC autovectorization works pretty well, try activating -O3 -march=native and see what you get performance wise, don't know if template will make autovectorization impossible.

Regarding Mystery Keeper comment, you can avoid branching using SSE, for example an abs function may be convertent branchless using

value = _mm_set_ps1(value_address);
value_abs = _mm_and_ps(pixel, mask of all 1 except MSB);
_mm_store1_ps(value_abs, value address);

A similar thing whit clamp

A branch like the one at line 87, 114, 126, etc, will not affect performance because they execute always the same path, and the processor is pretty good at knowing this.

In the end, as Myrsloik in the other thread, don't use the STL when writing the kernel, C++ is not zero-cost abstraction https://gist.github.com/rygorous/c6831e60f5366569d2e9

[Mystery Keeper]

I'd correct that to "STL is not zero-cost abstraction". C++ templates can be used for the said "very similar routines" and have no runtime overhead. And even <vector> can be used for safe memory allocation/deallocation. You can create it once and then work with raw memory (vector::data() / &vector[0]).

[LoRd_MuldeR]

I want to add that you should define _SECURE_SCL to 0 in your project settings when using STL with the Microsoft compiler - at least in Release builds.

AFAIK, the latest versions of Visual Studio do this automatically (for Release builds) now, but older versions definitely did not. And this can make a HUGE speed difference, in my experience!

So, if you think STL is slow in your project (and you use MSVC), then _SECURE_SCL should be one of the first things to check...

[asarian]

At the risk of sounding rude (which really isn't my intention), what's the point of VapourSynth to begin with?! Will I be able to use scripts like QTGMC with it? Or MCTemporalDenoise? I mean, I get it's Python and all; and that is pretty cool; but, so far, it just looks like a very rudimentary emulation of AviSynth, that will likely never be able to handle complex scripts like the above.

Just trying to figure out what the added value of VapourSynth is, really. 64-bit? From what I gather, looks like even Seth (MT) has given up on 64-bit. Can't say I blame him either, as getting all those complex stuff (with all third-party dll's) to 64-bit is just a humongeous endeavour that seems unlikely to ever fully happen.

Been off the video world for a spell, so I may be wrong on many things; if so, feel free to correct me.

[Boulder]

At least it doesn't crash like Avisynth MT and 64-bit environment is a big bonus. Why wouldn't it be able to handle such functions? QTGMC has been ported quite a while ago and it works well (and utilizes the CPU completely on my i7).

It takes a little to get used to but it's worth it.

[LigH]

@ asarian:

Your question proves that you took very little time to try to answer it for yourself. VapourSynth is not an emulation. It is a separate framework, not just a frameserver. It may support many features similar to what you are used to from AviSynth, but it has a different base. It was designed not to be restricted by the limits of AviSynth known from its origins when BenRG made it. One factor is the support of 64-bit memory addressing and multi-threading from the base. Another factor is support of different color spaces, also with higher component precisions than just 8 bit. A third is a possible integration in separately running applications. Reading about its history, you may find a few more...

[asarian]

Originally Posted by Boulder

At least it doesn't crash like Avisynth MT and 64-bit environment is a big bonus. Why wouldn't it be able to handle such functions? QTGMC has been ported quite a while ago and it works well (and utilizes the CPU completely on my i7).

It takes a little to get used to but it's worth it.

This is all good news! I knew there *had* to be a good reason for someone to start a project like this. Thank you for your clarification!

I shall look into this more, as 64-bit truly is a *major* thing for me. Currently, with 1080p material, I can manage barely (with the avs2yuv process separation trick); and some things (like very complex upscaling) just runs out of memory in the 32-bit environment.

[asarian]

Originally Posted by LigH

@ asarian:

Your question proves that you took very little time to try to answer it for yourself. VapourSynth is not an emulation. It is a separate framework, not just a frameserver. It may support many features similar to what you are used to from AviSynth, but it has a different base. It was designed not to be restricted by the limits of AviSynth known from its origins when BenRG made it. One factor is the support of 64-bit memory addressing and multi-threading from the base. Another factor is support of different color spaces, also with higher component precisions than just 8 bit. A third is a possible integration in separately running applications. Reading about its history, you may find a few more...

Why, like I said, I didn't mind being corrected if I was wrong. Looks like I really need to try and give VapourSynth a chance. And, apart from 64-bit, native (stable) multi-threading will be welcomed too!