FFmpegSource - C-plugin

[qyot27]

Since it's easier, I'll keep this first post updated with newer builds whenever one happens.

Issues tracker (for C plugin issues only): https://github.com/qyot27/ffms2_cplugin/issues

FFMS2 C-plugin r1470+181 (https://www.mediafire.com/file/ws6pe3j6oddxwed/ffms2_r1470%252B181.7z/file)

Standard C-plugin builds are in amd64, i686, and aarch64 directories.

The c++_avsgcc directory contains builds of the C++ plugin for use with
GCC builds of AviSynth+. To use them, create a plugins_gcc or plugins64_gcc
directory and place them there instead of in plugins(+) or plugins(+)64.
The plugins*_gcc directory probably also needs to have a registry entry
added for it like the standard 32-bit and 64-bit plugin directories have.


ffmpeg version r118355+62 master-ec4d3dc5b9 HEAD-810165e432
contains: avs_pixfmts datetime merged new_pkgconfig silent_invoke versioninfo
Copyright (c) 2000-2025 the FFmpeg developers
built on Jan 30 2025 20:31:57 with gcc 14.2.0 (GCC)
libavutil 59. 55.100 / 59. 55.100
libavcodec 61. 31.101 / 61. 31.101
libavformat 61. 9.106 / 61. 9.106
libavfilter 10. 6.101 / 10. 6.101
libswscale 8. 13.100 / 8. 13.100
libswresample 5. 4.100 / 5. 4.100
libpostproc 58. 4.100 / 58. 4.100

configuration (amd64):
--prefix=/home/qyot27/mpv-build-deps/ffmpeg_build_for_ffms2/amd64
--cross-prefix=x86_64-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--enable-libdav1d
--disable-decoder=aac_fixed
--disable-decoder=ac3_fixed
--disable-decoder=mp1
--disable-decoder=mp2
--disable-decoder=mp3
--disable-decoder=mp3adu
--disable-decoder=mp3on4
--cpu=core2
--extra-cflags='-march=core2'
--target-os=mingw32
--arch=x86_64


configuration (i686):
--prefix=/home/qyot27/mpv-build-deps/ffmpeg_build_for_ffms2/i686
--cross-prefix=x86_64-w64-mingw32-
--windres='x86_64-w64-mingw32-windres -F pe-i386'
--enable-gpl
--enable-version3
--disable-w32threads
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--enable-libdav1d
--disable-decoder=aac_fixed
--disable-decoder=ac3_fixed
--disable-decoder=mp1
--disable-decoder=mp2
--disable-decoder=mp3
--disable-decoder=mp3adu
--disable-decoder=mp3on4
--cpu=pentium3
--extra-cflags='-m32 -mfpmath=sse -march=pentium3 -msse -mtune=pentium3'
--extra-ldflags='-m32 -L/usr/i686-w64-mingw32/lib'
--target-os=mingw32
--arch=x86


configuration (aarch64):
--prefix=$HOME/mpv-build-deps/ffmpeg_build_for_ffms2/aarch64
--cross-prefix=aarch64-w64-mingw32-
--windres="aarch64-w64-mingw32-windres -I/usr/llvm-mingw/generic-w64-mingw32/include"
--enable-gpl
--enable-version3
--disable-w32threads
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--enable-libdav1d
--disable-decoder=aac_fixed
--disable-decoder=ac3_fixed
--disable-decoder=mp1
--disable-decoder=mp2
--disable-decoder=mp3
--disable-decoder=mp3adu
--disable-decoder=mp3on4
--extra-cflags="-I/usr/aarch64-w64-mingw32/include"
--extra-ldflags="-I/usr/aarch64-w64-mingw32/lib"
--target-os=mingw32
--arch=aarch64

FFMS2 C-plugin r1315+119 (http://www.mediafire.com/file/oi31n1lcrzdvkno/ffms2_r1315%2B119-avs%2Bvsp_lastxp.7z) (Final LastXP build)

Optimized for Pentium-III and SSE (32-bit)
Optimized for Core2 (64-bit)

ffmpeg version r90798 master-21da248b5f HEAD-a56580b117
contains: lastxp_wincrypt
Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 7.2.0 (GCC)
libavutil 56. 13.100 / 56. 13.100
libavcodec 58. 17.100 / 58. 17.100
libavformat 58. 11.101 / 58. 11.101
libavfilter 7. 15.100 / 7. 15.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 0.102 / 5. 0.102
libswresample 3. 0.101 / 3. 0.101
libpostproc 55. 0.100 / 55. 0.100

32-bit configuration:
--prefix=/home/qyot27/ffmpeg_build_for_ffms2/32bit
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3'
--target-os=mingw32
--arch=x86

64-bit configuration:
--prefix=/home/qyot27/ffmpeg_build_for_ffms2/64bit
--cross-prefix=x86_64-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--extra-cflags='-march=core2'
--target-os=mingw32
--arch=x86

FFmpeg 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 [de]muxers, so unlike the winthread/pthread thing last time, this time XP compatibility is probably broken for good. 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.

[Reino]

There was a vote regarding this on the FFmpeg-devel mailing list a couple weeks ago (thread starts here (http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222354.html)), so as of commit 9b121dfc32810250938021952aab4172a988cb56, support for Windows XP was dropped in FFmpeg-git, which now requires the use of the newer lock and thread APIs introduced in Vista.
I've seen the vote and as far as I know this only concerns w32threads.
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222869.html (https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222869.html):
...
Windows XP is hereby not a supported build target anymore. It was
decided in a project vote that this is OK. (Technically, it could still
be built for Windows XP using an external pthread lib as of this
commit.)

I've just released another WinXP compatible FFmpeg build (https://ffmpeg.zeranoe.com/forum/viewtopic.php?p=12998#p12998) using pthreads. I haven't extensively tested it myself, but so far it's working just fine.

[lvqcl]

I've seen the vote and as far as I know this only concerns w32threads.

No, the vote (http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222354.html) was to drop WinXP support:
"We should drop XP support, and allow unconditional use of Windows Vista APIs"

I've just released another WinXP compatible FFmpeg build using pthreads. I haven't extensively tested it myself, but so far it's working just fine.

Looks like adding --disable-w32threads option is currently enough to restore ffmpeg compatibility with WinXP. But it can break with any new commit.

[manolito]

Thanks so much qyot27 for this new version... :thanks:

As opposed to the previous version this one works under plain vanilla AviSynth v2.6 again. I tested it under WinXP with a non-SSE2 capable CPU, no problems whatsoever.


Thanks again and Cheers
manolito

[qyot27]

Looks like adding --disable-w32threads option is currently enough to restore ffmpeg compatibility with WinXP. But it can break with any new commit.
I sort of forgot that w32threads were a separate method. And I actually do use --disable-w32threads (IIRC, because FFMS2's C++11 threading requires MinGW-w64's win32-pthreads, and I can't remember if w32threads plays nice with that), so I guess it might actually hang on a while longer.

The uncertainty about it breaking somewhere deeper at any time, though...

As opposed to the previous version this one works under plain vanilla AviSynth v2.6 again.
It's been quite some time since I did the update to support AviSynth+'s huge number of new colorspaces in the C plugin parts, so I don't remember whether I actually fixed that differently than the previous build or not. Good to hear that it's working, though.

[StainlessS]

Thank you Q Branch, your continued support has always been appreciated (now where did I leave Moneypenny?).

[FranceBB]

@qyot27... thank you very much indeed for supporting XP :D

[TheFluff]

y'all XP diehards might want to take note of this (https://meltdownattack.com/) new shiny CPU exploit that you will most likely never get a patch for
if you do dangerous things such as "using a web browser with javascript enabled" you are vulnerable

[manolito]

y'all XP diehards might want to take note of this (https://meltdownattack.com/) new shiny CPU exploit that you will most likely never get a patch for
if you do dangerous things such as "using a web browser with javascript enabled" you are vulnerable

Yes, and according to this:
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
I will also not get a slowdown of my computer for up to 30% which these (future) patches will introduce... :devil:

Cheers
manolito

[lvqcl]

ffmpeg-related tasks are usually computationally intensive, so performance penalty for them should be close to 0.

P.S. anyway, even 30% performance hit is better than a new ransomware like WannaCry or (Not)Petya.

[Andouille]

y'all XP diehards might want to take note of this (https://meltdownattack.com/) new shiny CPU exploit that you will most likely never get a patch for
if you do dangerous things such as "using a web browser with javascript enabled" you are vulnerable

What does this have to do with video processing ?



@qyot27... thank you

[manolito]

Good to hear that it's working, though.

After a long testing session I have to report that this new version indeed works nicely, but only under WinXP. Under Win7-64bit it causes problems... :o

This seems weird, normally it works the other way around, so I was sceptical and tested it on 3 different machines. My ancient desktop PC running WinXP and two newer machines with Intel Core i5 CPUs running under Win7-64bit.

I used AVStoDVD for testing. This software comes with ffms2_r1140+101-avs+vsp.7z from Oct 2016. Replacing ffms2 with this new build causes no problems under WinXP. But on the two Win7 machines the encoders (HCenc and FFmpeg) as well as Wavi crash after they have finished their work. The terrible Windows popup telling the user that the software has stopped working because of some problem. And the software needs to be closed down. No further explanation.

I tried some workarounds like adding the folder from where ffms2 is loaded by AVStoDVD to the environment path variable. I also disabled DEP completely, but nothing helped. I ended up going back to the old ffms2 version from Oct 2016.


Any ideas what is happening here?

Cheers
manolito

[Midzuki]

After a long testing session I have to report that this new version indeed works nicely, but only under WinXP. Under Win7-64bit it causes problems... :o

This seems weird, normally it works the other way around, so I was sceptical and tested it on 3 different machines. My ancient desktop PC running WinXP and two newer machines with Intel Core i5 CPUs running under Win7-64bit.

I used AVStoDVD for testing. This software comes with ffms2_r1140+101-avs+vsp.7z from Oct 2016. Replacing ffms2 with this new build causes no problems under WinXP. But on the two Win7 machines the encoders (HCenc and FFmpeg) as well as Wavi crash after they have finished their work. The terrible Windows popup telling the user that the software has stopped working because of some problem. And the software needs to be closed down. No further explanation.

Just confirming, yes the latest C plugin is problematic. Tested with avs2yuv and x265.exe under 64-bit Windows 7. avs2yuv crashed after the encoding was finished.

[StainlessS]

ancient desktop PC running WinXP

So WXP_32 and W7_64, did anyone try WXP_64 ? [EDIT: or indeed W7_32]

[manolito]

Just confirming, yes the latest C plugin is problematic. Tested with avs2yuv and x265.exe under 64-bit Windows 7. avs2yuv crashed after the encoding was finished.

Thanks for confirming my findings...

The thing which I do not understand is why it works under WinXP. 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). But it runs the same version of AviSynth (2.61 Alpha VC6) as the other Win7-64 computers.

So I tried a few more things under Win7-64. First I disabled Hyperthreading, then I completely disabled multicore processing. I added the "threads=1" parameter to ffvideosource. And I tried to force AVStoDVD to only use 1 CPU core globally. Nothing helped.

I could not even get AVSMeter to create a report about the AVS script which used ffms2. AVSMeter crashed immediately.


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 did not test it under AVS+ because I have no intention to upgrade to AVS+ in the forseeable future.


Cheers
manolito

[qyot27]

It's been fixed locally. I'll wait to post a new build until all this recent C-plugin discussion has been split off to a new thread, though.

The 'why does it work on XP?' issue had me stumped (I'd mentioned it in passing with the build before this), but as this MSDN thread notes (https://social.msdn.microsoft.com/Forums/vstudio/en-US/21af5f8d-01a9-41cf-9134-41c12d3eab7e/malloc-crashes-my-program-in-vista-but-works-fine-in-xp?forum=vcgeneral) is more than likely down to XP's heap manager not being as comprehensive about warning users about corruptions that occur. So the bug is still there, but XP doesn't bother telling you about it.

The actual issue itself may have been a longstanding bug from back when kemuri-9 was the one doing C-plugin stuff (since the actual line that fails was virtually unchanged since then) or it was a regression that happened when the allocation method for AviSynth.dll changed recently to get rid of calloc (in which case it'd be my fault for not noticing it was trying to NULL the avs_lib after it had been freed).

[Selur]

It's been fixed locally. I'll wait to post a new build until all this recent C-plugin discussion has been split off to a new thread, though.
Any new on the new build? :)

[qyot27]

Any new on the new build? :)
Yup.

FFMS2 C-plugin r1293+111

It's built against the same FFmpeg as last time, so I won't bother with that infoblock again.

EDIT 2018-04-23: Newer build available here. (https://forum.doom9.org/showthread.php?p=1839968#post1839968)

[burfadel]

What's the code separation like between the main branch and the FFMS2000 experimental branch?

[Midzuki]

Yup.

FFMS2 C-plugin r1293+111 (http://www.mediafire.com/file/h052qy7xd74v2ll/ffms2_r1293%2B111-avs%2Bvsp.7z)

It's built against the same FFmpeg as last time, so I won't bother with that infoblock again.

:goodpost:

:thanks: for the new build, now it works without causing crashes.

[manolito]

+1

This new hotfix build is a winner... :thanks:

Tested under WinXP and Win7-64bit, no problems whatsoever.

Thanks again and Cheers
manolito

[qyot27]

What's the code separation like between the main branch and the FFMS2000 experimental branch?
Wrong thread?

[burfadel]

Well, this is built from the main branch, so it's relevant here since it's a more recent build than FFMS2000.

[qyot27]

Well, this is built from the main branch, so it's relevant here since it's a more recent build than FFMS2000.
It's actually built from one of:
the c_plugin (https://github.com/FFMS/ffms2/commits/c_plugin) branch on the upstream FFMS2 repo, if the C plugin is fully caught up with the master branch
the cplugin_master (https://github.com/qyot27/ffms2/commits/cplugin_master) branch on my personal working repo, when there aren't any C-plugin-specific fixes or patches I have to apply.
the patches (https://github.com/qyot27/ffms2/commits/patches) branch, when something needs to be fixed for cplugin_master to build or for other issues with the C-plugin (read: the contents of src/avisynth_c/) to be resolved.

What this means is that, 999 times out of 1000, the FFMS2 core in the C-plugin builds will be the same as it is as of the HEAD position of upstream's master branch at the time I built it, exempting a couple spots required to get MinGW-w64 to build it at all (and those commits are old and already in the c_plugin branch).

It's not really relevant to a comparison with the upstream release builds or the test builds in the FFMS2000 thread, though, because those are the standard C++ plugin, and that's separate from the C-plugin's code. The FFMS2000 changes were merged back into the master branch in November, and the builds from after that are just normal HEAD builds from upstream/master.

[FranceBB]

I got half green screen, decoding an MPEG-2 .ts file.
It didn't happen in the former version of ffms.
It seems like it's somehow expecting high bitdepth, but MPEG-2 files are 8bit.
This is the result: Image (https://i.imgur.com/5ELRAy3.png)
It's a common MPEG-2 .ts file, except for the fact that it's 4:2:2 and it didn't go on air; there shouldn't be any problem with it anyway.
Avisynth: 2.6.1
OS: Windows XP Professional x86 with extended support

ID : 21 (0x15)
Menu ID : 1 (0x1)
Format : MPEG Video
Format version : Version 2
Format settings, BVOP : No
Format settings, Matrix : Custom
Format settings, GOP : Variable
Codec ID : 2
Duration : 23 min 9 s
Bit rate mode : Constant
Maximum bit rate : 50.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Time code of first frame : 00:00:00:00
Time code source : Group of pictures header
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed

[qyot27]

Does it happen with the latest build of the C++ plugin?

[FranceBB]

Yes, it behaved exactly the same, but I just found out that the file is corrupted.
(MD5 doesn't match).
I'm just gonna transfer it again. Nothing to be worried about, my bad. ^_^

[qyot27]

FFMS2 C-plugin r1315+118 (Final LastXP build)

Optimized for Pentium-III and SSE (32-bit)
Optimized for Core2 (64-bit)

ffmpeg version r90798 master-21da248b5f HEAD-a56580b117
contains: lastxp_wincrypt
Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 7.2.0 (GCC)
libavutil 56. 13.100 / 56. 13.100
libavcodec 58. 17.100 / 58. 17.100
libavformat 58. 11.101 / 58. 11.101
libavfilter 7. 15.100 / 7. 15.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 0.102 / 5. 0.102
libswresample 3. 0.101 / 3. 0.101
libpostproc 55. 0.100 / 55. 0.100

32-bit configuration:
--prefix=/home/qyot27/ffmpeg_build_for_ffms2/32bit
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3'
--target-os=mingw32
--arch=x86

64-bit configuration:
--prefix=/home/qyot27/ffmpeg_build_for_ffms2/64bit
--cross-prefix=x86_64-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--extra-cflags='-march=core2'
--target-os=mingw32
--arch=x86

As noted above, this really is going to be the last XP-compatible build I can provide. FFmpeg 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 [de]muxers, so unlike the winthread/pthread thing last time, this time XP compatibility is probably broken for good.

So yeah, at this point there's no point keeping my cross environment compatible with XP from the MinGW-w64 level.

EDIT 2018-04-25: Newer build available; check first post. (https://forum.doom9.org/showthread.php?p=1829061#post1829061)

[Selur]

Thanks a lot!

[Selur]

From the file name 'ffms2_r1315+117-avs+vsp_lastxp' I assumed these should also work with Vapoursynth.
Trying to use the 64bit version in Vapoursynth with:
# Imports
import vapoursynth as vs
core = vs.get_core()
# Loading Plugins
core.std.LoadPlugin(path="G:/Hybrid/64bit/vsfilters/SourceFilter/FFMS2/ffms2.dll")
# Loading F:\TestClips&Co\files\Test-AC3-5.1.avi using FFMS2
clip = core.ffms2.Source(source="F:/TESTCL~1/files/TEST-A~1.AVI",cachefile="H:/Temp/avi_4a88093b3b83d19d00642a5a96b0af78_41.ffindex",format=vs.YUV420P8,alpha=False)
# making sure input color matrix is set as 470bg
clip = core.resize.Point(clip, matrix_in_s="470bg")
# making sure frame rate is set to 25
clip = core.std.AssumeFPS(clip, fpsnum=25, fpsden=1)
# Making sure input color range is set to TV (limited) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)
# adjusting output color from: YUV420P8 to YUV420P10 for x265Model (i420)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10)
# Output
clip.set_output()
I get:
Failed to evaluate the script:
Python exception: No entry point found in G:/Hybrid/64bit/vsfilters/SourceFilter/FFMS2/ffms2.dll

Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1847, in vapoursynth.vpy_evaluateScript
File "H:\Temp\tempPreviewVapoursynthFile06_41_54_518.vpy", line 5, in <module>
core.std.LoadPlugin(path="G:/Hybrid/64bit/vsfilters/SourceFilter/FFMS2/ffms2.dll")
File "src\cython\vapoursynth.pyx", line 1739, in vapoursynth.Function.__call__
vapoursynth.Error: No entry point found in G:/Hybrid/64bit/vsfilters/SourceFilter/FFMS2/ffms2.dll

(32bit version works fine in Avisynth MT 2.6)

Cu Selur

[manolito]

Thanks so much qyot27 for this new version... :thanks:

Tested it thoroughly under Win XP and Win 7-64, works like a charm.


Maybe a little bit OT since this new version (the absolutely very very last XP version) will be perfect for some time...

What will be the alternative for stubborn XP diehards like myself once this version will fail with certain sources (and DSS2Mod will not work reliably)? This is my reasoning:

Luckily there are still three folks who still provide XP compatible FFmpeg builds (CoRoNe, Sherpya and AbeChin). Since FFmpeg decoders are updated frequently there is a good chance that these XP compatible builds will open newer source formats in the future.

So why can't we use FFmpeg.exe to decode sources and pipe them to stdout and then use some (yet to be written) AviSynth stdin source filter?

I had a look at Sashimi, but it seems awfully complex, and it relies on writing an intermediate raw file. Inserting FFmpeg decoded output into a DirectShow Filter Graph seems to be impossible (after doing some research).

What does work for me is using FFmpeg to create a lossless intermediate file (I used H264 CRF=0 with FLAC audio) and open this file with DSS2Mod and LAVFilters. Am I right to assume that there will be no seeking issues because the lossless video file only has key frames? The problem is just that the intermediate file will be huge, and creating it is time consuming. Some kind of piping it into AviSynth would be very welcome.

Any thoughts?

Cheers
manolito

[qyot27]

Maybe a little bit OT since this new version (the absolutely very very last XP version) will be perfect for some time...

What will be the alternative for stubborn XP diehards like myself once this version will fail with certain sources (and DSS2Mod will not work reliably)?
Wine under a Linux distro, ReactOS, or if you can get Wine cross-compiled*, transplanting it onto XP to run programs that require Vista+ APIs.

*I managed to partially do so once, to fix an issue with a DirectX .dll. Hopefully the situation is better than it was ca. 2010 and won't trip over itself and die during the compilation process. I don't have a lot of hope for that, but who knows?

Luckily there are still three folks who still provide XP compatible FFmpeg builds (CoRoNe, Sherpya and AbeChin). Since FFmpeg decoders are updated frequently there is a good chance that these XP compatible builds will open newer source formats in the future.

So why can't we use FFmpeg.exe to decode sources and pipe them to stdout and then use some (yet to be written) AviSynth stdin source filter?
Because you won't be able to run newer versions of FFmpeg (.exe or other programs linked to FFmpeg's libs) on XP. That was the underlying problem. It's not a configure switch that can simply turn XP support back on like --disable-w32thread could - they'll have to explicitly revert any commits that are bcrypt-related (which may mean doing complex merge integration in all those decoders every time something changes in them just to get the bcrypt commits to revert cleanly), then fix any compilation errors that might arise, and then cross your fingers that it doesn't introduce any unexpected behavior when using wincrypt.

FFmpeg commit a56580b117 (the one used in this build) is the last one that can work on XP without beginning to put in [potentially] a lot of extra leg work to keep it going. Even if it's minimal work to do so right now, it'll get progressively harder to do so.

I had a look at Sashimi, but it seems awfully complex, and it relies on writing an intermediate raw file. Inserting FFmpeg decoded output into a DirectShow Filter Graph seems to be impossible (after doing some research).

What does work for me is using FFmpeg to create a lossless intermediate file (I used H264 CRF=0 with FLAC audio) and open this file with DSS2Mod and LAVFilters. Am I right to assume that there will be no seeking issues because the lossless video file only has key frames? The problem is just that the intermediate file will be huge, and creating it is time consuming. Some kind of piping it into AviSynth would be very welcome.
I can't say. I've never used Sashimi because I've never come across a need to open raw video. Intra-only files shouldn't have any seeking issues, but in many cases that's more up to the demuxer than it is the video compression format.

[FranceBB]

Few issues with Avisynth 2.6.1 on Windows XP x86.

LoadCPlugin("ffms2.dll") in ffms2.avsi doesn't work, Load_Stdcall_Plugin("ffms2.dll") does.

If I try to index an H.264 4:2:0 8bit .mp4 file, it works flawlessly,
however when I try to index an H.264 4:2:0 10bit .mkv file, it says:

Error requesting frame xxxx
Windows error: exception access violation reading 0x00000000.

The latest stable ffms build (not ffms2000) from 2016 works fine.
I can't test the latest ffms2000 'cause I'm running XP.

Nothing special on mediainfo:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 10@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 10 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 min 32 s
Bit rate : 4 685 kb/s
Width : 1 024 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.331
Stream size : 51.4 MiB (91%)
Writing library : x264 core 148 r2744kMod b97ae06
Encoding settings : cabac=1 / ref=10 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=0.70:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=17.0000 / qcomp=0.60 / qpmin=5 / qpmax=40 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
Language : Japanese
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.601 PAL
Transfer characteristics : BT.470 System B, BT.470 System G
Matrix coefficients : BT.601

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 1 min 31 s
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 spf)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 4.90 MiB (9%)
Language : Japanese
Service kind : Complete Main
Default : Yes
Forced : No

[manolito]

Few issues with Avisynth 2.6.1 on Windows XP x86.

LoadCPlugin("ffms2.dll") in ffms2.avsi doesn't work, Load_Stdcall_Plugin("ffms2.dll") does.


Tried to reproduce the issue, but I couldn't. Also on Win XP SP3 and AviSynth 2.61. LoadCPlugin in the ffms2.avsi works fine, I do not even have the AviSynth\plugins folder in my path.

Could it be that you have the old Avisynth_c.dll in your Plugins folder? See this post:
https://forum.doom9.org/showthread.php?p=1835702#post1835702


Cheers
manolito

[manolito]

Because you won't be able to run newer versions of FFmpeg (.exe or other programs linked to FFmpeg's libs) on XP. That was the underlying problem. It's not a configure switch that can simply turn XP support back on like --disable-w32thread could - they'll have to explicitly revert any commits that are bcrypt-related (which may mean doing complex merge integration in all those decoders every time something changes in them just to get the bcrypt commits to revert cleanly), then fix any compilation errors that might arise, and then cross your fingers that it doesn't introduce any unexpected behavior when using wincrypt.

FFmpeg commit a56580b117 (the one used in this build) is the last one that can work on XP without beginning to put in [potentially] a lot of extra leg work to keep it going. Even if it's minimal work to do so right now, it'll get progressively harder to do so.



Thanks for taking the time for explaining...
So my only hope for XP is that those 3 guys will find some tricks to maintain XP compatibility for some time to come...


Cheers
manolito

[FranceBB]

@manolito... yes, it was Avisynth_c.dll. I had it in my autoloading plugin directory. Thank you. ;)

And thanks to qyot27 for this new build.

[qyot27]

Hotfix build for the 64-bit VapourSynth issue Selur reported earlier.

EDIT 2018-04-25: Newer build available; check first post. (https://forum.doom9.org/showthread.php?p=1829061#post1829061)

[StainlessS]

Wine under a Linux distro, ReactOS, or if you can get Wine cross-compiled*, transplanting it onto XP to run programs that require Vista+ APIs.


ReactOS 0.48 is released recently. [EDIT: Ubuntu 18.1 Final due for release on 26th of this month]

With software specifically leaving NT5 behind, ReactOS is expanding its target to support NT6+ (Vista, Windows 8, Windows 10) software.


The NTFS driver coded by Trevor, during GSOC 2016/2017, has been finally added. The NTFS driver has been an ongoing effort started by Hervé and Pierre, and which needed 2 different Google Summer Of Code to reach its current state. Under the mentoring of Pierre, Trevor Thomson has been coding and documenting his titanic NTFS coding efforts. If you're interested in file systems or how NTFS works and the tools needed to understand its behavior, you shouldn't miss the blog posts of Trevor. Thanks to these efforts ReactOS is able to read NTFS partitions in a more robust way, covering NTFS specific cases, and since 0.4.8, ReactOS introduces initial NTFS writing support. The NTFS writing feature is disabled but can be enabled through registry to test its experimental support.


https://www.reactos.org/project-news/reactos-048-released

I've never got ReactOS to run as yet (dont think), and put that down to all of my systems being multi-boot (non-M$/non-Linux boot controller), am hopeful that the new version will at last work (have downloaded, not yet tried).

Thanx for the updates qyot27. :thanks:

[manolito]

I've never got ReactOS to run as yet (dont think), and put that down to all of my systems being multi-boot (non-M$ boot controller), am hopeful that the new version will at last work (have downloaded, not yet tried).

ReactOS has been on my watch list for a long time (but their development only progresses at a snail's pace). I really hope that it will be usable by the time M$ decides to kill Win7.

Please let us know once you tried it how it works for you. A lot of stuff I rely on is not available under Linux, and using Wine or have Windows installed in a VM looks clumsy to me. I just hope that ReactOS will succeed...


Cheers
manolito

[StainlessS]

I just hope that ReactOS will succeed..

Sad, but not just yet Mani,
Tried on Intel Board/bios core-duo quad m/c with all drives removed, all external cards/usb devices removed, running live USB ReactOS v0.48, and
sadly, stopped on about the 4th message
"Loading NTOSKRNL.EXE..."
"Loading HAL.DLL..."
"Loading KDCOM.DLL..."
"Loading boot drivers..."

Black Screen then nothing (monitor detects active display), CTRL/ALT/DEL reboot is disabled.

Tried on a second m/c IBM board/bios, did not remove any drives (3 internal attached), no internal cards attached, a couple of external USB cameras
attached; did not remove, same results as previous Intel m/c test, although after about 5 minutes, the fan became quite active but may have been
down to it being relatively warm day (does not usually have fan going continuous, which it did for at least 20 mins before shutting down, so CPU does seem to be
doing something).

I think on a previous attempt (perhaps with v0.47), it put up the usual long list of debug logging driver/system files, and used to hang at "Mup.Sys".

This is beginning of debug log (Safe Mode from boot F8 key) for XP SP3.

Loaded driver \WINDOWS\system32\ntkrnlpa.exe
Loaded driver \WINDOWS\system32\hal.dll
Loaded driver \WINDOWS\system32\KDCOM.DLL
Loaded driver \WINDOWS\system32\BOOTVID.dll
Loaded driver sptd.sys
Loaded driver \WINDOWS\System32\Drivers\WMILIB.SYS
Loaded driver \WINDOWS\System32\Drivers\SCSIPORT.SYS
Loaded driver ACPI.sys
Loaded driver pci.sys
Loaded driver isapnp.sys
Loaded driver pciide.sys
Loaded driver \WINDOWS\system32\DRIVERS\PCIIDEX.SYS
Loaded driver MountMgr.sys
Loaded driver ftdisk.sys
Loaded driver dmload.sys
Loaded driver dmio.sys
Loaded driver PartMgr.sys
Loaded driver VolSnap.sys
Loaded driver atapi.sys
Loaded driver disk.sys
Loaded driver \WINDOWS\system32\DRIVERS\CLASSPNP.SYS
Loaded driver fltMgr.sys
Loaded driver sr.sys
Loaded driver PxHelp20.sys
Loaded driver KSecDD.sys
Loaded driver WudfPf.sys
Loaded driver Ntfs.sys
Loaded driver inspect.sys
Loaded driver \WINDOWS\System32\DRIVERS\NDIS.SYS
Loaded driver \WINDOWS\System32\DRIVERS\TDI.SYS
Loaded driver pwdrvio.sys
Loaded driver Mup.sys

Above XP debug log for no particular reason, just showing how far it used to get (they seem to have changed/reduced debug progress messages).

It also used to fail (some prev versions) on a Dell m/c which I've recently consigned to the scrap heap (random failures, probably Motherboard,
PSU, or CPU faulty, mem seems ok).
Also dumped another Motherboard, down to only 3 now, and not set up to easily test on the 3rd board, so only above two results available.

Its strange that they have not been able to get the live image to boot on any of my machines, I presume that the image does not require
recent hardware.

ReactOS, apparently is able to run in only 96MB of RAM, M$ stuff is way too bloated.

[qyot27]

While it's a bit off-topic, when ReactOS refers to NT6+ compatibility, they're largely talking about stuff like the NT kernel itself, the system libs are already capable of running Vista+ programs if Wine can (ReactOS contributes to Wine development since they use parts of Wine themselves), but that wasn't their immediate priority because they were targeting Server 2003. I have managed to run AviSynth+ and either/both ffplay or mpv in one of last year's releases of ReactOS under a VM, and it worked fine for the kind of resource-strapped system I was running the VM on; but it was only a brief test to see if it actually could work, it wasn't anything intensive. I've not tried 0.4.8, but I've not been able to run it on the actual hardware on either of my own computers - but then again, one's using UEFI and the other uses SATA expansion card to host its boot drive, so it's probably more just that my setups are still a bit too exotic for what ROS currently has support for.

It's happily moved to both an intended 3-month release schedule and moved the source repos to Github, which to read their news posting(s) about it, seem to have attracted more outside contributions. Regardless, I remember playing with the then-current release 10 years ago (it may have been the early 0.3.x releases when I started taking notice of it?) and it's leaps and bounds ahead of where it was then.

[StainlessS]

Well this too is Off Topic, perhaps a moderator can move from post #38 to here [EDIT: Post #45] into a new thread, maybe into
'General', or 'Linux, OS X & Co' forum (my perference would be General, Maybe thread named 'ReactOS').

In my previous post, I made two screwups.

1), I had used the wrong ISO image on USB stick, as I had already written the Flash drive with intent of using
it to install test version of ReactOs on a machine that has now been scrapped due to faulty hardware.
I used the ReactOS Install ISO in testing, instead of the ReactOS Live CD ISO [originally created nearly a couple of weeks ago].

2), It seems that ReactOS does not as yet support USB devices (it seems to install some kind of USB hub drivers, but
dont support any USB devices themselves). Result was that in writing an ISO to a flash drive, it actually boots ok, but
then at some point cannot continue becase 'it dont support USB devices' [sometimes get a STOP 0x0000007B Blue screen].

I tried again after burning a CD with the Live CD image (live CD zip for v0.48 is about 75MB, expands to about 225MB ISO).
After some screwing around, I found that it boots OK with 1 Floppy, 1 IDE Pata and 2 SATA hard drives + 1 SATA SSD, +
1 PCI USB 5 port hub and 1 external USB drive attached to that add-on hub. It also works OK with Ethernet connected
and Switch/hub powered up. My ATI graphics card was removed for some reason several weeks ago so has not been tried in-situ.

Two devices were found to cause booting to fail, namely a Linksys WUSB54AG Wifi dongle, and a
TP-LINK_WN823N USB 300Mb Mini Wifi dongle (thumbnail size).

The MotherBoard used was an old Intel board DG965WH, with builtin ide, sata, usb, graphics, audio, and ethernet.
(Builtin serial, parallel, and FireWire are always disabled [EDIT: by me], as is a TPM [Trusted Platform Module, I think]).
CPU was Intel Core Duo Quad Core 2.4GHz Q6600, with 4GB RAM.
After booting into ReactOS, no USB devices worked (neither flash not external USB drives), nor the builtin Ethernet (no attempt
to install a driver for it). The Builtin Intel graphics worked just fine defaulting to 800x600 (dont recall color depth but
have impression that it was 24 or 32 bit). Tried change resolution to 1280x1024 and worked ok, did not try higher.
The CPU showed in Task Manager as Uni-Processor instead of Multi-Processor.
My NTFS partitions all showed up just fine, but I did not figure out how to enable NTFS write, read only.

It was kinda frustrating not having any device I could write to, as I had about 8 partitions all NTFS (read only) and
USB flash drives did not function at all. On starting up the Live CD, it asks for locale/keyboard, and then asks if you
want to run live or install, if you select install it produces a message "UserInit Failed to start Installer", maybe
the installer is only provided on the Install CD, or if a duel purpose Live/Install CD is created.

I removed all hard drives (in case of screwup) and temp installed an old 10GB drive and formated it as FAT32,
ran the live CD again and saved an image to the FAT32 partition, image is below.

I did not try the Live CD on my 2nd machine, it has no CD/DVD drive (replaced in drive bay with 3rd hard drive), and
not really convienient to use as it more often than not has no monitor attached, and sometimes neither keyboard nor mouse.
(access usually via 'My Network Places', or VNC [Tight-VNC/Tiger-VNC on Linux]).

So, ReactOS does actually work, but of limited use at present. think I saw somewhere that v0.50 would have NTFS working
(also will support linux partitions at some point, dont know if already so).
I'm a lot happier now I know that the project is indeed progressing, if point version increments every 4 months, then
would suggest that in about 8 months should have near full NTFS support.

https://s20.postimg.cc/ebtindin1/RTOS.jpg (https://postimages.org/)
EDIT: Above saved when desktop @ 800x600.

EDIT: By qyot27
3-month release schedule
so a 2 point increment in about 6 months, not 8.

@Manolito, Saw in the ReactOS FAQ, that minimum CPU is Pentium, so P3 is probably well plenty for you :)

EDIT: Maybe I have another try when I get another machine put together.

[FranceBB]

I personally use Linux and Windows XP in a virtual machine, for everything else I have Windows Server 2016 and I connect remotely to it via RDP to encode.
This is way off topic, but still... if you are willing to try an XP based OS, I think you should try Windows Shorthorn http://shorthornproject.com/
It's XP/Server 2003 based, but has many improvements, including a modified kernel that includes more functions and allows to run programs and drivers that wouldn't normally run on XP.
This is the closest thing you can get to an updated Windows XP.

Cheers.

[StainlessS]

Arh Damn!, another one to try, me gots bout 11 OS's that I've currently got in queue (incl 9 Linux, 1 Android, and ReactOS),
but does look very good, never heard of it before, thanx muchley FranceBB.

Tried search for a WikiPedia page on it, nuttin but cattle stuff found.

Vista eh, hope the state-of-the-art artificial stupidity managed to evade duplication.

Guess it might be lovely so long as you can turn of all of that horrid glitzy stuff, and get it back to real W95 Classic. :)

Again thanx F_BB

[qyot27]

If you scroll down, you'll notice that Shorthorn's 'newer program support' is basically that option I mentioned above about running Wine in Windows.

[FranceBB]

This is awkward...
After I removed Avisynth_C.dll I managed to load the C plugin with LoadCPlugin, but it still wasn't able to index my test file; no problem with a normal 8bit 4:2:0 H.264 .mp4.
Since it was the very first time that I was using the C plugin, I tried to remove all the other filters: same result.
I also tried to use "FFVideoSource" instead of FFMpegSource2: same behaviour.
Then, I tried older ffms2 C plugin releases, but they all prompted me to the same error, 'till I tried this one from 2016 https://forum.doom9.org/showthread.php?p=1783312#post1783312
FFMS2 C-plugin 1140+101 is working flawlessly on my machine.

Test:
FFMS2 C-plugin 1140+101 works
FFMS2 C-plugin r1293+111 exception access violation reading 0x00000000.
FFMS2 C-plugin r1293+111 exception access violation reading 0x00000000.
FFMS2 C-plugin r1315+118 exception access violation reading 0x00000000.

Not sure why.
I'm running Windows XP Professional x86 PAE.
Frameserver: Avisynth 2.6.1
CPU: Intel i7 6700HQ
RAM: 16 GB DDR4 (8x2)
GPU: NVIDIA GTX 950M
SSHD: Seagate 1TB

I don't know how to provide additional informations. Also please note that my CPU supports AVX and AVX2, but XP only uses SSE4.2, but that shouldn't be a problem. I also have PAE enabled and unlocked and I can use memory above 4GB thanks to the HAL (Hardware Abstraction Layer) that translates it from 32bit programs to 36bit hardware. Anyway, none of this should compromise the usage of ffms2 C plugin. It's weird.

[Groucho2004]

Then, I tried older ffms2 C plugin releases, but they all prompted me to the same error, 'till I tried this one from 2016 https://forum.doom9.org/showthread.php?p=1783312#post1783312
FFMS2 C-plugin 1140+101 is working flawlessly on my machine.

Test:
FFMS2 C-plugin 1140+101 works
FFMS2 C-plugin r1293+111 exception access violation reading 0x00000000.
FFMS2 C-plugin r1293+111 exception access violation reading 0x00000000.
FFMS2 C-plugin r1315+118 exception access violation reading 0x00000000.

I can reproduce that with a HEVC 420P10 clip. Specifying the correct color space makes no difference.
However, 10 bit sources seem to work fine with Avisynth+ with all plugin versions.

[qyot27]

I'm going to assume it's because I'd moved the C plugin to AviSynth+'s headers a while back. Also the note at the bottom of this post: https://forum.doom9.org/showpost.php?p=1799448&postcount=2351

[manolito]

After seeing FranceBB's post I started playing around with different ffms2 C-Plugin versions...

What I found is that the issues are not restricted to 10-bit or hi color sources. The test file from this post also caused indexing issues:
https://forum.doom9.org/showthread.php?p=1840071#post1840071

This file is broken, it does not demux or remux properly. But it can be reencoded with FFmpeg and AVS using DSS2Mod with LAVFilters. The video format is HD AVC, 8 bit, 4:2:0, interlaced TFF.

The latest ffms2 C-Plugin versions can not decode it correctly. The length is 13 sec, but with the latest ffms2 versions the conversion stops after 7 sec. Going back to the old version FFMS2 C-plugin 1140+101 which also works for FranceBB the conversion finishes without problems. Here is the script I use (generated by AVStoDVD):

LoadCPlugin("E:\Programme\AVStoDVD\Lib\ffms2.dll")
LoadPlugin("E:\Programme\AVStoDVD\Lib\LeakKernelDeint.dll")

Audio = FFAudioSource("F:\Download\kuchikirukia - won't mux.ts", track=-1)
Video = FFVideoSource("F:\Download\kuchikirukia - won't mux.ts", track=-1, fpsnum=2997, fpsden=100, seekmode=0)

Video = Video.ConvertToYV12(interlaced=true)
Video = Video.LeakKernelBob(1,7,false,false)
Video = Video.Spline36Resize(720,480)
Video = Video.SeparateFields().SelectEvery(4,1,2).Weave()

AudioDub(Video, Audio)

It looks like it is generally a bad idea to use an ffms2 version which employs the AVS+ headers under a plain vanilla AVS 2.60. For my part I will revert to the FFMS2 C-plugin 1140+101 from 2016 which always worked reliably for me.


Cheers
manolito

[qyot27]

Another new build (https://forum.doom9.org/showthread.php?p=1829061#post1829061); this time, using the C plugin under AviSynth 2.6 shouldn't error out with access violations if given high bit depth video. It will spit back the 'FFVideoSource: No suitable output format found' error since it won't do automatic downsampling anymore. The assumption, given high bit depth video, is outputting the same pix_fmt unless you use ConvertTo later in the script. The colorspace= parameter should work again, though, so you can force 8-bit output when you know you need it.

For simplicity's sake, I'll just update the first post from now on instead of burying the release posts mid-thread.


Regarding the broken TS file mentioned above, using the new build (r1315+119) and a simple script:
v=FFVideoSource("kuchikirukia - won't mux.ts")
a=FFAudioSource("kuchikirukia - won't mux.ts")
AudioDub(v,a)
All 13 seconds converted and encoded file played back fine. When using the expanded script manolito posted, it crashed at 6½ seconds (roughly). I whittled down the problem to the fpsnum=/fpsden= settings. Which is strange, since I don't think I've ever touched anything related to those in the C-plugin; anyone that can test with the main C++ FFMS2, does it happen when fpsnum/fpsden on this clip?