There is also an external plugin named DSS2 that fixes the frame-inaccurate issue of the original. However in my experience when opening some interlaced HDTV streams encoded in H264 FFmpegSource2 produces double frame rate, so you might need to watch out for that. ffindex files for improved seeking capabilities (it's on by default). for QTGMC(preset'placebo', EdiThreads6) you need tons of filters and a few scripts. By default it also ignores the audio even if it's present in the source container.Ī notable difference is that DirectShowSource() does not have frame-accurate seeking, which becomes critical if you're trying to do some trimming with per-frame precision or, say, mix two recording of the same event so that every frame would match. through ffms2: FFMS2.avsi which calls FFVideoSource, FFAudioSource which are part of ffms2.dll 2.
If you have some special postprocessing options enabled there they will be in effect too.įFmpegSource2(), as you mentioned, is not dependent on system codecs and instead uses FFMPEG. Usually that means same codecs that fire up when you open that videofile in your mediaplayer, including the audiostream.
I did not test it under AVS+ because I have no intention to upgrade to AVS+ in the forseeable future.DirectShowSource() uses codecs currently installed and enabled for the particular filetype in your system.
So I have to conclude that this latest version of the qyot27 C-Plugin does not work under a 64-bit OS using the standard AVS versions (I forgot to mention that I also tried using different builds of AVS versions 2.60 and 2.61). I could not even get AVSMeter to create a report about the AVS script which used ffms2. And I tried to force AVStoDVD to only use 1 CPU core globally. I added the "threads=1" parameter to ffvideosource. First I disabled Hyperthreading, then I completely disabled multicore processing. So I tried a few more things under Win7-64. But it runs the same version of AviSynth (2.61 Alpha VC6) as the other Win7-64 computers. Of course the old desktop computer has a single core CPU (Celeron Coppermine 1.1 Ghz, made in the year 2000), and it has very low system RAM (576 MB). The thing which I do not understand is why it works under WinXP. avs2yuv crashed after the encoding was finished.
Tested with avs2yuv and x265.exe under 64-bit Windows 7. Just confirming, yes the latest C plugin is problematic. I ended up going back to the old ffms2 version from Oct 2016. I also disabled DEP completely, but nothing helped. I tried some workarounds like adding the folder from where ffms2 is loaded by AVStoDVD to the environment path variable.
And the software needs to be closed down. The terrible Windows popup telling the user that the software has stopped working because of some problem. But on the two Win7 machines the encoders (HCenc and FFmpeg) as well as Wavi crash after they have finished their work. Replacing ffms2 with this new build causes no problems under WinXP. This software comes with ffms2_r1140+101-avs+vsp.7z from Oct 2016.
My ancient desktop PC running WinXP and two newer machines with Intel Core i5 CPUs running under Win7-64bit. This seems weird, normally it works the other way around, so I was sceptical and tested it on 3 different machines. While it could probably hang on for a while doing increasingly labor-intensive merge integrations to revert the bcrypt commits, make sure everything still compiles, and that no unwanted behavior arises because of the use of winthread, I'm not particularly enthused to do so, and the alternatives (Wine, ReactOS, using Wine in Windows if you can get it compiled) are more compelling in the long term.Īfter a long testing session I have to report that this new version indeed works nicely, but only under WinXP.
arch=x86FFmpeg has now switched from wincrypt to bcrypt, and this is too far-reaching of a change for any selective revert to handle - the system library it links against changed (and bcrypt.dll is not available on XP it's part of Vista+'s API), and far more importantly, the code that requires the random_seed functions that the *crypt library is called in for is spread throughout the FFmpeg codebase - it's used in encoders, decoders, and muxers, so unlike the winthread/pthread thing last time, this time XP compatibility is probably broken for good. Optimized for Pentium-III and SSE (32-bit)įfmpeg version r90798 master-21da248b5f HEAD-a56580b117Ĭopyright (c) 2000-2018 the FFmpeg developers Code: -prefix=/home/qyot27/ffmpeg_build_for_ffms2/64bit