Vapoursynth

[CarlPig]

CarlPig, have you already looked at the documentation?
ttp://www.vapoursynth.com/doc/index.html

And at this post, which explains usage with x264?
http://forum.doom9.org/showpost.php?p=1521791&postcount=1

:readguid:

I have now looked at the documentation.

But can't still not figure out of that, so i hope someone will help me start.

I hope its spelled correctly, because im not so good to english.

[SassBot]

Can't figure what out? The first post made by Myrsloik tells you how to use it with x264:


The easiest way to pipe to x264:
1. Import the sys module in your python script.
2. To output a clip to stdout simply add "someclip.output(sys.stdout, y4m=True)" to your script.
3. Run the script with this command: python script.py | x264 --demuxer y4m --output encodedfile.mkv -
(only works for yuv formats with an y4m header value)

There are also numerous script examples throughout this thread in addition to this sample in the documentation here (http://www.vapoursynth.com/doc/gettingstarted.html). How much more explicit does it need to be?

[mandarinka]

So I'm taking a crack at porting ColorMatrix to Vapoursynth

Color adjustment like this is a kind of operation that would benefit from being able to work in/output higher than 8-bit precision data. Wouldn't it be better to build a solution around Dither tools?

Currently you can script colormatrix conversion with it, but it forces you to upsample and downsample chroma.

[SassBot]

Since ColorMatrix is used almost exclusively for sources that are 8-bit and will be reencoded as 8-bit what would be the point? Also, it's more of a way for me to refresh my knowledge on Avisynth plugin development and get into Vapoursynth plugin development. If you want to make something based on dither tools for Vapoursynth to do the same thing, go ahead. My interest is in the learning.

[Myrsloik]

It's time for another release! This time it's the equivalent of conditional filtering that gets a huge improvement and I enabled more of the cache memory management now that I have more complex scripts to test with. I also added a slightly revised version of the avisynth core filters to the downloads.

As usual the bloggy post is here (http://www.vapoursynth.com/2012/10/r13-conditional-filtering-and-memory-optimizations/) and consider adopting your favorite avisynth filter and porting it.

You should also take a look at Chikuzen's filters if you haven't done so already.

[Are_]

I don't know if I'm doing something wrong, but r13 module does not load in Python.

I get the following error on wine:

$ ./vs-enc.sh test.vpy
err:module:import_dll Library MSVCR100D.dll (which is needed by L"C:\\Python33\\lib\\site-packages\\vapoursynth.dll") not found
err:module:import_dll Library vapoursynth.dll (which is needed by L"C:\\Python33\\lib\\site-packages\\vapoursynth.pyd") not found
Traceback (most recent call last):
File "test.vpy", line 4, in <module>
import vapoursynth as vs
ImportError: DLL load failed: Module not found.
x264 [error]: could not open input file `-'

I tried too on Windows 7 and fails to load too, but less verbose.
And vcredist 2010 is installed in both machines. R12 loads fine.

[Myrsloik]

Once again I mess up use a debug compile. The r13 installer has been updated.

Also, why are you using vs in wine?

[Are_]

Thx Myrsloik.

Because I use Linux as my desktop mainly, personal preferences I suppose, and if I compile it natively I get stuck with native filters (64bit, although this is a guess on my side).
Anyway, don't worry, if something fails there I make sure it's not OS related before reporting.

[SassBot]

So outside of recompiling Vapoursynth is there any way I can test my ported ColorMatrix since you have it blacklisted? :p

[Myrsloik]

So outside of recompiling Vapoursynth is there any way I can test my ported ColorMatrix since you have it blacklisted? :p

Blacklisted? I only print a warning when you load the original avisynth one. I crashes so well on its own I never saw a reason to actively stop it.

[SassBot]

Ok, nm. It was an unrelated error throwing up.

[kolak]

import vapoursynth as vs
import sys
core = vs.Core(threads=6)
core.std.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\ffms2.dll')
ret = core.ffms2.Source(source=r'S:\temp\Avatar_ProRes_L.mov',threads=6)
a= core.resize.Spline(clip=ret, width=720, height=576,format=vs.YUV422P10)
last= core.resize.Spline(clip=a, width=1920, height=1080,format=vs.YUV422P10)
enable_v210=True

compared to:

import vapoursynth as vs
import sys
core = vs.Core(threads=6)
core.std.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\ffms2.dll')
ret = core.ffms2.Source(source=r'S:\temp\Avatar_ProRes_L.mov',threads=6)
a= core.resize.Spline(clip=ret, width=720, height=576,format=vs.YUV422P10)
last= core.resize.Spline(clip=a, width=1920, height=1080,format=vs.COMPATYUY2)
#enable_v210=True

runs about 4x faster (1st one is faster). Why?

[Myrsloik]

import vapoursynth as vs
import sys
core = vs.Core(threads=6)
core.std.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\ffms2.dll')
ret = core.ffms2.Source(source=r'S:\temp\Avatar_ProRes_L.mov',threads=6)
a= core.resize.Spline(clip=ret, width=720, height=576,format=vs.YUV422P10)
last= core.resize.Spline(clip=a, width=1920, height=1080,format=vs.YUV422P10)
enable_v210=True

compared to:

import vapoursynth as vs
import sys
core = vs.Core(threads=6)
core.std.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\ffms2.dll')
ret = core.ffms2.Source(source=r'S:\temp\Avatar_ProRes_L.mov',threads=6)
a= core.resize.Spline(clip=ret, width=720, height=576,format=vs.YUV422P10)
last= core.resize.Spline(clip=a, width=1920, height=1080,format=vs.COMPATYUY2)
#enable_v210=True

runs about 4x faster (1st one is faster). Why?

It's swscale. Its design makes no sense at all. I can however tell you that some conversion paths are "optimized". Nobody will give you a clearer answer than this since the code is so unreadable.

[SassBot]

Quick question, ColorMatrix does a check when processing interlaced footage to see if it's FieldBased and it errors out if it is. Is this check even still relevant or necessary for VapourSynth?

[Myrsloik]

Quick question, ColorMatrix does a check when processing interlaced footage to see if it's FieldBased and it errors out if it is. Is this check even still relevant or necessary for VapourSynth?

I have a different idea about field handling. The user knows best. So let the users mess up if they want to.

Maybe I'll specify some frame property for specifying frame/field based but I don't think it's necessary judging by how random it is in avisynth anyway.

[SassBot]

Okay, then I'll just omit the check. It can be fixed if leaving it out actually causes an issue for someone.

[Pat357]

a= core.resize.Spline(clip=ret, width=720, height=576,format=vs.YUV422P10)
last= core.resize.Spline(clip=a, width=1920, height=1080,format=vs.YUV422P10)
enable_v210=True

compared to:

a= core.resize.Spline(clip=ret, width=720, height=576,format=vs.YUV422P10)
last= core.resize.Spline(clip=a, width=1920, height=1080,format=vs.COMPATYUY2)
#enable_v210=True

runs about 4x faster (1st one is faster). Why?


It depends on the source format; In the first, you do :
Source -> YUV422P10 -> YUV422P10

In the second you do an additional conversion :
Source -> YUV422P10 -> COMPATYUY2
This is a conversion from a 10b format (YUV422P10) to 8 bit packed format. I'm not sure if swscale does it, but this should also be dithered of course.

This is 0 conversions for first case against 1 conversion for 2e case. (assuming source is also YUV422P10)

Why do you scale in 2 "steps" ?

[mandarinka]

Since ColorMatrix is used almost exclusively for sources that are 8-bit and will be reencoded as 8-bit what would be the point?

To prevent banding. Obviously you can encode to 10bit afterwards, too!

In my usage, sources that needed colormatrix conversion needed level conversion too*, and with two such adjustments, the odds of banding really increase.

* They were DVD sources that in fact had pc levels and bt709 colormatrix. True, you can solve this by flagging the h.264 streams, but then almost no playback environment respects those. Hence why you sorta need to actually convert the video.

[SassBot]

How exactly does ColorMatrix introduce banding or how would using anything greater than 8-bit within ColorMatrix prevent it? Why would using greater than 8-bit for a filter that is only really for 8-bit sources going to do anything useful?

I can see adding support for other colorspaces, but I still don't see how processing say YV12 at 10-bit or higher is going to do anything useful as I've never seen nor heard anyone complain that ColorMatrix introduces banding.

[Myrsloik]

How exactly does ColorMatrix introduce banding or how would using anything greater than 8-bit within ColorMatrix prevent it? Why would using greater than 8-bit for a filter that is only really for 8-bit sources going to do anything useful?

I can see adding support for other colorspaces, but how would processing YV12 at greater than 8-bit do anything useful?

It's most likely simple rounding errors. You can see them surprisingly quickly if you only have 8 bits per channel.

I hope the world will switch to something like 16bit precision when processing things soon...

[SassBot]

I guess, but unless someone is seeing drastic issues with ColorMatrix adding banding I don't think implementing the processing at 10-bit or higher for YV12 is really useful effort. If it is it would be the first time I've ever heard of it doing so.

Edit to add: Yes, I realize the theoretical issue that can crop up by rounding errors, but unless someone can show some actual banding issues I'm not going to spend my time writing a solution for a theorectical problem that I've never seen with my eyes. But at this point I'm not going to derail the thread on that topic anymore.

[kolak]

This is a conversion from a 10b format (YUV422P10) to 8 bit packed format. I'm not sure if swscale does it, but this should also be dithered of course.

Why do you scale in 2 "steps" ?

There is no specific need in my scripts- it was done just for testing.

It's bit strange that scaling + 10 to 8bit conversion is so slow.

When you do one scaling:

a= core.resize.Spline(clip=ret, width=720, height=576,format=vs.YUV422P10)

and than:

a= core.resize.Spline(clip=ret, width=720, height=576,format=vs.COMPATYUY2)

than speed is about the same (even if ProRes source gets decoded to 10bit). As Myrsloik said- there is some mess in swscale.

[active1]

i have a problem with vapoursynth on linux, it crashes after encoding 1 frame (when piping to x264-10bit)

python3 test.py | x264 --demuxer y4m --output encodedfile.mkv -
y4m [info]: 1280x720p 0:0 @ 3908/143 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High 10, level 3.1, 4:2:0 10-bit
y4m [error]: bad header magic (400040 <=> @)
y4m [error]: bad header magic (40004000 <=> )
x264 [info]: frame I:1 Avg QP:45.00 size: 2350
x264 [info]: mb I I16..4: 97.6% 0.0% 2.4%
x264 [info]: 8x8 transform intra:0.0%
x264 [info]: coded y,uvDC,uvAC intra: 1.4% 2.2% 2.2%
x264 [info]: i16 v,h,dc,p: 100% 0% 0% 0%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 76% 0% 24% 0% 0% 0% 0% 0% 0%
x264 [info]: i8c dc,h,v,p: 2% 0% 98% 0%
x264 [info]: kb/s:513.78

encoded 1 frames, 8.47 fps, 668.13 kb/s
Traceback (most recent call last):
File "test.py", line 6, in <module>
v.output(sys.stdout, y4m=True)
File "vapoursynth.pyx", line 658, in vapoursynth.VideoNode.output (build/src/cython/vapoursynth.c:10442)
vapoursynth.Error: 'write() call returned error'



script:
import vapoursynth as vs
import sys
c = vs.Core()
c.std.LoadPlugin('/usr/local/lib/libffms2.so')
v=c.ffms2.Source('/home/200.mkv')
v.output(sys.stdout, y4m=True)


and this is the clip (https://www.dropbox.com/s/3m3pr61ycoq33my/200.mkv)
there is nothing special in that clip, and that is the problem :(
i always have this problem, but sometimes more than 1 frame encoded
and i tried to view script by piping it to avplay, then all what i get is a green window

[JEEB]

...
Not in any way Linux specific, and these extensions aren't yet in libav as far as I know.

I wrote the support for the high bit depth Y4M extensions into x264's y4m input module only some time ago, and that stuff isn't in the main repository yet, so trying to pass it as y4m will fail right now unless you apply the patch (https://github.com/DarkShikari/x264-devel/commit/a7530d18bef4a32c79e60094e4f6195ef333057f.patch).

[qyot27]

Since the extensions are on FFmpeg's side, it is possible to pipe from python, through ffmpeg, and then to x264. Of course, that last pipe wouldn't be necessary if ffmpeg was built with libx264 linked in. Might also be the only way to preview it using mplayer, as I can't remember if one linked against ffmpeg inherits the support for higher bit depths too, or if that's strictly internal. Although at that point you could also use ffplay to do it.
python3 testscript.vpy | ffmpeg -i - -f yuv4mpegpipe - | x264 [options as usual]
or
python3 testscript.vpy | ffmpeg -i - -vcodec libx264 -preset ultrafast -tune zerolatency -crf 18 outputfile

EDIT: Yeah, that totally doesn't work when dealing with high bit depths. Took me this long to get around to test it. ffmpeg can turn it into a compatible rawvideo stream, though. So it doesn't change the fact that getting y4m+hbd to work right with x264 will have to wait on that patch.

[Chikuzen]

Why everyone want to use shell ?
I think that one of the big advantage of VapourSynth is that it can control by Python (https://gist.github.com/3804501) easily :rolleyes:

[Pat357]

Since the extensions are on FFmpeg's side, it is possible to pipe from python, through ffmpeg, and then to x264.
python3 testscript.vpy | ffmpeg -i - -f yuv4mpegpipe - | x264 [options as usual]

How would this extra piping through ffmpeg change the 10 or 16bit format ? FFmpeg gets Y4M , does it output also Y4M via the pipe to x264 ?
What format does x264 get ? Still y4m ?

[Chikuzen]

After update VS to r13, I got an issue.


#sample.vpy
import vapoursynth as vs
core = vs.Core()
core.std.LoadPlugin('G:/vsplugins/vsrawsource.dll')
clip = core.raws.Source('D:/test_media/soccer.y4m')
last = clip


#sample.avs
AVISource('sample.vpy')


> x264.exe ./sample.avs -o out.h264


This works normally on r12.
However, on r13, x264 (and the other tools using avisynth_c interface like avs2yuv, avs2pipemod, etc) stops after displaying the message "Bad fpu state detected after plugin load"

what is "Bad fpu state" ?
How should I do ?

[Myrsloik]

After update VS to r13, I got an issue.


#sample.vpy
import vapoursynth as vs
core = vs.Core()
core.std.LoadPlugin('G:/vsplugins/vsrawsource.dll')
clip = core.raws.Source('D:/test_media/soccer.y4m')
last = clip


#sample.avs
AVISource('sample.vpy')


> x264.exe ./sample.avs -o out.h264


This works normally on r12.
However, on r13, x264 (and the other tools using avisynth_c interface like avs2yuv, avs2pipemod, etc) stops after displaying the message "Bad fpu state detected after plugin load"

what is "Bad fpu state" ?
How should I do ?
Which compiler did those other tools use? If I'm right then recompiling them with msvc will fix it.
You get that error when when something messes up the fpu control word. Some compilers change it just for fun. See this post for a longer explanation: http://virtualdub.org/blog/pivot/entry.php?id=53
I suppose my strict check is too much for the avisynth mess...

[Chikuzen]

Which compiler did those other tools use?
maybe, mingw-w64-gcc.
I downloaded it from x264.nl (compiled by JEEB).
If I'm right then recompiling them with msvc will fix it.
How can I compile x264 with MSVC ?
It's not libav.

[Myrsloik]

maybe, mingw-w64-gcc.
I downloaded it from x264.nl (compiled by JEEB).

How can I compile x264 with MSVC ?
It's not libav.

Hmm... I'll think of something for the next version... I'll probably just replace that check with a huge warning in R14.

[Myrsloik]

Here's my latest creation: VIVTC (https://dl.dropbox.com/u/73468194/vivtc.dll)
The matching metric calculation is directly based on TFM but all the logic around has been rewritten, parts of it estimated from the tfm manual's vague descriptions. VDecimate is written from scratch and uses a similar method to both decomb and tdecimate.

See it as a portable "TIVTC lite" with most features cut since nobody changes the defaults anyway. The only real new feature is that VFM has support for directly applying its matches to another clip (use the clip2 argument for that).

I also wrote a bloggy post (http://www.vapoursynth.com/2012/10/open-binary-introducing-a-practical-alternative-to-open-source/) that tries to be funny. It's about open source in its more degenerate forms.

[wOxxOm]

So VFM uses clip2 differently from TFM which was using it for combed frames only? Also, 'ovr', 'output' parameters were immensely useful. And I wonder if is it possible to display a tfm(display=true)-like video overlay with frame stats like MI, field match, etc

[Myrsloik]

So VFM uses clip2 differently from TFM which was using it for combed frames only? Also, 'ovr', 'output' parameters were immensely useful. And I wonder if is it possible to display a tfm(display=true)-like video overlay with frame stats like MI, field match, etc

Correct. It has no built in pp and clip2 is used to apply matches to. I will make it hint pp stuff properly later. It already attaches all calculated metrics to the output frames though. Maybe I'll reimplement some additional features later that I feel are missing, like ovr. Actually that's the only one I feel is missing. Maybe display once some other things are into place... other people are working on some interesting things for vs.

If you want tfm then use tfm. I'm not going to add that many features. I suggest you always use vdecimate in vs though since it should be faster.

Oh,I believe vivtc in its current state is good enough for 95% of the tivtc users. Patches are of course accepted if you want to add a specific feature yourself. See my latest bloggy post for examples on why I junked tivtc and started over instead of porting it.

[wOxxOm]

Thank you. I liked that blog post :)
Frame properties would be quite enough I suppose _if_ those could be used in a user defined function, like clip2=userfunc(statsclip) for example or somehow else, to selectively deint/postprocess some frames based on metrics. As for displaying metrics: if those could be read as frame properties then it'll be possible to make a user function that uses Subtitle to output them I guess, but not that rectangle that tfm draws where it finds combing. Anyway, I agree, your current implementation covers almost 100% of commonly used functionality.

p.s. It occured to me that there's probably no need to pass stats to clip2 user function if I can iterate through frames and apply processing depending on frame properties added previously by VFM.

[sneaker_ger]

Since the number of frames has been reduced it probably only forgot to AssumeFPS afterwards?

[Myrsloik]

Since the number of frames has been reduced it probably only forgot to AssumeFPS afterwards?

Right, I forgot the fps... there are also some other small details left to fix. My next project will be something that adds a bit more masktools/overlay functionality I think

[Chikuzen]

@Myrsloik
How about adding new color family which has four planes ?
I think that it is useful for alpha support.

[Myrsloik]

@Myrsloik
How about adding new color family which has four planes ?
I think that it is useful for alpha support.

I'm thinking about it. It probably should be added in some way... but it's complicated. Sometimes alpha should be processed too (like trim, splice and such) but should be ignored for filtering operations to not be ruined. That's why I thought attaching it as a metadata frame or using mask clips was the best idea at first. Right now I have no good idea for a clean solution...
All I know is that I want to avoid avisynth's mess of alpha vs mask clip.

There's also a new experimental build of vdub available with .vpy support here (http://forums.virtualdub.org/index.php?act=ST&f=15&t=21216&).

[kolak]

For some reason new Vdub "feels" working faster - hehe

[cihub]

Myrsloik, can you change this string in a first post:
"python script.py | x264 --demuxer y4m --output encodedfile.mkv -"
to:
"python script.py | x264 --demuxer y4m --output encodedfile.mkv - "
For noobs like myself that missing space at the end of the command can lead to a great confusion...

P.S. to those who new to this piece of software and tried to do exactly like it was written here (http://www.vapoursynth.com/doc/gettingstarted.html)
if smth like "ret = core.ffms2.Source(source='Super Size Me.avi')" are not working for you (i'm using R13 with ffms2.dll from MeGUI), try this instead: "ret = core.avs.FFVideoSource(r'd:\path\to\video_file.mkv')".

[Myrsloik]

Myrsloik, can you change this string in a first post:
"python script.py | x264 --demuxer y4m --output encodedfile.mkv -"
to:
"python script.py | x264 --demuxer y4m --output encodedfile.mkv - "
For noobs like myself that missing space at the end of the command can lead to a great confusion...

P.S. to those who new to this piece of software and tried to do exactly like it was written here (http://www.vapoursynth.com/doc/gettingstarted.html)
if smth like "ret = core.ffms2.Source(source='Super Size Me.avi')" are not working for you (i'm using R13 with ffms2.dll from MeGUI), try this instead: "ret = core.avs.FFVideoSource(r'd:\path\to\video_file.mkv')". Oh, and don't forget to set resolution explicitly (in my case it used 466x704 instead of 960x720).

Since when does it need a space? I'll have to try this myself when I get home.
I also assume minimal python proficiency. As in knowing how to escape a string. There's a reason the first thing I suggest on the very same page is to check out a python tutorial.

Oh, and the project isn't dead. I just have a cold.

[qyot27]

With the official binary of R13 I'm consistently getting a crash after frame #99. It affects all the files I've tested it with (tested with .avi, .mp4, .mov, .mkv, and .flv files...still results in x264 only getting 99 frames to encode before crashing). The Windows error reporting dialog says the crash is in vapoursynth.dll, so is it safe to say that's where it really is? Namely because the script only uses FFMS2, so if it was actually in the source filter I'd think it would report that ffms2.dll crashed. I tried culling what little information gdb can generate without debug symbols, but that was completely fruitless (tried hooking both python itself and x264...neither one gave me anything to go on).

None of this happens on Linux, so it seems like it might just be a problem with compilation settings or something (I'll have to try satisfying the dependencies first to attempt building under Windows, though). Unless this is part of a fix that occurred between the release of R13 and HEAD.

Is there any kind of internal error reporting type of thing that could be used to help diagnose this?


Some output from the Command Prompt:
>python vpytestscript.vpy | x264 --stdin y4m --preset ultrafast --crf 18 -o testvs.mkv -
y4m [info]: 1920x800p 0:0 @ 24000/1001 fps (cfr)
y4m [info]: color matrix: undef
x264 [info]: using cpu capabilities: MMX2 Cache32
x264 [info]: profile Constrained Baseline, level 4.0
x264 [info]: started at Sat Oct 27 18:04:29 2012

x264 [info]: frame I:1 Avg QP:15.00 size: 92219
x264 [info]: frame P:98 Avg QP: 7.36 size: 891
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 0.0% 0.0% 0.0% P16..4: 1.9% 0.0% 0.0% 0.0% 0.0% skip:98.1%
x264 [info]: coded y,uvDC,uvAC intra: 11.2% 10.7% 10.7% inter: 0.6% 0.4% 0.4%
x264 [info]: i16 v,h,dc,p: 92% 6% 2% 0%
x264 [info]: i8c dc,h,v,p: 89% 7% 3% 0%
x264 [info]: kb/s:347.87

encoded 99 frames, 2.540 fps, 349.09 kb/s, 175.96 KB
x264 [info]: ended at Sat Oct 27 18:05:08 2012
x264 [info]: encoding duration 0:00:39

And one with the normal AviSynth side of the .dll to prove there's nothing wrong there. I killed it at 151 frames so I wouldn't have to wait around too long.
>x264 --preset ultrafast --crf 18 -o testvs-avs.mkv testvs.avs
avs [info]: 1920x800p 0:0 @ 24000/1001 fps (cfr)
avs [info]: color matrix: undef
x264 [info]: using cpu capabilities: MMX2 Cache32
x264 [info]: profile Constrained Baseline, level 4.0
x264 [info]: started at Sat Oct 27 18:05:54 2012
[5.0%] 151/3008 frames, 5.969 fps, 249.76 kb/s, 192.02 KB, eta 0:07:58, est.size

x264 [info]: frame I:1 Avg QP:15.00 size: 92219
x264 [info]: frame P:150 Avg QP: 7.27 size: 692
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 0.7% 0.0% 0.0% P16..4: 1.5% 0.0% 0.0% 0.0% 0.0% skip:97.9%
x264 [info]: coded y,uvDC,uvAC intra: 5.7% 5.4% 5.3% inter: 0.5% 0.3% 0.2%
x264 [info]: i16 v,h,dc,p: 95% 3% 2% 0%
x264 [info]: i8c dc,h,v,p: 95% 4% 2% 0%
x264 [info]: kb/s:248.96

aborted at input frame 151, output frame 151
encoded 151 frames, 5.969 fps, 249.76 kb/s, 192.02 KB
x264 [info]: ended at Sat Oct 27 18:06:20 2012
x264 [info]: encoding duration 0:00:26

>

[Myrsloik]

With the official binary of R13 I'm consistently getting a crash after frame #99. It affects all the files I've tested it with (tested with .avi, .mp4, .mov, .mkv, and .flv files...still results in x264 only getting 99 frames to encode before crashing). The Windows error reporting dialog says the crash is in vapoursynth.dll, so is it safe to say that's where it really is? Namely because the script only uses FFMS2, so if it was actually in the source filter I'd think it would report that ffms2.dll crashed. I tried culling what little information gdb can generate without debug symbols, but that was completely fruitless (tried hooking both python itself and x264...neither one gave me anything to go on).

None of this happens on Linux, so it seems like it might just be a problem with compilation settings or something (I'll have to try satisfying the dependencies first to attempt building under Windows, though). Unless this is part of a fix that occurred between the release of R13 and HEAD.

Is there any kind of internal error reporting type of thing that could be used to help diagnose this?



Vs always outputs an error message for the fatal errors it has checks for, which are quite a few. There's no additional debug output as I like to make warnings visible for everyone to see.
I'm just going to guess that it's either a bad ffms2 compile or you've found a new bug. If you point me at the exact script and ffms2 build I'll test it as soon as my cold is over. Sigh... I really want to finish up r14 soon...

[qyot27]

The FFMS2 build was the one I posted on the 12th (the post itself (http://forum.doom9.org/showthread.php?p=1595488#post1595488)).

The script:
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin(r"C:\Program Files\AviSynth 2.5\plugins\ffms2.dll")
ret = core.ffms2.Source("ironman3-tlr1-m4mb0_h1080p.mov")
ret.output(sys.stdout, y4m=True)

[active1]

hi, i have a transport stream and i want to ivtc it and encode it as vfr.
i can do that easily in avisynth with TIVTC by outputting the timecodes and then encode it in x264, but how can i do that in vs with VIVTC?

[Myrsloik]

hi, i have a transport stream and i want to ivtc it and encode it as vfr.
i can do that easily in avisynth with TIVTC by outputting the timecodes and then encode it in x264, but how can i do that in vs with VIVTC?

You can't. I suggest you use TFM+VDecimate (I think that combination can give you vfr too but I could be mistaken in how TIVTC works). The auto vfr stuff I just thought was one of those niche features few people use.

Peronally I'm more used to people loading anything that's vfr in yatta and then marking stuff there. Where did you find a vfr transport stream anyway?

[active1]

You can't. I suggest you use TFM+VDecimate (I think that combination can give you vfr too but I could be mistaken in how TIVTC works).


i used the 2-pass vfr way in this (http://avisynth.org/mediawiki/VFR) page with TIVTC every time i had a hybrid transform stream because i don't want to blend any frames and i need "input, tfmin, and mkvout" parameters to do this with VDecimate

The auto vfr stuff I just thought was one of those niche features few people use.
but how it works?

Peronally I'm more used to people loading anything that's vfr in yatta and then marking stuff there. Where did you find a vfr transport stream anyway?
i don't think that i need to use yatta because it's easy to do what i need in avisynth only. its a hybrid transform stream

[Reel.Deel]

As some you guys probably already know, dubhater started porting a couple of plugins over to VS. You can now download a windows dll for both Histogram (https://github.com/dubhater/vapoursynth-histogram/downloads) and TemporalSoften (https://github.com/dubhater/vapoursynth-temporalsoften/downloads).

*edit*
Right after my post, dubhater updated Histogram. Classic mode works with up to 16 bits now.

Also, 06_taro posted (http://astrataro.wordpress.com/2012/10/27/x264-hi-bpp-y4m/) a special build of x264. It adds support for high bit depth input from Vapoursynth.

Thanks dubhater and 06_taro.

*edit again*

Thanks JEEB, for submitting (http://forum.doom9.org/showpost.php?p=1596309&postcount=426) the patch.

It's a beautiful thing to see people from all over working together. :)

[Myrsloik]

As some you guys probably already know, dubhater started porting a couple of plugins over to VS. You can now download a windows dll for both Histogram (https://github.com/dubhater/vapoursynth-histogram/downloads) and TemporalSoften (https://github.com/dubhater/vapoursynth-temporalsoften/downloads).

*edit*
Right after my post, dubhater updated Histogram. Classic mode works with up to 16 bits now.

Also, 06_taro posted (http://astrataro.wordpress.com/2012/10/27/x264-hi-bpp-y4m/) a special build of x264. It adds support for high bit depth input from Vapoursynth.

Thanks dubhater and 06_taro.

Just going to add some small notes about stuff. Jeeb also deserves credit as he was the one who submitted the actual patch for the extended y4m support to x264.

Dubhater/nodame/jackoneill also deserves more credit for reconstructing temporalsoften's algorithm from inline asm to c. That code can benefit avxsynth too since it's portable.