Vapoursynth

[stax76]

470bg

You really should do this experimentation in a separate script with vspipe. Then it will tell you what the error is.

gives also blackness


D:\>"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" "D:\Video\Samples\DVD\Pulp Fiction\VTS_01_1 temp files\VTS_01_1_Preview.vpy" - --y4m | "D:\Projekte\GitHub\staxrip\bin\Apps\x265\x265_ml.exe" --crf 22 --preset ultrafast --frames 2970 --y4m --sar 16:11 --output "D:\Video\Samples\DVD\Pulp Fiction\VTS_01_1 temp files\VTS_01_1_out.hevc" -
Error: Can only apply y4m headers to YUV and Gray format clips
Output 0 frames in 0.03 seconds (0.00 fps)
x265 [error]: unable to open input file <->



import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'D:\Projekte\GitHub\staxrip\bin\Apps\Plugins\vs\vslsmashsource\vslsmashsource.dll')
clip = core.lsmas.LWLibavSource(source = r'D:\Video\Samples\DVD\Pulp Fiction\VTS_01_1 temp files\VTS_01_1.m2v')
clip = clip.resize.Bicubic(matrix_in_s = '470bg', format = vs.COMPATBGR32)
clip.set_output()

[Are_]

Just curious, does "matrix_in_s" exists at all? It is listed like that in the documentation in one example but not anywhere else.

It should be "matrix_in"? If that is the case, it makes me think you are still not using a proper console to debug vapoursynth scripts. If you are using a simple "vspipe script.vpy NUL" then I don't know why it does not output the error.

[LigH]

Are you really a programmer, stax76? ;) Read the error message, try to understand it. Then avoid provoking it, and continue to the next layer. — Try the simplest of all cases:

vspipe VTS_01_1_Preview.vpy > NUL

And hope that STDERR will contain something related to the content of the script, not to the (in this case, due to the output attributes) unsupported parameter of the command line.

[Myrsloik]

Just curious, does "matrix_in_s" exists at all? It is listed like that in the documentation in one example but not anywhere else.

It should be "matrix_in"?

There are two versions of many arguments. The matrix_in version with takes an integer. But remembering the ITU assigned number for your favorite matrix is hard. So you can also specify it with a string using the matrix_in_s version which is usually easier to remember.

[stax76]

Just curious, does "matrix_in_s" exists at all? It is listed like that in the documentation in one example but not anywhere else.

It should be "matrix_in"?
------
Arguments denoted as type enum may be specified by numerical index (see ITU-T H.265 Annex E.3) or by name. Enums specified by name have their argument name suffixed with “_s”. For example, a destination matrix of BT 709 can be specified either with matrix=1 or with matrix_s="709".

[Are_]

My fault, I was thinking the initial call of functions in the help was auto-generated from the source code with all possible valid values for the variables.

[stax76]

The problem is also with Intel GPU, at least HD works now.

[Myrsloik]

I made this build (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r32-test1.exe) just for you. Have fun.

r32:
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

[stax76]

my preview shows now: Resize error: Resize: field-based video not supported


import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'D:\Projekte\GitHub\staxrip\bin\Apps\Plugins\vs\vslsmashsource\vslsmashsource.dll')
clip = core.lsmas.LWLibavSource(source = r'D:\Video\Samples\DVD\Pulp Fiction\VTS_01_1 temp files\VTS_01_1.m2v')
clip = clip.resize.Bicubic(matrix_in_s = '470bg', format = vs.COMPATBGR32)
clip.set_output()



Video

Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Format settings, picture structure: Frame
Duration : 1mn 58s
Bit rate mode : Variable
Bit rate : 4 527 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.437
Time code of first frame : 00:00:00:00
GOP, Open/Closed : Open
Stream size : 64.1 MiB (100%)

[stax76]

the source looks progressive in DGIndex though MediaInfo says interlaced

if I load a source where MediaInfo says progressive then it works fine

thanks everybody for the help!

[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]

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/HomeOfVapourSynthEvolution/mvsfunc/blob/master/mvsfunc.py#L1942

