Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 9th January 2018, 07:03   #21  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
+1

This new hotfix build is a winner...

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

Thanks again and Cheers
manolito
manolito is offline   Reply With Quote
Old 9th January 2018, 10:45   #22  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by burfadel View Post
What's the code separation like between the main branch and the FFMS2000 experimental branch?
Wrong thread?
qyot27 is offline   Reply With Quote
Old 9th January 2018, 15:29   #23  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Well, this is built from the main branch, so it's relevant here since it's a more recent build than FFMS2000.
burfadel is offline   Reply With Quote
Old 9th January 2018, 17:25   #24  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by burfadel View Post
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 branch on the upstream FFMS2 repo, if the C plugin is fully caught up with the master branch
  • the 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 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.
qyot27 is offline   Reply With Quote
Old 1st February 2018, 02:39   #25  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
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
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

Last edited by FranceBB; 1st February 2018 at 02:44.
FranceBB is offline   Reply With Quote
Old 1st February 2018, 02:53   #26  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Does it happen with the latest build of the C++ plugin?
qyot27 is offline   Reply With Quote
Old 1st February 2018, 03:08   #27  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
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. ^_^
FranceBB is offline   Reply With Quote
Old 22nd April 2018, 03:57   #28  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
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:
Code:
    --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:
Code:
    --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.

Last edited by qyot27; 25th April 2018 at 23:30.
qyot27 is offline   Reply With Quote
Old 22nd April 2018, 05:33   #29  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Thanks a lot!
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 22nd April 2018, 05:45   #30  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
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:
Code:
# 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:
Code:
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
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 22nd April 2018, 13:26   #31  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
Thanks so much qyot27 for this new version...

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

Last edited by manolito; 22nd April 2018 at 13:44.
manolito is offline   Reply With Quote
Old 22nd April 2018, 22:19   #32  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by manolito View Post
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?

Quote:
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.

Quote:
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.
qyot27 is offline   Reply With Quote
Old 23rd April 2018, 03:22   #33  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
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
FranceBB is offline   Reply With Quote
Old 23rd April 2018, 11:19   #34  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
Quote:
Originally Posted by FranceBB View Post
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.p...02#post1835702


Cheers
manolito
manolito is offline   Reply With Quote
Old 23rd April 2018, 11:25   #35  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
Quote:
Originally Posted by qyot27 View Post
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
manolito is offline   Reply With Quote
Old 23rd April 2018, 13:58   #36  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
@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.
FranceBB is offline   Reply With Quote
Old 23rd April 2018, 13:59   #37  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Hotfix build for the 64-bit VapourSynth issue Selur reported earlier.

EDIT 2018-04-25: Newer build available; check first post.

Last edited by qyot27; 25th April 2018 at 23:31.
qyot27 is offline   Reply With Quote
Old 23rd April 2018, 14:37   #38  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Quote:
Originally Posted by qyot27 View Post
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]

Quote:
With software specifically leaving NT5 behind, ReactOS is expanding its target to support NT6+ (Vista, Windows 8, Windows 10) software.
Quote:
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...s-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.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 23rd April 2018 at 15:01.
StainlessS is offline   Reply With Quote
Old 23rd April 2018, 15:03   #39  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
Quote:
Originally Posted by StainlessS View Post
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
manolito is offline   Reply With Quote
Old 23rd April 2018, 17:33   #40  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Quote:
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.
Code:
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.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 23rd April 2018 at 17:38.
StainlessS is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.