StaxRip

[Atlantis]

Thank you for adding support to check if the final image is compatible with output mod.

When we use AddBorders or anything else wouldn't it better if staxrip showed the output resolution also?
Maybe under resize or on the right panel showing output info.

[Atlantis]

Comparing 2.1.3.0 to 2.1.6.0.

I used to launch staxrip in file managers with this command
staxrip.exe video.mkv

This worked correctly before. Now it says I have found a new version of and it goes through 7zip - Autocrop - Avisynth and on and on.

The only way I can open a file correctly without these warnings is to launch staxrip first and drag the file into source which I don't want to do.

[AMED]

I got that same issue when i started a second job so i had 2 jobs processing at once. When the second job began I needed to set the version of every "APP" so it would start processing the job. The first job was processing fine while i need to verify the app versions for the 2nd job to start.

Workaround was go to Tools > Settings > Danger Zone | tick "Allow using tools with unknown version"

I also found that the Apple Application Support doesn't autodetect CoreAudioToolbox.dll if the files are located in ..\StaxRip\Apps\Audio\qaac\QTfiles64\. Running Qaac --check from ..\StaxRip\Apps\Audio\qaac\ does pick up the files in ..\StaxRip\Apps\Audio\qaac\QTfiles64\.

Workaround for that is to go in to Tools > Settings > Danger Zone | tick "Allow using custom paths in startup folder" and then point Apple Application Support to ..\StaxRip\Apps\Audio\qaac\QTfiles64\.

[stax76]

@MrBrownCow

You can also compare performance with VapourSynth:

Filters > Filter Setup > VapourSynth

@Atlantis

The latest version of RgTools and neo_FFT3D are available in the next build.

It uses a x265 mod that supports direct avs and vpy input, there are plans adding UTF-8 and long path support as well this year.

https://github.com/staxrip/staxrip/wiki/x265

I got that same issue when i started a second job so i had 2 jobs processing at once. When the second job began I needed to set the version of every "APP" so it would start processing the job. The first job was processing fine while i need to verify the app versions for the 2nd job to start.

Workaround was go to Tools > Settings > Danger Zone | tick "Allow using tools with unknown version"

Unfortunate bug for a stable release... It's the same reason and fixed in the next build.

I also found that the Apple Application Support doesn't autodetect CoreAudioToolbox.dll if the files are located in ..\StaxRip\Apps\Audio\qaac\QTfiles64\. Running Qaac --check from ..\StaxRip\Apps\Audio\qaac\ does pick up the files in ..\StaxRip\Apps\Audio\qaac\QTfiles64\.

It's not the best possible location, that's why it's not permitted by default:

Custom paths within the startup folder are not permitted
because it would prevent a simple update process.
Please put the file somewhere else outside the startup folder.

When we use AddBorders or anything else wouldn't it better if staxrip showed the output resolution also?
Maybe under resize or on the right panel showing output info.

I changed it to show that, but only if no resize filter is active, you can always find it in the info dialog. Doing more is difficult and problematic.

New beta is available:

2.1.6.1 Beta (2021-01-07)

- Fix CLI usage causing version verification to fail. (stax76)
- RgTools 1.1
- Neo FFT3D r10

[44vince44]

@Stax76 ; @MrBrownCow
I did the AVS - VPY comparison, on a 12 minute encode, the difference was 2 seconds, not significant.

@Stax76 @Atlantis @AMED : tested beta 2.1.6.1, it fixes indeed the issue of simultaneous processing with two staxrip instances

@MrBrownCow: there are several things you have to make sure of before continuing (and maybe you have, so only checking):
- do not process other than the video, set all audio tracks to No audio
- make sure you are using the same video source
- make sure you are not applying filters

[stax76]

Since there were two severe bugs, I've uploaded a fixed stable release 2.1.7.0.

[AMED]

It's not the best possible location, that's why it's not permitted by default:

Custom paths within the startup folder are not permitted
because it would prevent a simple update process.
Please put the file somewhere else outside the startup folder.No problems, I thought I would mention it since that's were you would normally put the files for previous versions of StaxRip.

Thank you for the quick bugfix version.

[JKyle]

DGIndex (part of DGMPGDec) is finally updated to 2.0.00 (in 10 years) :).

--------------------------
Changes from version 1.5.8
--------------------------

1. Rebuilt with Visual Studio 2019.
2. A 64-bit executable of DGDecode is now included (derived from fork by Asd-g).
3. DGDecode now works with Avisynth 2.6 and Avisynth+.

Website: http://rationalqm.us/dgmpgdec/dgmpgdec.html


1. Probable issues related to D2VSource for AVS