[foxyshadis]

this works:

clip = mvsfunc.AssumeFrame(clip)

https://github.com/HomeOfVapourSynthEvolution/mvsfunc/blob/master/mvsfunc.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]

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 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r32-test2.exe)

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 (http://avisynth.nl/index.php/WarpDeRing_source).

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]

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]

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]

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]

@ 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!

[stax76]

@asarian

Maybe have a look at StaxRip.

https://github.com/stax76/staxrip/wiki/Test-Build

[asarian]

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.

Am I right in not seeing 64-bit installers for it? Only a portable 64-bit, it seems. Will that work with the Pismo File Mount Audit Package too?

And yes, I just found the full port of QTGMC. :) This looks promising. Now only MCTemporalDenoise, at some point, and I'm all set.

[Myrsloik]

Am I right in not seeing 64-bit installers for it? Only a portable 64-bit, it seems. Will that work with the Pismo File Mount Audit Package too?

And yes, I just found the full port of QTGMC. :) This looks promising. Now only MCTemporalDenoise, at some point, and I'm all set.

The installer has both versions. You need to have x64 python installed first too.

[asarian]

The installer has both versions. You need to have x64 python installed first too.

Okay, cool. :) Thx.

[Efenstor]

Hi guys. Is it possible to make VapourSynth read source from a pipe? I want something like
ffmpeg -f rawvideo - | vspipe --y4m proc_vs.py - | ffmpeg -i pipe: output.mkv

The reason for this is that the pullup filter from ffmpeg works so much better than VIVTC on the footage I want to process. In fact, VIVTC doesn't seem to work at all - I dunno if it is bug or not, but I do everything right and my footage is nothing special, just a telecined 24p AVCHD video shot with a Canon camcorder.

Here is the VIVTC code that does not work
import vapoursynth as vs
core = vs.get_core()

# Source
video = core.ffms2.Source('00066.MTS')
video = video.std.AssumeFPS(fpsnum=30000, fpsden=1001)

# Process
video = core.vivtc.VFM(clip=video, order=1)
video = core.vivtc.VDecimate(video)

# Output
video.set_output()
The output is still combed. Anyway I remember that when I tried the AviSynth's IVTC plugin a few years ago it occasionally been leaving combing behind as well as some duplicate frames, which ffmpeg's pullup never does. At least for my case ffmpeg performs absolutely perfectly with no parameter fiddling at all. Any chance of porting it to VS? )))

[Myrsloik]

Hi guys. Is it possible to make VapourSynth read source from a pipe? I want something like
ffmpeg -f rawvideo - | vspipe --y4m proc_vs.py - | ffmpeg -i pipe: output.mkv

The reason for this is that the pullup filter from ffmpeg works so much better than VIVTC on the footage I want to process. In fact, VIVTC doesn't seem to work at all - I dunno if it is bug or not, but I do everything right and my footage is nothing special, just a telecined 24p AVCHD video shot with a Canon camcorder.

Here is the VIVTC code that does not work
import vapoursynth as vs
core = vs.get_core()

# Source
video = core.ffms2.Source('00066.MTS')
video = video.std.AssumeFPS(fpsnum=30000, fpsden=1001)

# Process
video = core.vivtc.VFM(clip=video, order=1)
video = core.vivtc.VDecimate(video)

# Output
video.set_output()
The output is still combed. Anyway I remember that when I tried the AviSynth's IVTC plugin a few years ago it occasionally been leaving combing behind as well as some duplicate frames, which ffmpeg's pullup never does. At least for my case ffmpeg performs absolutely perfectly with no parameter fiddling at all. Any chance of porting it to VS? )))

You should probably use d2vsource, ffms2 with mts is bad luck. It could be bad decoding that makes ivtc fail.

