VapourSynth Portable FATPACK - 64Bit, Editor, Plugins, Scripts, Apps & endless FUN!

[ChaosKing]

This warning shouldn't cause any problems normally. Maybe your source filter is not 100% frame accurate.
If you can wait a bit (probably till the weekend) then I will release a new package based on R56. Then it should not print this waning anymore Script exceeded memory limit...

[Etroxamin]

Originally Posted by ChaosKing

This warning shouldn't cause any problems normally. Maybe your source filter is not 100% frame accurate.
If you can wait a bit (probably till the weekend) then I will release a new package based on R56. Then it should not print this waning anymore Script exceeded memory limit...

The warning may not really be a problem, i guess, just thought that it eventually could be a reason.

I use the ffms2 source filter that is bundled with the fatpack with this (standard ?) script:

src = core.ffms2.Source("Video.mkv")

however, is there a way to check for accuracy?

Eventually it would also be an idea to use a pure video file, i currently use a complete remux and it's stored on an external hdd, maybe i should copy it to my ssd as well.

an updated pack may could help too and sure i have time to wait, it's just testing anyway, btw. started another test and a similar error was noticeable, in the same scene, but a few frames later and less stuttering, however if i only test the scene itself, it never happens (tried it a couple of times). This is also not very far into encoding process, less than a minute, really strange ...

I will test this again tonight, with pure video and stored on my ssd (system enviroment), might be worht a try. Btw i already did the same test, but with ttempsmooth and the error didn't occured. Seems to be pure coincidence if it happens or not.

[Etroxamin]

I already tried to encode the part a 3rd time and got the same stutter in the same scene, but eventually i found the reason why this is happening and would also explain why it is happening only with my larger test encode.

for the test i do 10000 frames, after the 3rd time this happened i tried to compare different ffms2 versions, starting with the older one which have installed around 2019 on my old pc, the result was different by 1 frame, the newer version however seems to have lost 1 frame compared to the older one, and after trying to find out where this happens, i noticed this seems to happen within the range of my 10000 frames test encode. It's actually not happening in the scene, but when there happens an error like this, it might not be easy to find out where it exactly happens.

I will do another test encode and see if the stuttering happens again.
Btw, i also noticed the newer version is a lot faster than the old one, only takes 40-50 seconds (at least on my NVMe), while the older version needs about 4-5 minutes, on a hdd, this is not very noticeable.
Might be that the better speed enhancement looks like a good step forward developing FFMS2, but may can cause problems for certain videos. I will post again if this will be confirmed by my next test encode.

[ChaosKing]

Originally Posted by Etroxamin

however, is there a way to check for accuracy?

Where should be a bat file _seek_test_(drop files on me blah).bat in the root folder.

[Etroxamin]

Originally Posted by ChaosKing

Where should be a bat file _seek_test_(drop files on me blah).bat in the root folder.

ok, thanks for the hint

did that with the file i had problems with, mode 1, as well as mode 6 and of course with the ffms2 version that caused the problem. But the result is a little bit sobering, seek test method 1, as well as 2 showed no issues.

I also finished my new test encode and as i already expected, there were no problems with the older ffms2.

The video track has been demuxed with eac3to latest version and remuxed with the latest version of MKVToolNix, guess there shouldn't be any problem. The BD is relative old ~2008 release, it has 2 ref frames limit, which isn't very common, it also lacks of certain meta info, like color matrix entrys. Might be source specefic, or maybe not.

Eventually other users have discovered similar problems with other sources as well, perhaps worth to have a look at, currently i dont feel like i want to test this a lot tbh, but maybe others.

[Etroxamin]

hey, just a short question:

is it possible to use --zonefile command?

tried it with --zonefile zones.txt, the encoder isn't complaining about it, but it for sure does have no effect.

text file is in the same folder as the encoder.exe and looks like this:

0 crf 10
5000 crf 15
10000 crf 20

on the x265 info page, its wirtten, --zonfile is only for cli.
but i also tried

--zones 0,5000,q=20

which doesnt have any effect as well.

would be nice to be able to zone with crf of course ...

PS: I only did tests with frame samples, not a whole video, not sure if that can cause problems.

[ChaosKing]

There are no restrictions. It's just a normal x265 binary (you could try to update the binary to a newer version).

[ChaosKing]

New release https://github.com/theChaosCoder/vap...eleases/tag/r6

[Zarxrax]

Is there any chance for an update to this pack? I found it very useful, but the last release is a couple years old by now.

[ChaosKing]

I'm a bit busy these days. Maybe with the next Vapoursynth release => R66.