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. |
24th April 2018, 02:25 | #41 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
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. |
24th April 2018, 04:15 | #42 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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. EDIT: Above saved when desktop @ 800x600. EDIT: By qyot27 Quote:
@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.
__________________
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; 24th April 2018 at 18:03. |
|
24th April 2018, 04:56 | #43 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
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. |
24th April 2018, 05:21 | #44 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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
__________________
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; 24th April 2018 at 06:30. |
24th April 2018, 17:16 | #46 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
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.p...12#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. Last edited by FranceBB; 24th April 2018 at 17:22. |
24th April 2018, 17:38 | #47 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
However, 10 bit sources seem to work fine with Avisynth+ with all plugin versions.
__________________
Groucho's Avisynth Stuff Last edited by Groucho2004; 24th April 2018 at 17:41. |
|
25th April 2018, 00:25 | #48 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
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...postcount=2351
|
25th April 2018, 11:51 | #49 | Link | |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
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.p...71#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): Quote:
Cheers manolito Last edited by manolito; 25th April 2018 at 11:59. |
|
26th April 2018, 00:44 | #50 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Another new build; 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: Code:
v=FFVideoSource("kuchikirukia - won't mux.ts") a=FFAudioSource("kuchikirukia - won't mux.ts") AudioDub(v,a) |
26th April 2018, 07:17 | #51 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
I see... Thanks for this new build, but I would still change a thing.
(I know, I know, you are gonna hate me right now xD). I tried to open a 10bit file and it says "no suitable output format found", as expected. I tried to output an 8bit dithered video from a 10bit source and it worked, as expected. I then tried to output a 16bit video via the 10bit hack, but it didn't work. My question is: how can I output a 16bit video (stacked - Dither Tools - or interleaved - HDRCore) in plain Avisynth via ffms2 C plugin? I think you should enable the 10bit hack for Avisynth users, otherwise we won't be able to preserve the bitdepth of the source. FFVideoSource("jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv") no suitable output format found --- FFVideoSource("jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv", enable10bithack=true) FFVideoSource does not have a named argument "enable10bithack" --- FFVideoSource("jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv", colorspace="YV12") Works: output is dithered down 8bit 4:2:0 video Thank you in advance. |
26th April 2018, 12:12 | #52 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
No. The 10bit hack was never in the C plugin (or mainline FFMS2, for that matter), and there's no reason for it to be put in now that we have an option that can preserve and give proper high bit depth input/output. If you want to use high bit depth, use AviSynth+.
|
26th April 2018, 13:59 | #53 | Link | |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Quote:
I tried using the very old C++ version 2.17 of ffms2 (the last version which runs on my machine), and it handled it nicely. I think I saw a short hickup pause at 6 1/2 seconds, but the conversion went on smoothly. I was too lazy to pull out my Win7 laptop from the closet to test it with version 2.23.1 (last version on GitHub), but I think it does not really matter. The problem clearly comes from the broken source file. After transcoding this source to exactly the same format using either FFmpeg or AviSynth -> H.264 and feeding the transcoded file to AVStoDVD using the latest ffms2 C-plugin (making sure that fpsnum and fpsden were in the params list), the conversion proceeded all the way to the end. My conclusion is that the older ffms2 versions are just more tolerant when they encounter broken source files. No big deal... Cheers manolito |
|
26th April 2018, 20:06 | #54 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
If you're using 2.17 to test, make sure to force the lavf demuxer; that's the only way to make sure it's directly comparable to current builds. The Haali demuxers (which may have been more tolerant of bad streams, I'm not sure) were removed a couple or three years ago, so newer FFMS2 builds only use libavformat.
|
27th April 2018, 15:33 | #55 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
OK, I did my homework, here are the results:
Not so sure about using Haali demuxers when testing version 2.17, simply because Haali is not installed on my computer. I do have avss_26.dll from DSS2Mod in my plugins folder, but would this be enough to enable Haali demuxers in ffms2? Anyways, I fired up my Win7-64 laptop and repeated the conversion using the C++ version 2.23.1 from GitHub and the latest FFMS2000 test8 build from Myrsloik. Interesting results: Version 2.23.1 handled the broken source file just fine, FFMS2000 crashed at the same point where the current C-plugins crash. Working: C++ versions 2.17 and 2.23.1 C-plugin version 1140+101 Not working: C++ version FFMS2000 test8 All C-plugin versions after 1140 But again, this is caused by the broken source file. After transcoding this source file all ffms2 versions handled it correctly. Cheers manolito Last edited by manolito; 27th April 2018 at 15:37. |
27th April 2018, 20:42 | #56 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Ok, well if it occurs in mainline FFMS2, then the root cause is in the FFMS2 core, not in the plugins. Since it only occurs with fpsnum/fpsden, it probably involves one of the good handful of commits about timestamp or frame rate handling that came in over the course of 2017, although without bisecting it, I won't know for sure which one is the culprit. Likely it's specifically using fpsnum/fpsden on broken files like that, because the timestamps are already messed up.
My memory is really fuzzy involving the Haali stuff (but it doesn't matter since we know it happened in both the C++ and C plugins around the same time). The MPEG and OGG demuxers relied on the Haali DirectShow splitter, though, so I'm not sure if that was the *.dll or the *.ax file. |
5th July 2018, 17:44 | #57 | Link |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
@qyot27: Encountered a strange problem with this file.
It works fine with the 64bit Vapoursynth filter, but with Avisynth 2.6 MT I get dropped and repeated frames. Using just FFVideoSource: Code:
FFVideoSource("C:\Users\Selur\Desktop\2SOURC~1.AVI",cachefile="H:\Temp\avi_3a7584798a428c1a525d134a8f55420b_18467_1_0.ffindex",fpsnum=30000,fpsden=1001) # current resolution: 640x480 return last Frame with time 29 is shown as frame 29 and 30. Frame with time 31 is missing. Frame with time 32 is shown as frame 32&34. Frame with time 33 is missing. Frame with time 54 is shown as frame 54&55. Frame with time 55 is missing. Frame with time 56 is shown as frame 56&57. Frame with time 59 is shown as frame 59&60. Using just FFms2000: same result as when using FFVideoSource. Using just LWLibavVideoSource: All frames are properly decoded. Installing a Xvid vfw decoder and using AviSource: All frames are properly decoded. Using Vapoursynth + FFMS2K All frames are properly decoded. Using Vapoursynth + FFVideoSource All frames are properly decoded. Using Vapoursynth + LibAV All frames are properly decoded. Cu Selur |
5th July 2018, 19:41 | #58 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Looks like a problem with Avisynth 2.6 MT to me. Under plain vanilla AviSynth 2.60 (and 2.61 Alpha) I cannot reproduce these issues, I cannot see any dropped or repeated frames.
Have you tried to use MPEG4 Modifier by Moitah to remove the Packed Bitstream from the source file? Cheers manolito |
6th July 2018, 06:32 | #59 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
That it does the same thing when using FFMS2000 means that the issue is not C-plugin-specific. That it doesn't occur with VapourSynth means it's probably not in the core.
Here's the thing, though: it only happens when forcing fpsnum= and fpsden=. It doesn't occur when leaving it as just the filename, even if you then proceed to use ChangeFPS() to do the same sort of framerate conversion. So that would seem to suggest that it's an issue with the AviSynth plugin interface code, but since FFMS2000 and the C-plugin use two entirely different plugin codebases, the fpsnum/den bug when handling AVI would have to either have been implemented separately in the C-plugin, or it arises from some quirk of AVI, AviSynth, libavformat and/or libavcodec, or some combination of the three. It does seem to be AVI-specific; I remuxed into MKV two different ways, as native MPEG4 and as VFW-compat, and both of them decoded the frames correctly even with fpsnum/den present. |
6th July 2018, 14:56 | #60 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
This is only partly true...
The reason that I could not reproduce the issue was that AVStoDVD created a script which had "fpsnum=2997, fpsden=100" in it. With these values the output is flawless. Only after I changed the script to use "fpsnum=30000, fpsden=1001" I was able to reproduce the issues. This means that we are dealing with a very stupid bug in one of the libraries which the latest C-plugin uses. Is there any chance to find and fix this bug? Cheers manolito |
Thread Tools | Search this Thread |
Display Modes | |
|
|