Modified raw source with pipe input (http://forum.doom9.org/showthread.php?p=1755073#post1755073)

[LigH]

L-SMASH Source for AviSynth used to be quite reliable in this case. Still, it may in general be a good idea to rip your Blu-ray's main movie to MKV first (e.g. using MakeMKV) before converting it further: Matroska has less container overhead than M2TS, and the fine granularity makes TS parsing quite slow.

[Efenstor]

You should probably use d2vsource, ffms2 with mts is bad luck. It could be bad decoding that makes ivtc fail.

Modified raw source with pipe input (http://forum.doom9.org/showthread.php?p=1755073#post1755073)

Thanks Myrsloik! You should've put the link to vsrawsource mod before everything else. :) I just tried d2vsource but cannot produce the d2v file, as D2VWitch freezes on startup and I can't use DGIndex as I'm on Linux.

In fact, would I be on Windows I would be pretty happy with AviSynth but as I am a Linux-man, I've been waiting for something like AvxSynth but with a lot of plugins for quite a time. Of course, I've tried to run AviSynth under Wine but it's too... too incorrect you know, when it's Linux. Also too much CPU power gets lost in the translation.

[Efenstor]

L-SMASH Source for AviSynth used to be quite reliable in this case. Still, it may in general be a good idea to rip your Blu-ray's main movie to MKV first (e.g. using MakeMKV) before converting it further: Matroska has less container overhead than M2TS, and the fine granularity makes TS parsing quite slow.

Thanks LigH, I'll try it. By the way, I think ffmpeg will do that as well:
ffmpeg -i input.mts -scodec copy -acodec copy -vcodec copy -f matroska input.mkv

[Efenstor]

L-SMASH Source for AviSynth used to be quite reliable in this case. Still, it may in general be a good idea to rip your Blu-ray's main movie to MKV first (e.g. using MakeMKV) before converting it further: Matroska has less container overhead than M2TS, and the fine granularity makes TS parsing quite slow.

Turned out it was one really good idea, and the only one which helped me through to the VIVTC. Now it works, although it required me some toil with compilation. I know it's unavoidable as VapourSynth and its plugins are all in the alpha stage.

For the newbies who are interested how to process AVCHD .MTS files on Linux with VapourSynth here are a few tricks.

1. Compiling plugins: there are no binaries yet at all, learn how compile from sources. Always clone everything from GitHub, outdated stable releases may not compile successfully. Don't forget about -Ofast (or -O3 if you get errors), otherwise you won't get the full speed.
2. Compiling L-Smash: configure with ./configure --enable-shared
3. Compiling the V.C.Mohan's vcmove (as suggested by _Are):
mv ReformHelper.cpp reformHelper.cpp
gcc -fPIC -shared -std=c++11 -Ofast vcmove.cpp -o libvcmove.so
I guess vcmod, vcfreq and the others are compiled in the same manner, although I did not yet tried.

4. Basic bash script for processing a single file. Input file name is specified as an argument, the rest is in the user definitions.
#!/bin/bash

# User defines
vspath=/usr/local/lib/python3.4/site-packages
ffmpeg_options_out="-vcodec ffvhuff -acodec pcm_s16le"
dst_dir="."
dst_ext="avi"

# Prepare some vars
filename=$(basename "$1")
filename_out="$dst_dir/${filename%.*}.$dst_ext"

# Remove the output file if already exists
if [ -e $filename_out ]; then
rm $filename_out
fi

# Process
env PYTHONPATH=$vspath vspipe -a filename="$1" -y proc.py - | \
ffmpeg -i pipe: $ffmpeg_options_out $filename_out
5. Basic batch processing. No arguments, edit the user definitions.
#!/bin/bash

# User defines
vspath=/usr/local/lib/python3.4/site-packages
src_dir="."
src_ext="mts"
ffmpeg_options_out="-vcodec ffvhuff -acodec pcm_s16le"
dst_dir="proc"
dst_ext="avi"

# Do processing
files=$(find "$src_dir" -maxdepth 1 -iname "*.$src_ext" | sort -n)
for i in $files ; do

# Prepare some vars
filename=$(basename "$i")
filename_out="$dst_dir/${filename%.*}.$dst_ext"

# Remove the output file if already exists
if [ -e $filename_out ]; then
rm $filename_out
fi

# Process
env PYTHONPATH=$vspath vspipe -a filename="$i" -y proc.py - | \
ffmpeg -i pipe: $ffmpeg_options_out $filename_out
if [ $? -ne 0 ]; then
exit $?
fi

done
6. Basic proc.py:
import vapoursynth as vs
core = vs.get_core()

clip = core.lsmas.LWLibavSource(filename)

#Processing goes here

clip.set_output()

[asarian]

The installer has both versions. You need to have x64 python installed first too.

Have 64-bit Python installed; the "vapoursynth-r31.exe" installer still wants to install to C:\Program Files (x86), though. So it may not be the 64-bit version after all?!

[Myrsloik]

Have 64-bit Python installed; the "vapoursynth-r31.exe" installer still wants to install to C:\Program Files (x86), though. So it may not be the 64-bit version after all?!

Look atcthe component selection, not the path. You'll ser it say 64bit.

[asarian]

Look atcthe component selection, not the path. You'll ser it say 64bit.

Yeah, my bad. LOL. That was only 1 sceen further in! :P

[asarian]

So, dumb question probably, but how does VSFS work? (As opposed to AVFS) Got AVFS working just fine now.

'vsfs' is not recognized as an internal or external command,

[asarian]

So, dumb question probably, but how does VSFS work? (As opposed to AVFS) Got AVFS working just fine now.

'vsfs' is not recognized as an internal or external command,


Anyone?! I can understand 'VSPipe -' doesn't output to a file; but shouldn't an output file otherwise show up in the VSFS somewhere?!

[poisondeathray]

So, dumb question probably, but how does VSFS work? (As opposed to AVFS) Got AVFS working just fine now.

'vsfs' is not recognized as an internal or external command,

Anyone?! I can understand 'VSPipe -' doesn't output to a file; but shouldn't an output file otherwise show up in the VSFS somewhere?!


You need to register VSFS first, it's described in the instructions under "installation of VSFS"

http://www.vapoursynth.com/doc/installation.html

Otherwise it's analgous to AVFS - a "virtual" AVI will appear in the c:\volumes folder

[asarian]

You need to register VSFS first, it's described in the instructions under "installation of VSFS"

http://www.vapoursynth.com/doc/installation.html

Otherwise it's analgous to AVFS - a "virtual" AVI will appear in the c:\volumes folder


Thanks for replying. The doumentation said

"By default VSFS will be registered if the Pismo File Mount Audit Package was installed before VapourSynth."

Hence, I hadn't registered it manually. So I did

pfm register "C:\Program Files (x86)\VapourSynth\core64\vsvfw.dll"

It registers okay, but still not seeing anything appear in c:\volumes when I run a job.

[poisondeathray]

Hence, I hadn't registered it manually. So I did

pfm register "C:\Program Files (x86)\VapourSynth\core64\vsvfw.dll"

It registers okay, but still not seeing anything appear in c:\volumes when I run a job.

How are you "running" the job ?

The newer versions use the commandline
eg.
vsfs input.vpy
or
start vsfs input.vpy

I'm using an older version, that runs from the context menu, and you right click, mount

[asarian]

How are you "running" the job ?

The newer versions use the commandline
eg.
vsfs input.vpy
or
start vsfs input.vpy

I'm using an older version, that runs from the context menu, and you right click, mount


The problem, for me, is that 'vsfs' doesn't seem to exist, anywhere (unlike avfs). Like:

F:\jobs>start vsfs neela.vpy
The system cannot find the file vsfs.

F:\jobs>vsfs neela.vpy
'vsfs' is not recognized as an internal or external command,
operable program or batch file.

'vsfs' (other than the dll) is nowhere to be found on my system.

[poisondeathray]

pfm register "C:\Program Files (x86)\VapourSynth\core64\vsvfw.dll"


Is that the correct .dll or a typo ?

In the older version I'm using it's vsfs.dll , not vsvfw.dll

Things might have changed, if it's vsvfw.dll, try calling it with vsvfw neela.vpy

Also there might some differences with portable vs installed version. I'm using an old installed version