We need to check if D2VSource for AVS (by Asd-g (https://github.com/Asd-g/MPEG2DecPlus)) currently registered in Apps is compatible with this update.
If not, let's see if Asd-g will update D2VSource as well accordingly.

At this point, I'm wondering if the updated DGDecode.dll(MPEG2Source) can replace D2VSource. This needs further testing.

But even if it can be a replacement, I believe it's a matter of decision by @stax76 whether DGDecode.dll will be adopted or not as it needs some modification of the app structure (and AVS Filters Profiles) if it's adopted.


2. Compatibility with d2vsource for VS

We also need to test whether the currently registered d2vsource (https://github.com/dwbuiten/d2vsource) filter works well with the updated version of DGIndex in VapourSynth.

And again, we need to wait for an appropriate update of the source filter if not.

[videoh]

Better late than never, eh?

Just in case you did not know... DGMPGDec 2.0.00's included 64-bit DGDecode.dll supports both AVISynth(+) and Vapoursynth. Work is ongoing to improve performance for DGIndex. It is quite slow compared to DGIndexNV.

Nothing has changed in DGIndex that would invalidate d2vsource, but the hope is that the newest DGDecode makes d2vsource unnecessary.

There are no licensing issues, everything is GPL 2.0 as always. You won't get any hassles from DG.

[NanoBot]

Hi,

until today, I used the beta versions up to 2.1.5.5 together with DGIndexNV to reencode h264 files to a lower bitrate without problems.

Since version 2.1.7.0 this error message appears when I am trying to encode with x264:
"x264 Avisynth input supports only ... as input colorspace"
Consider to use a pipe tool: x264 > Input/Output > Pipe > avs2pipemod y4m

This setting is on "automatic". The source file and all other settings are the same.
The same error message appeared when I used the 2.1.5.5 beta with the "newer" staxrip.exe which was on dropbox and is been removed in the meantime.

After I switched the 2.1.7.0 to " avs2pipemod y4m" I could encode the file. Here are the logfiles from 2.1.5.5 and 2.1.7.0 for clarification:

------------------------- System Environment -------------------------

StaxRip : 2.1.5.5
Windows : Windows 10 Pro 2009
Language : German (Germany)
CPU : AMD Ryzen 9 3900X 12-Core Processor
GPU : NVIDIA GeForce GTX 1060 3GB
Resolution : 1920 x 1080
DPI : 96

----------------------- Media Info Source File -----------------------

E:\Video\Clips\Test.dgi

General
Complete name : E:\Video\Clips\Test.dgi
File size : 752 KiB

---------------------------- Configuration ----------------------------

Template : DGSource x264 denoise crf23
Video Encoder Profile : x264
Container/Muxer Profile : No Muxing

--------------------------- AviSynth Script ---------------------------

AddAutoloadDir("D:\MPEG\Staxrip_Beta\Apps\FrameServer\AviSynth\plugins")
LoadPlugin("D:\MPEG\DGIndexNV\DGDecodeNV.dll")
DGSource("E:\Video\Clips\Test.dgi",ct=0,cb=0,cl=0,cr=0,rw=0,rh=0)
DGDenoise()

------------------------- Source Script Info -------------------------

Width : 1920
Height : 1080
Frames : 42055
Time : 28:02.200
Framerate : 25 (25000/1000)
Format : YUV420P8

------------------------- Target Script Info -------------------------

Width : 1920
Height : 1080
Frames : 42055
Time : 28:02.200
Framerate : 25 (25000/1000)
Format : YUV420P8

--------------------------- Video encoding ---------------------------

x264 M-0.161.3027-4121277-x64-gcc10.2.0 Patman

D:\MPEG\Staxrip_Beta\Apps\Encoders\x264\x264.exe --crf 23 --colorprim bt709 --colormatrix bt709 --transfer bt709 --output E:\Video\Clips\Test2155.h264 D:\StaxTemp\Test_temp\Test2155.avs

and

------------------------- System Environment -------------------------

StaxRip : 2.1.7.0
Windows : Windows 10 Pro 2009
Language : German (Germany)
CPU : AMD Ryzen 9 3900X 12-Core Processor
GPU : NVIDIA GeForce GTX 1060 3GB
Resolution : 1920 x 1080
DPI : 96

----------------------- Media Info Source File -----------------------

E:\Video\Clips\Test.dgi

General
Complete name : E:\Video\Clips\Test.dgi
File size : 752 KiB

---------------------------- Configuration ----------------------------

Template : DGSource x264 denoise crf23
Video Encoder Profile : x264
Container/Muxer Profile : No Muxing

--------------------------- AviSynth Script ---------------------------

AddAutoloadDir("D:\MPEG\Staxrip\Apps\FrameServer\AviSynth\plugins")
LoadPlugin("D:\MPEG\DGIndexNV\DGDecodeNV.dll")
DGSource("E:\Video\Clips\Test.dgi",ct=0,cb=0,cl=0,cr=0,rw=0,rh=0)
DGDenoise()

------------------------- Source Script Info -------------------------

Width : 1920
Height : 1080
Frames : 42055
Time : 28:02.200
Framerate : 25 (25000/1000)
Format : YUV420P8

------------------------- Target Script Info -------------------------

Width : 1920
Height : 1080
Frames : 42055
Time : 28:02.200
Framerate : 25 (25000/1000)
Format : YUV420P8

--------------------------- Video encoding ---------------------------

x264 M-0.161.3027-4121277-x64-gcc10.2.0 Patman

D:\MPEG\Staxrip\Apps\Support\avs2pipemod\avs2pipemod64.exe -dll=D:\MPEG\Staxrip\Apps\FrameServer\AviSynth\AviSynth.dll -y4mp D:\StaxTemp\Test_temp\Test2170.avs | D:\MPEG\Staxrip\Apps\Encoders\x264\x264.exe --crf 23 --colorprim bt709 --colormatrix bt709 --transfer bt709 --demuxer y4m --frames 42055 --output E:\Video\Clips\Test2170.h264 -


As you will notice, the source script in both cases has the YUV420P8 color format, which is a valid colorspace for the encoder. Nevertheless, version 2.1.7.0 forces the use of a pipe, while version 2.1.5.5 beta works flawless without a pipe. The included x264 encoder versions are idenctical.

And now the most astonishing: If I load the same clip with the h264 template, I get the error message. Then I switch to h265, the error message disappears and I can start the encode without a pipe. If I then abort the h265 encode and then switch back to h264, the error message is not shown again and the clip can be encoded to h264 without a pipe.

For me it looks to me that for some reason the 2.1.7.0 version by mistake complains about an incompatible color format.

C.U. Nanobot

[MrBrownCow]

@MrBrownCow: there are several things you have to make sure of before continuing (and maybe you have, so only checking):
- do not process other than the video, set all audio tracks to No audio
- make sure you are using the same video source
- make sure you are not applying filters

@44vince44
Thanks for testing VPY.
I am using the same source clip each time.
I am setting all audio to "No audio" each time
I am NOT using any filters

I went back and grabbed 2.1.3.0 and added that to the test results as well as 2.1.6.1 and 2.1.7.0.

Staxrip Test Encode time
2.1.3.0 Duration: 00:08:15 uses AviSynth 3.6.0
2.1.3.7 Duration: 00:08:23 uses AviSynth 3.6.1
2.1.4.8 Duration: 00:13:31 uses AviSynth 3.6.2 test 2
2.1.4.9 Duration: 00:13:37 uses AviSynth 3.6.2 test 2
2.1.5.2 Duration: 00:14:04 uses AviSynth 3.6.2 test 2
2.1.5.5 Duration: 00:13:19 uses AviSynth 3.6.2 test 6
2.1.6.0 Duration: 00:12:58 uses AviSynth 3.6.2 test 6
2.1.6.1 Duration: 00:13:04 uses AviSynth 3.6.2 test 6
2.1.7.0 Duration: 00:13:01 uses AviSynth 3.6.2 test 6

I wasn't able to find any changelog for AviSynth 3.6.2 versions. Does this newer version include some quality enhancements that might account for the large reduction in speed?

Vince is it possible for you to test a short clip and verify you see an fps reduction as well?

2.1.3.0 logs
https://pastebin.com/gc1bmMuD

2.1.7.0 logs
https://pastebin.com/rJuX8XqJ

[JKyle]

Just in case you did not know... DGMPGDec 2.0.00's included 64-bit DGDecode.dll supports both AVISynth(+) and Vapoursynth. Work is ongoing to improve performance for DGIndex. It is quite slow compared to DGIndexNV.

Nothing has changed in DGIndex that would invalidate d2vsource, but the hope is that the newest DGDecode makes d2vsource unnecessary.

There are no licensing issues, everything is GPL 2.0 as always. You won't get any hassles from DG.

Good to hear that.

So, in VapourSynth, what's the minimal syntax for MPEG2Source?

Please, see if the following is OK.

core.std.LoadPlugin(r"\PATH\TO\DGDecode.dll")
clip = core.dgdecode.MPEG2Source(r"\PATH\TO\A\D2V_File.d2v")


Since the DGDecode Manual doesn't have anything about VapourSynth, I misunderstood it's only for AviSynth.

Could you please include a guide to usage in VapourSynth in the manual? Thanks.

[videoh]

So, in VapourSynth, what's the minimal syntax for MPEG2Source?

Good question. Need to add that to the readme64.

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(".../DGDecode.dll")
video = core.dgdecode.MPEG2Source(".../Nature.d2v")
video = vs.core.text.ClipInfo(video)
video.set_output()

You can use the avscompat mode too, but why?

Since the DGDecode Manual doesn't have anything about VapourSynth, I misunderstood it's only for AviSynth.

Could you please include a guide to usage in VapourSynth in the manual? Thanks. Sure. Thank you for your suggestions.

[44vince44]

@NanoBot is this specific to DGIndexNV ?
I've just tested to encode from h264 to x264 in Staxrip 2.1.7.0 leaving the pipe automatic (i.e no pipe used) and it worked.

[44vince44]

@MrBrownCow

I've just made the following test: basic encoding one pass quality crf mode, with --crf 22 --output-depth 10 switches ONLY (so it's implied that preset=medium), on both v 2.1.3.0 and 2.1.7.0.
Same source, same source filter, same everything. Using the internal and default setting of each version.
I got so significant difference : 4 seconds on a 4 minutes process:

2.1.3.0
x265 M-3.4+6-g73f96ff39-gcc11.0.0 Patman

"D:\Downloads\_IDM Downloads\StaxRip-x64-2.1.3.0-stable\Apps\Support\avs2pipemod\avs2pipemod64.exe" -y4mp "D:\Downloads\_IDM Downloads\i_y5_temp\i_y5_new.avs" | "D:\Downloads\_IDM Downloads\StaxRip-x64-2.1.3.0-stable\Apps\Encoders\x265\x265.exe" --crf 22 --output-depth 10 --frames 3600 --y4m --output "D:\Downloads\_IDM Downloads\i_y5_temp\i_y5_new_out.hevc" -

avs2pipemod[info]: writing 3600 frames of 1000000/41731 fps, 1920x1080,
sar 0:0, YUV-420-planar-8bit progressive video.
y4m [info]: 1920x1080 fps 1000000/41731 i420p8 unknown frame count
raw [info]: output file: D:\Downloads\_IDM Downloads\i_y5_temp\i_y5_new_out.hevc
x265 [info]: HEVC encoder version 3.4+6-g73f96ff39
x265 [info]: build info [Windows][GCC 11.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-22.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing lslices=6 deblock sao
avs2pipemod[info]: finished, wrote 3600 frames [100%].
avs2pipemod[info]: total elapsed time is 292.917 sec.
x265 [info]: frame I: 35, Avg QP:18.37 kb/s: 17362.40
x265 [info]: frame P: 1174, Avg QP:22.61 kb/s: 3783.32
x265 [info]: frame B: 2391, Avg QP:28.34 kb/s: 677.11
x265 [info]: Weighted P-Frames: Y:1.4% UV:1.4%
x265 [info]: consecutive B-frames: 25.1% 13.2% 12.3% 37.3% 12.0%
encoded 3600 frames in 291.21s (12.36 fps), 1852.30 kb/s, Avg QP:26.38

Start: 01:57:51
End: 02:02:45
Duration: 00:04:54

2.1.7.0
x265 M-3.4+28 gcc10.2.0 Yuuki-Asuna/msg7086/DJATOM/Patman

"D:\Downloads\_IDM Downloads\StaxRip-x64-2.1.7.0-Stable\Apps\Encoders\x265\x265.exe" --crf 22 --output-depth 10 --output "D:\Downloads\_IDM Downloads\i_y5_temp\i_y5_new2170_out.hevc" "D:\Downloads\_IDM Downloads\i_y5_temp\i_y5_new2170.avs"

avs+ [info]: AviSynth+ 3.6.2 (r3341, master, x86_64)
avs+ [info]: Video colorspace: YUV420 (YV12)
avs+ [info]: Video depth: 8
avs+ [info]: Video resolution: 1920x1080
avs+ [info]: Video framerate: 1000000/41731
avs+ [info]: Video framecount: 3600
avs+ [info]: 1920x1080 fps 1000000/41731 i420p8 frames 0 - 3599 of 3600
raw [info]: output file: D:\Downloads\_IDM Downloads\i_y5_temp\i_y5_new2170_out.hevc
x265 [info]: HEVC encoder version x265M 3.4+28-419182243
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-22.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing lslices=6 deblock sao
avs2pipemod[info]: finished, wrote 3600 frames [100%].
avs2pipemod[info]: total elapsed time is 292.917 sec.
x265 [info]: frame I: 35, Avg QP:18.37 kb/s: 17362.40
x265 [info]: frame P: 1174, Avg QP:22.61 kb/s: 3783.32
x265 [info]: frame B: 2391, Avg QP:28.34 kb/s: 677.11
x265 [info]: Weighted P-Frames: Y:1.4% UV:1.4%
x265 [info]: consecutive B-frames: 25.1% 13.2% 12.3% 37.3% 12.0%
encoded 3600 frames in 291.21s (12.36 fps), 1852.30 kb/s, Avg QP:26.38

Start: 02:05:07
End: 02:09:58
Duration: 00:04:50

[Atlantis]

Thank you for 2.1.7.0. Everything working great for me.

You said "you can always find it in the info dialog". Where is this info dialog that shows the output resolution?

I see the output resolution under resize now.

Under Source you show the input resolution,
what about putting output resolution under Target? It already shows duration, framerate and Audio Bitrate.
Maybe that's a better logical place than under resize.

[44vince44]

@Atlantis, the info dialog is the drop-down menu above the filters section, saying "AVS Filters" or "VS Filters"
Click on it, you get a menu, with "Info" ...

You can also open a preview window, and press "i" to get information in a small overlay box.

[NanoBot]

@NanoBot is this specific to DGIndexNV ?
I've just tested to encode from h264 to x264 in Staxrip 2.1.7.0 leaving the pipe automatic (i.e no pipe used) and it worked.

I don't think that it is dgindexnv related, because

version 2.1.5.5 works flawless
switching to h265, aborting the encode and switching back to h264 makes version 2.1.7.0 to work
replacing the staxrip.exe from 2.1.7.0 with the staxrip.exe from 2.1.5.5 beta also makes it work again. So I suppose that there is a regression in staxrip.exe introduced between the "original" 2.1.5.5 and the version mentioned here:

https://forum.doom9.org/showthread.php?p=1932281#post1932281
https://forum.doom9.org/showthread.php?p=1932285#post1932285

And the colorspace format is a valid one, I just checked it with rightclick and "info" in the window for the AVS filters in use, which shows YUV420P8.

[44vince44]

@MrBrownCow, I made a two-pass encode with exactly the same switches that you have used.
The results are still similar (on my i7 setup = 8 logical cores) :
2.1.3.0: pass1 00:21:30 ; pass2 00:20:35
2.7.7.0: pass1 00:22:04 ; pass2 00:22:05

This difference is due to the x265 version difference, and it's a small difference.

I think I know what is happening in your case, it's due to the high number of cores in your processor, and you can check it by monitoring the global CPU usage when doing an encode with 2.1.3.0 and 2.1.7.0. One cause could be the ffms2 video source filter. Due to compatibility with some video source types, I believe the coder has restricted number of threads to use, according to the type of videos.
You can try replacing the ffms2 contents of 2.1.7.0 with the ones in 2.1.3.0 and see what happens.
You can also try another source filter.

[44vince44]

@Nanobot just to be sure, can you please go to this repository (Patman86's files):
https://www.mediafire.com/folder/vkt2ckzjvt0qf/StaxRip_Tools
and get latest x264M build (x264M-0.161.3030-xxxx , the x64 gcc version) and try it. I remember that Patman86 has changed something regarding the pipe.
I know that you've experienced the problem by simply changing the staxrip.exe, but please try.

[MrBrownCow]

I think I know what is happening in your case, it's due to the high number of cores in your processor, and you can check it by monitoring the global CPU usage when doing an encode with 2.1.3.0 and 2.1.7.0. One cause could be the ffms2 video source filter. Due to compatibility with some video source types, I believe the coder has restricted number of threads to use, according to the type of videos.
You can try replacing the ffms2 contents of 2.1.7.0 with the ones in 2.1.3.0 and see what happens.
You can also try another source filter.

@44vince44
Thanks for testing. I took ffms2.dll and ffmsindex.exe from 2.1.3.0 and used them with 2.1.7.0 but got the same results, about 40% slower.
Also tried using the newer ffms2 files from 2.1.7.0 with the older 2.1.3.0 and still got the faster result.

CPU usage seems to be similar on both, it bounces around between 50-60%. See screenshots here, not sure if you notice anything. Notice the fps is higher with 2.1.3.7, always between 5 and 15 fps higher.
https://imgur.com/a/FMz6oG6

I have to admit I have never changed source filter before and don't know how. Is that where it says "Source Automatic"? What should I try changing to?

[Atlantis]

Thank you. Found the info dialog.
Here is what I'm talking about:

https://i.postimg.cc/4ygPDWBr/Untitled.jpg

[44vince44]

@Atlantis: Stax76 has achieved in this build is to show you the output resolution in the "Resize area" in the middle of the window.
The only case where it won't be satisfactory is when resize is active, and a geometry filter is used below (after) resize.
You still have the info and preview. I remember in the past I asked the same thing but Stax76 explained to me that changing parts of the interface where you are pointing to is not simple at all.
At that time the concern was to have the MOD warning take into account any and all geometry filters. And that was fixed of course.

@MrBrownCow I am puzzled, my tests show no such difference. here are the logs, maybe you can find something useful in them:

here is for 2.1.3.0 https://pastebin.com/ycQZzRX2
here is for 2.1.7.0 https://pastebin.com/gZM38pJh

Yes, source filter is where it says "automatic" and your log files show it has selected for you FFVideoSource (ffms2), which is ok.
you can try to set there LWLibavVideoSource

[stax76]

@NanoBot

It seems DGDecodeNV and for instance ffms2 return something different:


YUV420P8 = -1610612720
YUV420P8_ = -1610612728


https://github.com/staxrip/staxrip/blob/master/General/FrameServer.vb#L110

I'll change it to allow both.

Edit:

There should now be a new StaxRip.exe file on the Beta cloud folders.

[NanoBot]

@stax76

At first glance, the staxrip.exe from the beta cloud folder solves the problem. The error message complaining the wrong colorspace no longer appears, and the h264 reencoding to a lower bitrate / crf works flawless again.

:thanks:

[stax76]

@NanoBot

You're welcome!

@Atlantis

I've added it now, there is a new StaxRip.exe file on the Beta cloud folders.

[44vince44]

@Stax76 : Ah so it wasn't that difficult ;-)))

[JKyle]

DGMPGDec(DGIndex & DGDecode.dll for MPEG2Source) is updated to 2.0.01:

* Fixed decode crash with 64-bit DLL in Vapoursynth mode when stream has RFF flags. The UV pitch was getting set wrong.

DGIndex remains the same as 2.0.00 and only 64-bit DGDecode.dll has been updated.

Here (https://www.videohelp.com/software/DGMPGDec).

For your reference, I posted a feature request on the GitHub issue tracker to incorporate MPEG2Source as a native source filter (for d2v) in StaxRip.
See this (https://github.com/staxrip/staxrip/issues/424).

[videoh]

JKyle is now Moose Approved. Congratulations!

[manolito]

Quick question:

The changelog for 2.0.01 says that this new version now works under AVS 2.6 and under AVS+. This confuses me a little bit because I have used version 1.5.8 for quite some time under AVS+ 32-bit, and so far I did not have any problems.

If there are any potential problems with 1.5.8 under AVS+ 32 could you please advise what I should look for?

[MrBrownCow]

Yes, source filter is where it says "automatic" and your log files show it has selected for you FFVideoSource (ffms2), which is ok.
you can try to set there LWLibavVideoSource

@44vince44
Thanks for your help thus far. I moved all of the below folders from 2.1.7.0 over to 2.1.3.7 in an effort to use as many of the new tools with the older version. Thinking maybe this would help reveal a tool that was causing the slow down or prove at least these tools were not the problem.
Encoders - x265
Encoders - ffmpeg
Frameserver - AviSynth
Plugins - Dual - FFMS2

Then ran the same test again after updating the version numbers of the tools etc.

2.1.3.7 w new apps and FFVideo = Duration: 08:19
2.1.3.7 w new apps and LWLibavVideoSource = Duration: 08:23
2.1.7.0 with LWLibavVideoSource = Duration: 13:10
2.1.7.0 with Automatic (FFVideo) = Duration: 13:01

Maybe premature but it would seem like this rules out x265, ffmpeg, AviSynth, FFMS2 and different source filters like LWLibavVideoSource.

If the difference in encode speed was 5-10% I wouldn't even worry, but over 40% slower encoding is a bit too much to handle.

Anything else you think I should move over from 2.1.7.0 to 2.1.3.7?
Any other test or change you can think of?

[videoh]

Quick question:

The changelog for 2.0.01 says that this new version now works under AVS 2.6 and under AVS+. This confuses me a little bit because I have used version 1.5.8 for quite some time under AVS+ 32-bit, and so far I did not have any problems. Bad wording. I just meant that now it can run fine under the newer frame servers like Avs 2.6 line, Avs+ line, and Vapoursynth.

If there are any potential problems with 1.5.8 under AVS+ 32 could you please advise what I should look for? Only potential problem could be XP.

[manolito]

Only potential problem could be XP.

Thanks for the clarification. I already noticed that the new version does not like WinXP, and since I want to have identical plugin versions on all of my machines I will stick with version 1.58. I do not use VapourSynth, I try to stay away from 64-bit stuff whenever I can, so I will not loose anything by keeping the older version. (I use Groucho's ICL build which seems to be a little bit faster.)

[44vince44]

@MrBrownCow, thanks for doing all those tests.

The test you made seems to reveal that it's a problem with the no-pipe method used since around 2.1.5.5. I can't think of anything else.

Here is the ultimate test you could do: in 2.1.7.0, go to x265 options, get to Input/Output section, select Pipe: Avs2pipemod instead of None. Do your encode.
FYI, I have already made such test, which revealed a small difference (Avs2pipemod was faster, which was not the expected behavior) I wanted to discuss it with Patman86, but later, because the difference was small. But if it turns out to be the reason of your problem, then we should prioritize it, and it's no bug in staxrip, but a tool issue.
Can't wait to see your test's results!

[apophis906]

@MrBrownCow, thanks for doing all those tests.

The test you made seems to reveal that it's a problem with the no-pipe method used since around 2.1.5.5. I can't think of anything else.

Here is the ultimate test you could do: in 2.1.7.0, go to x265 options, get to Input/Output section, select Pipe: Avs2pipemod instead of None. Do your encode.
FYI, I have already made such test, which revealed a small difference (Avs2pipemod was faster, which was not the expected behavior) I wanted to discuss it with Patman86, but later, because the difference was small. But if it turns out to be the reason of your problem, then we should prioritize it, and it's no bug in staxrip, but a tool issue.
Can't wait to see your test's results!

I dont know if this is related, but from my testing when I try to do a chunk encode with avs I get an IO access error saying the avs file is open in another program. It will do the first chunk job usually but when it tries to start the next job it will show the error trying to start the second chunk. Once I acknowledge the error the chunk will start to encode. I tried settings it to Avs2pipemod since I saw that it used that when doing chunks. Yet still it would pop the error every few times like it would forget I had set it and try to do a direct input or something.

[videoh]

I will not lose anything by keeping the older version. Functionality-wise, that's right. I am working on performance improvements, however, that you would miss.

[Atlantis]

Thank you for the new file. Used it, it looks great with the output resolution shown in the Target Area.

@44vince44. Why should it be difficult? It is just showing a text. ;D

[44vince44]

@Atlantis, I couldn't agree more ;-))

[Atlantis]

So in the new version, AAC audio encoding has changed. I need a little information on how to use it.

First when you change the Quality number, the Bitrate shown is not the same as before. I remember 0.4 was around 310 for bitrate. Now 40 is 262.

Is the 0.4 of before the same quality as the 40 now? Although that it shows lower bitrate?

Now it is using True VBR, what was it before? I don't remember.

Also, High Efficiency is disabled, what does it do, should we enable it? Is it the equivalent of H265 in audio?

Edit: Sorry if this was discussed. Can't encode AAC anymore like before. Where should I find/get CoreAudioToolbox.dll?

[44vince44]

@Atlantis, AAC encoding logic was not changed, but the defaults must be set now:

When I read you writing q=0.4, I seem to understand that you were using Eac3to which requires NeroAACEnc.
So in the AAC encoding options, select Encoder = Eac3to instead of Automatic.
Then you'll get the 0.x you're used to.
You'll need to point to the proper dll from the app manager (while it's still in the folder Staxrip/APPS/AUDIO/Eac3to). Staxrip will invite you to do so, when you create the job.
Keep a backup of that dll.

[44vince44]

@apophis906, I have just made a test (which allow me to find another bug BTW), but I could not reproduce your issue.
Can you paste the log file to pastebin.com and link to it here so i can see the log ?

EDIT: I COULD REPRODUCE THE BUG. when reprocessing same file (without purging temp folder from previous process) and without closing staxrip. I seem to reproduce it every time! I'll open a bug report on github, when I'll have that confirmed
Edit2 : Reproducing the bug is random...

[apophis906]

@apophis906, I have just made a test (which allow me to find another bug BTW), but I could not reproduce your issue.
Can you paste the log file to pastebin.com and link to it here so i can see the log ?

EDIT: I COULD REPRODUCE THE BUG. when reprocessing same file (without purging temp folder from previous process) and without closing staxrip. I seem to reproduce it every time! I'll open a bug report on github, when I'll have that confirmed
Edit2 : Reproducing the bug is random...

Yeah I noticed that at times it would do two in a row fine and then pop up all of a sudden. I went ahead and uploaded the log file as well as a copy of the error just in case.
iZombie test_new 2_staxrip.log (https://pastebin.com/TQffhhUZ)
IOException (2.1.7.0) (https://pastebin.com/20HaYshw)

[44vince44]

@apophis906 I filed the bug report, you can follow it up here https://github.com/staxrip/staxrip/issues/431

[44vince44]

@MrBrownCow

I moved all of the below folders from 2.1.7.0 over to 2.1.3.7 in an effort to use as many of the new tools with the older version. Thinking maybe this would help reveal a tool that was causing the slow down or prove at least these tools were not the problem.
Encoders - x265
Encoders - ffmpeg
Frameserver - AviSynth
Plugins - Dual - FFMS2

Then ran the same test again after updating the version numbers of the tools etc.

2.1.3.7 w new apps and FFVideo = Duration: 08:19
2.1.3.7 w new apps and LWLibavVideoSource = Duration: 08:23
2.1.7.0 with LWLibavVideoSource = Duration: 13:10
2.1.7.0 with Automatic (FFVideo) = Duration: 13:01

When you overwrote those, did you check that x265 (in your modded staxrip 2.1.7.0) output mentioned clearly version 3.6.0 or 3.6.1 of avisynth ? It's still in the logs, you can check it.

[Atlantis]

Thank you. I set the encoder to Eac3to and it shows the old default settings.

Edit:
Still have problems. Should the provided neroAacEnc.exe with staxrip work? If yes why the path is not already set?
When I set the path to the ...Apps\Audio\eac3to, it says custom paths within the startup folder are not permitted.
What is happening here?

In the old version it just worked.

[MrBrownCow]

The test you made seems to reveal that it's a problem with the no-pipe method used since around 2.1.5.5. I can't think of anything else.

Here is the ultimate test you could do: in 2.1.7.0, go to x265 options, get to Input/Output section, select Pipe: Avs2pipemod instead of None. Do your encode.
FYI, I have already made such test, which revealed a small difference (Avs2pipemod was faster, which was not the expected behavior) I wanted to discuss it with Patman86, but later, because the difference was small. But if it turns out to be the reason of your problem, then we should prioritize it, and it's no bug in staxrip, but a tool issue.
Can't wait to see your test's results!

@44vince44
Running the test now with "Avs2pipemod instead of None". I can tell already that its going to finish with the slower 13minutes due to how it starts out. 2.1.7.0 starts out encoding my test file at around 20fps and settles down to around 11fps. When I do the encode with 2.1.3.7 it starts out around 32fps and settles down to around 18fps. Will update once it finishes in about 10 minutes.

@MrBrownCow
When you overwrote those, did you check that x265 (in your modded staxrip 2.1.7.0) output mentioned clearly version 3.6.0 or 3.6.1 of avisynth ? It's still in the logs, you can check it.

When I over wrote things in the 2.1.3.7 folder I did verify in the tools section that the version numbers were updated and it was using the newer tools from 2.1.7.0. x265 and AviSynth 3.6.2 test 6. I cannot use the older AviSynth 3.6.1 or 3.6.0 with the newer staxrip 2.1.7.0 because it gives and error. I think staxtrip 2.1.7.0 requires AviSynth 3.6.2 somewhere so the best test I can do is to add the new tools to the old app.


2.1.3.7 w new apps from 2.1.7.0 (x265, Avisynth 3.6.2 test 6, ffms2, ffmpeg) and FFVideo source filter = Duration: 08:19
2.1.3.7 w new apps from 2.1.7.0 (x265, Avisynth 3.6.2 test 6, ffms2, ffmpeg) and LWLibavVideoSource source filter = Duration: 08:23
2.1.7.0 with LWLibavVideoSource = Duration: 13:10
2.1.7.0 with Automatic (FFVideo) = Duration: 13:01
2.1.7.0 with Automatic (FFVideo) and Avs2pipemod pipe = Duration: 13:01

Something in version 2.1.4.8 and above seem to run much slower on my system for some reason. Happy to keep trying things or post logs if you want. Thanks for the ideas so far.

[44vince44]

@Atlantis: I was expected this to happen. Stax76 is taking care of things that were not considered previously, which are legal permissions to distribute stuff.

If something is not to be distributed, then it has also to be removed from the autoupdate procedure that is used by Stax76 to update the apps prior to every new beta and new release.
This is why it isn't set to be in staxrip internal trees any longer!

So I assume neroAacEnc.exe will not be distributed anymore in staxrip and should be provided by the user, in a location external to Staxrip tree (officially, Nero would install it in its own tree or choice of tree)
So keep a safe copy of YOUR neroAacEnc.exe and put it somewhere where you can point to it in all future updates of Staxrip.

The same thing goes for Apple Quicktime files required for qAAC.

All of this in order to respect the legal licenses.

[44vince44]

@MrBrownCow

Here is what our tests show.

1) on my setup (i7, 8 logical cores), all my comparisons of v2.1.3.0 vs v2.1.7.0 unmodified releases show small differences.
2) still on my setup (i7, 8 logical cores), a specific test I made using your same encoding parameters, v2.1.3.0 vs v2.1.7.0 show a small difference (less than 3%)
3) on @Dendraspis setup (Ryzen, many++ logical cores), Dendraspis made a specific test using rskip 0 which is the only critical switch in this case showed a difference of 1% between v2.1.7.0 and v2.1.3.0
4) on @Patman86 setup (also Ryzen), Patman86 made a specific test with your same encoding parameters, which showed a 1% difference between v2.1.7.0 and v2.1.3.0.

So I'm afraid we can't reproduce what you have observed... something else must be interfering, I really don't know :(

Here's the discussion https://github.com/staxrip/staxrip/issues/429

[Z'Hadum]

I have a small issue since 2.1.6.
and 2.1.7 is also affected:
If I start Staxrip from a mapped Networkshare
it asks for a Symlink for avisynth.
But then it failes to create the symlink.

I'm not sue, I think we had this also in the past?:confused:

[stax76]

Here is some info:

https://staxrip.readthedocs.io/faq.html#why-does-avisynth-portable-mode-require-soft-links

You can try:

x264/x265 Options > Input/Output > Pipe > avs2pipemod

avs2pipemod and nvenc support a custom AviSynth DLL path.

Or if you have AviSynth installed you can enable it in the settings:

Tools > Settings > Frameserver > AviSynth > Use Installed Directly

If your installed AviSynth version is too old you can copy the files from staxrip to system32.

I cannot tell you why soft link creation does not work on your system.