Log in

View Full Version : StaxRip


Pages : 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101

Yups
5th September 2015, 15:17
Latest QSVEncC fixes it. :)


Possibly because he switched to bframes 2 as new default. Because of this change the GUI needs an update.

GUI default says bframes 3
http://fs2.directupload.net/images/150905/yxnb4szj.png

Converted with bframes 2
http://fs1.directupload.net/images/150905/pua59wgl.png


Does anyone know what Ext. Features PerMBRC means?

Yups
6th September 2015, 00:03
http://rigaya34589.blog135.fc2.com/blog-entry-672.html


According to the feature table Ext_BRC and MBBRC is supported in HEVC VBR bitrate mode. For some reason it doesn't work, no effect.

PerMBRC seems to be MBBRC by the way, doesn't work though.

stax76
6th September 2015, 09:25
Possibly because he switched to bframes 2 as new default. Because of this change the GUI needs an update.

Next build has it fixed.

NikosD
6th September 2015, 15:21
I’ve just read an older post regarding the first benchmarks of the new HW decoding mode of QSVEncC.

My older benchmarks:

1) Core i7 4790 – Win 8.1 x64 Pro – iGPU HD 4600@1.5GHz – Drivers 4206
StaxRip x64 (1.3.1.2)/ QSVEncC x64 (v2.00β3)

I used CQP encoding mode using the default value of 24 with Balanced target usage and everything else set to Auto (default)
I didn’t use Audio encoding (Just Mux option or Auto Pass-through)

H.264 – Eclectic-1080p clip – 11Mbps

StaxRip x64 QSV 301 fps


The new results:

2) Core i7 4790 – Win 10 x64 Pro – iGPU HD 4600@1.5GHz – Drivers 4256
StaxRip x64 (1.3.1.2)/ QSVEncC x64 (v2.00β3)

H.264 – Eclectic-1080p clip – 11Mbps

StaxRip x64 QSV 230 fps



3) Core i7 4790 – Win 10 x64 Pro – iGPU HD 4600@1.5GHz – Drivers 4256
StaxRip x64 (1.3.1.6)/ QSVEncC x64 (v2.12)


H.264 – Eclectic-1080p clip – 11Mbps

StaxRip x64 QSV 201 fps (!)


My goodness (!)

The rise of performance using the older drivers and older QSVEncC version is 100 fps -> 50 %.

I gain 35% using older drivers and 15% using older QSVEncC.

Intel has done a disastrous job with drivers but QSVEncC looses some power too.

JohnLai
6th September 2015, 17:47
Driver and the program itself?
I was expecting the driver to be the issue....didn't expect the program itself also one of the cause (30fps gone from using new QSVenc? wow...)

*Now that might explains the anomaly of the QSV decode + resizing (vpp) slowdown*

Someone gonna report these issue to Rigaya and Intel........(~.~ I leave the task to you, @NikosD)

NikosD
6th September 2015, 17:52
Of course I have already done that :) even from version v2.06 which has the same speed like v2.12

He knows it, but haven't managed to resolve it yet.

A lot of stuff has been added to v.200 onwards and he is continuously adding more things.

Yups
6th September 2015, 19:39
ICQ bitrate mode works much better in HEVC mode, faster and much better quality at the same bitrate.

VBR
http://abload.de/img/vbrkikr1.png


ICQ
http://abload.de/img/icqc9ko3.png

RazorBurn
8th September 2015, 04:06
Thanks stax for adding KNLMeansCL in StaxRip. Would it be possible to add Chroma Processing in KNLMeansCL for both AVS+ and VS in StaxRip?

Vapoursynth:
y = core.std.ShufflePlanes(clip, planes=[0], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
u = core.std.ShufflePlanes(clip, planes=[1], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
v = core.std.ShufflePlanes(clip, planes=[2], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
clip = core.std.ShufflePlanes([y, u, v], planes=[0, 0, 0], colorfamily=vs.YUV)

AVS+
Y=KNLMeansCL(device_type="GPU")
U=UToY8().KNLMeansCL(device_type="GPU")
V=VToY8().KNLMeansCL(device_type="GPU")
YToUV (U, V, Y)

Im mostly encoded Surveillance Videos with a cheap USB Webcam, the night time videos has a lot of Chroma noise..

stax76
8th September 2015, 10:33
Thanks stax for adding KNLMeansCL in StaxRip. Would it be possible to add Chroma Processing in KNLMeansCL for both AVS+ and VS in StaxRip?

Vapoursynth:
y = core.std.ShufflePlanes(clip, planes=[0], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
u = core.std.ShufflePlanes(clip, planes=[1], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
v = core.std.ShufflePlanes(clip, planes=[2], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
clip = core.std.ShufflePlanes([y, u, v], planes=[0, 0, 0], colorfamily=vs.YUV)

AVS+
Y=KNLMeansCL(device_type="GPU")
U=UToY8().KNLMeansCL(device_type="GPU")
V=VToY8().KNLMeansCL(device_type="GPU")
YToUV (U, V, Y)

Im mostly encoded Surveillance Videos with a cheap USB Webcam, the night time videos has a lot of Chroma noise..

I'm not sure if the current system is good for adding too much code, currently all filters are loaded on startup and all settings are stored in one settings file. Deserializing the settings file takes half of the startup time and everything is always loaded in memory. There is also the problem whenever I reset the filter profiles, customizations are lost. Before adding much filter code I should probably first think about if I can find a better design being more efficient in regard of startup time and memory consumption and with better usability not resetting customizations all the time. In the next release various new plugins will be added so the filter profiles must be reset again.

cegy
8th September 2015, 11:31
stax76 is there a minor bug with preview as if the user clicks on crop the video is smaller (which is normal/good) than the whole screen for the input video of say 1920x1080 yet... for preview its full screen (as in the whole screen is covered) even if the video res is set at a smaller res say 1280x720 etc.. ?
where i'm sure when you click on preview it shows you what the output should be filters/video res wise :o

p.s the filename_preview.avs even shows the resizing aswell i.e LanczosResize(1280, 720) but it doesn't make any differences

RazorBurn
8th September 2015, 16:18
I'm not sure if the current system is good for adding too much code, currently all filters are loaded on startup and all settings are stored in one settings file. Deserializing the settings file takes half of the startup time and everything is always loaded in memory. There is also the problem whenever I reset the filter profiles, customizations are lost. Before adding much filter code I should probably first think about if I can find a better design being more efficient in regard of startup time and memory consumption and with better usability not resetting customizations all the time. In the next release various new plugins will be added so the filter profiles must be reset again.

Im not rushing you on anything, thanks BTW..

Also a few milliseconds or seconds added to startup time is not a problem for me.. A lot of people using Premiere is Pro or Photoshop are already used to long startup times..

ShamisOMally
9th September 2015, 07:16
Staxrip 1.3.1.6 refuses to mux MKV's for me, I had to go back to 1.3.1.5

JohnLai
14th September 2015, 16:20
Of course I have already done that :) even from version v2.06 which has the same speed like v2.12

He knows it, but haven't managed to resolve it yet.

A lot of stuff has been added to v.200 onwards and he is continuously adding more things.

I see, have you told rigaya about the QSVenc '--avqsv -c raw' extreme slowdown when piping it to NVencc?

Using lavfilter DSS QSV decoder results in 200fps, but using '--avqsv' in conjunction with '-c raw' only result in 60-90fps.
*1080P H264 to HEVC without resizing.

I dont believe the copy-back penalty is that severe.

Staxrip beta has the option to use QSVEncc as decoder at Nvidia H.265 --> Encoder Options--->Advanced.

NikosD
14th September 2015, 16:23
I don't use nvencc, I don't have a recent Nvidia card, I can't reproduce all those.

You could reach him in his email explaining all these.

It's been a while since his last update.
Maybe he is interested in his new version to improve it.

dejong12
14th September 2015, 22:04
I have strange issue. On my laptop, when I try to open a .ts file with DGSource indexer, nothing happens at DGIndexNV in the log files. When I remove the -a and -h arguments at Tools -> Settings -> Demuxing -> DGIndexNV, DGIndexNV.exe pops up, but nothing happens. Only when I drag the .ts file into DGIndex.nv, a .dgi is created and StaxRip loads the .dgi file, after I close DGIndexNV.exe manually.
I still have this problem, even after two Windows reinstalls (using Win 10). This also happens with .mkv so I think it'll happen with every container. I've deleted the settings file in ProgramData, but that didn't help. Making matters worse, StaxRip (using 09-09-2015 one) now crashes when it's done with DGIndexNV, but it's not leaving a crash file. So I can't use DGIndexNV. StaxRip also crashes when I try to manually open the .dgi in StaxRip. I've included the .dgi here (https://www.dropbox.com/s/d90meumneamcnly/Zwarte_Tulp-2130_20150906-15-10800000-1441567800.dgi?dl=0).

stax76
15th September 2015, 11:02
I still have this problem, even after two Windows reinstalls (using Win 10). This also happens with .mkv so I think it'll happen with every container. I've deleted the settings file in ProgramData, but that didn't help. Making matters worse, StaxRip (using 09-09-2015 one) now crashes when it's done with DGIndexNV, but it's not leaving a crash file. So I can't use DGIndexNV. StaxRip also crashes when I try to manually open the .dgi in StaxRip. I've included the .dgi here (https://www.dropbox.com/s/d90meumneamcnly/Zwarte_Tulp-2130_20150906-15-10800000-1441567800.dgi?dl=0).

Is the last write date of your DGDecodeNV.dll 2015-05-10? If not than that's the problem and re-downloading it will help.

dejong12
15th September 2015, 11:32
Is the last write date of your DGDecodeNV.dll 2015-05-10? If not than that's the problem and re-downloading it will help.
The date of that dll is 2015-05-10 actually. I redownloaded it before testing it again.

stax76
15th September 2015, 15:19
Without log file or error message I can't say much, did it work before on the same hardware, same OS and same graphics driver? Did you try things like test different file types, different source filters, test DGDecNV without any GUI, if it's not GUI related than you can also create a dedicated thread here or at DG's forum. I use DGDecNV myself and know that many StaxRip users are using it too so it's likely a problem with your system.

dejong12
16th September 2015, 00:39
Without log file or error message I can't say much, did it work before on the same hardware, same OS and same graphics driver? Did you try things like test different file types, different source filters, test DGDecNV without any GUI, if it's not GUI related than you can also create a dedicated thread here or at DG's forum. I use DGDecNV myself and know that many StaxRip users are using it too so it's likely a problem with your system.
I found out the error is related to nvcuda.
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2015-09-15T23:36:11.000000000Z" />
<EventRecordID>235</EventRecordID>
<Channel>Application</Channel>
<Computer>DESKTOP-LBA8HIM</Computer>
<Security />
</System>
- <EventData>
<Data>StaxRip.exe</Data>
<Data>1.3.1.7</Data>
<Data>55f0a322</Data>
<Data>nvcuda.dll</Data>
<Data>8.17.13.5582</Data>
<Data>55dc71ce</Data>
<Data>c0000409</Data>
<Data>000000000029c07c</Data>
<Data>1dc4</Data>
<Data>01d0f00f417ab513</Data>
<Data>D:\StaxRip x64 09-09-2015\StaxRip.exe</Data>
<Data>C:\WINDOWS\SYSTEM32\nvcuda.dll</Data>
<Data>d007d03a-5dcb-4b79-8539-4cfc5141b3e8</Data>
<Data />
<Data />
</EventData>
</Event>

Windows 10 probably does not recognize StaxRip wanting to use the Nvidia graphics card (it worked before in Windos 8.1, gfx is 660M). Any idea what goes wrong?

Jeroi
16th September 2015, 09:44
Staxx do you believe to add sometime episode handling for DVD Backup prosess? You currently have bluray but DVD episodes or PGC chapters backup is needed here atleast. DVD Decypter handles PGC's in IFO mode but all episodes are needed to manually separate and then encoded with staxx...

stax76
16th September 2015, 10:36
Windows 10 probably does not recognize StaxRip wanting to use the Nvidia graphics card (it worked before in Windos 8.1, gfx is 660M). Any idea what goes wrong?

Sorry I don't have experience with mobile NVIDIA, you could try DG's forum.

Staxx do you believe to add sometime episode handling for DVD Backup prosess? You currently have bluray but DVD episodes or PGC chapters backup is needed here atleast. DVD Decypter handles PGC's in IFO mode but all episodes are needed to manually separate and then encoded with staxx...

Dealing with VOB is even for movies broken since there aren't reliable tools, with x64 the situation is even worse, it's possible but you have to know which tools to use and how to use them and it's a lot manual work.

Aren't episodes typically stored in separate titles? MakeMKV creates a separate file for each title by default but I believe MakeMKV has also a advanced mode that can deal with chapters.

Jeroi
16th September 2015, 13:58
I found out that I can do episodes backup with DVD Shrink in reauthor mode. It will store invidual vobs to harddisck from episode titles. How ever then is needed some labour to encode the vobs to smaller size. It would be nice to have all in one open dvd and backup episodes separately to mp4 format. Handbrake is supposed to work but I found out that it works only with some vobs that are in one large vob but if there is 4 separate vobs it will not handle the episodes rigth so I need to use some other app.

stax76
16th September 2015, 14:58
If every episode is a title then why not just use MakeMKV? You'll get one MKV file for each title effortless.

Jeroi
16th September 2015, 15:28
I report still that 2pass encoding mp4 is broken. It uses for passes werad bitrates up to 23000kbit whic makes huge filesizes...

stax76
16th September 2015, 16:13
I report still that 2pass encoding mp4 is broken. It uses for passes werad bitrates up to 23000kbit whic makes huge filesizes...

Which encoder?

For most problems I'll have to see a full log file which can be uploaded to www.pastebin.com, pastebin has a auto expire feature which should always be set to 30 days.

dejong12
16th September 2015, 20:36
Sorry I don't have experience with mobile NVIDIA, you could try DG's forum.
I found out the troublemaker. It's the Avisynth version (r1773) you included, which is causing the crashing. Installing the newer r1825 fixes it and I'm able to use StaxRip and DGIndexNV once more.

videoh
16th September 2015, 20:49
I found out the troublemaker. It's the Avisynth version (r1773) you included, which is causing the crashing. Installing the newer r1825 fixes it and I'm able to use StaxRip and DGIndexNV once more. Good to know. Thanks for the information, dejong12.

Groucho2004
16th September 2015, 20:53
I found out the troublemaker. It's the Avisynth version (r1773) you included, which is causing the crashing.
@stax
Huh? Is this (http://forum.doom9.org/showthread.php?p=1736650#post1736650) the one you included? Seriously? Have a look at the very next post in that thread and the one after that.

dejong12
16th September 2015, 21:19
Good to know. Thanks for the information, dejong12.
I found the cause by using my pc with Windows 10 which I know for sure works. I reinstalled Windows a few days ago and I was using the latest StaxRip version (09-09-2015) which has AS+ r1773 included. When I tried to index a file, DGIndexNV gave me an error about not supporting MPEG1, which was weird because the video was similar to the file I sent you a few weeks ago. I tried to index it with just DGIndexNV and that worked, but when I tried to import the resulting .dgi into StaxRip, StaxRip crashed. That was when I noticed I had installed the older r1773 version. So I tried r1825 and lo and behold, everything worked again.

JohnLai
17th September 2015, 05:48
Staxrip 1.3.1.6 refuses to mux MKV's for me, I had to go back to 1.3.1.5

Bump for this muxing bug.

[@stax76]

When I select the audio to 'Just Mux', the muxing stage will fail.
Using StaxRip_x64_2015-09-09.

Jeroi
17th September 2015, 11:03
H264 aac audio mp4 2pass encoding sets the weard bitrates on it's own. I cannot change bitrate even manually --bitrate 900 option to command the prosess to calculate 1pass and second pass in 900 bitrate.

Could you add to encoder options when 2pass selected the target bitrate box?

stax76
17th September 2015, 16:01
@all

Please don't forget posting the log file, I wrote it now also to my signature:

For StaxRip support please always post the log file to www.pastebin.com and enable auto expire after 30 days.

Bump for this muxing bug.

I had tested this too without having problems, please post the log file.

@stax
Huh? Is this (http://forum.doom9.org/showthread.php?p=1736650#post1736650) the one you included? Seriously? Have a look at the very next post in that thread and the one after that.

I used rev 1773 in a test release, on my sample clips DGDecNV didn't produce errors. Can you recommend a particular build?

H264 aac audio mp4 2pass encoding sets the weard bitrates on it's own. I cannot change bitrate even manually --bitrate 900 option to command the prosess to calculate 1pass and second pass in 900 bitrate.

Could you add to encoder options when 2pass selected the target bitrate box?

Looks OK here, there is a new option at:

main menu > Options > Misc > Use fixed bitrate

make sure this is zero so the value in the main dialog is used, also make sure you have no --bitrate entered as custom command line switch. I entered 941 in the main dialog and it was passed to x264 correctly and the x264 output was correct two.

Another factor is after audio encoding a video bitrate recalculation is happening adjusting the video bitrate to the bitrate of the audio output, I tested this also and it's still working. Without log file and more detailed description I can't tell much more.


------------------------------------------------------------
x264
------------------------------------------------------------

"D:\Projekte\GitHub\staxrip\bin\Apps\x264\x264.exe" --preset veryfast --pass 1 --bitrate 941 --stats "D:\Temp\Encoding\test temp files\test.stats" --output NUL "D:\Temp\Encoding\test temp files\test.avs"

avs [info]: 1920x1080p 0:0 @ 30000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
x264 [info]: profile Main, level 4.0
x264 [info]: frame I:16 Avg QP:28.35 size: 62235
x264 [info]: frame P:1429 Avg QP:34.42 size: 4251
x264 [info]: frame B:942 Avg QP:33.95 size: 576
x264 [info]: consecutive B-frames: 45.6% 3.7% 4.8% 45.9%
x264 [info]: mb I I16..4: 69.9% 0.0% 30.1%
x264 [info]: mb P I16..4: 10.5% 0.0% 0.0% P16..4: 11.6% 0.0% 0.0% 0.0% 0.0% skip:77.9%
x264 [info]: mb B I16..4: 0.4% 0.0% 0.0% B16..8: 1.8% 0.0% 0.0% direct: 0.7% skip:97.2% L0:43.5% L1:55.5% BI: 1.0%
x264 [info]: final ratefactor: 33.04
x264 [info]: coded y,uvDC,uvAC intra: 5.2% 27.5% 4.1% inter: 0.4% 1.9% 0.0%
x264 [info]: i16 v,h,dc,p: 36% 31% 23% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 22% 22% 8% 8% 5% 8% 4% 6%
x264 [info]: i8c dc,h,v,p: 70% 13% 12% 5%
x264 [info]: Weighted P-Frames: Y:0.6% UV:0.2%
x264 [info]: kb/s:764.69
encoded 2387 frames, 157.06 fps, 764.69 kb/s

Start: 16:30:07
End: 16:30:22
Duration: 00:00:15


------------------------------------------------------------
x264 Second Pass
------------------------------------------------------------

"D:\Projekte\GitHub\staxrip\bin\Apps\x264\x264.exe" --preset veryfast --pass 2 --bitrate 941 --stats "D:\Temp\Encoding\test temp files\test.stats" --output "D:\Temp\Encoding\test temp files\test_out.h264" "D:\Temp\Encoding\test temp files\test.avs"

avs [info]: 1920x1080p 0:0 @ 30000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:16 Avg QP:28.51 size: 51309
x264 [info]: frame P:1429 Avg QP:32.49 size: 5476
x264 [info]: frame B:942 Avg QP:35.70 size: 749
x264 [info]: consecutive B-frames: 45.6% 3.7% 4.8% 45.9%
x264 [info]: mb I I16..4: 18.5% 74.1% 7.4%
x264 [info]: mb P I16..4: 4.7% 5.8% 0.0% P16..4: 12.4% 2.4% 0.5% 0.0% 0.0% skip:74.3%
x264 [info]: mb B I16..4: 0.2% 0.2% 0.0% B16..8: 2.2% 0.3% 0.0% direct: 0.6% skip:96.4% L0:43.5% L1:54.3% BI: 2.2%
x264 [info]: 8x8 transform intra:56.8% inter:59.9%
x264 [info]: coded y,uvDC,uvAC intra: 19.1% 30.4% 4.1% inter: 0.5% 2.4% 0.0%
x264 [info]: i16 v,h,dc,p: 37% 32% 21% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 18% 54% 2% 3% 2% 3% 2% 3%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 21% 17% 9% 11% 7% 9% 5% 7%
x264 [info]: i8c dc,h,v,p: 66% 15% 14% 5%
x264 [info]: Weighted P-Frames: Y:0.6% UV:0.2%
x264 [info]: kb/s:939.37
encoded 2387 frames, 274.08 fps, 939.37 kb/s

JohnLai
17th September 2015, 16:12
[@stax76]


Error Muxing using mkvmerge

Muxing using mkvmerge failed with error code 3

mkvmerge v8.3.0 ('Over the Horizon') 64bit
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.



StaxRip.ErrorAbortException: Muxing using mkvmerge failed with error code 3

mkvmerge v8.3.0 ('Over the Horizon') 64bit
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.


at StaxRip.Proc.Start() in D:\Projekte\GitHub\staxrip\General\Proc.vb:line 235
at StaxRip.MkvMuxer.Mux() in D:\Projekte\GitHub\staxrip\General\Muxer.vb:line 512
at StaxRip.MainForm.Encode() in D:\Projekte\GitHub\staxrip\Forms\MainForm.vb:line 2289
at StaxRip.MainForm.RunJobRecursive() in D:\Projekte\GitHub\staxrip\Forms\MainForm.vb:line 3583

stax76
17th September 2015, 16:21
@JohnLai

StaxRip raises a exception because exit code 3 is not mentioned in the mkvmerge documentation:

https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.exit_codes

I need always a full log file so I can see all parameters giving me hints to reproduce it.

Any other build, the best would be r1576 which is pretty stable. r1773 was pulled from Git and user Elegant hacked around in the code a bit because he thought he could solve the problem.

I can't use r1576 because I have features where ffmpeg use AviSynth+ and ffmpeg is not compatible with r1576, ffmpeg work only with more recent AviSynth+ builds.

JohnLai
17th September 2015, 16:24
@JohnLai

StaxRip raises a exception because exit code 3 is not mentioned in the mkvmerge documentation:

https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.exit_codes

I need always a full log file so I can see all parameters giving me hints to reproduce it.

Full log? I only saw one text file inside the folder created by staxrip. That one?

EDIT: Check your PM inbox.

stax76
17th September 2015, 16:32
Full log? I only saw one text file inside the folder created by staxrip. That one?

If there isn't a better log file then please post MediaInfo and a screenshot of the main dialog showing the used options.

JohnLai
17th September 2015, 16:41
If there isn't a better log file then please post MediaInfo and a screenshot of the main dialog showing the used options.

The log I pm-ed to you wasn't sufficient?

Groucho2004
17th September 2015, 16:44
I can't use r1576 because I have features where ffmpeg use AviSynth+ and ffmpeg is not compatible with r1576, ffmpeg work only with more recent AviSynth+ builds.
Right, I keep forgetting that. I guess you're stuck with r1825 for the time being. Maybe one of the AVS+ devs (like qyot27) will have a look and fix the slowdown issue.

stax76
17th September 2015, 16:49
The log I pm-ed to you wasn't sufficient?

It was my error, I deleted everything but 3 executables from the mkvmerge dir in order to save download and disk space, turns out the data dir is needed for your type of source.

JohnLai
17th September 2015, 16:52
It was my error, I deleted everything but 3 executables from the mkvmerge dir in order to save download and disk space, turns out the data dir is needed for your type of source.

I will say thanks in advance for fixing the muxing issue in your upcoming staxrip build. ^.^

Now then, my next stuff is to inform Rigaya on the weird avqsv decode slowdown this weekend.

stax76
17th September 2015, 17:14
Right, I keep forgetting that. I guess you're stuck with r1825 for the time being. Maybe one of the AVS+ devs (like qyot27) will have a look and fix the slowdown issue.

I wonder if raising money could help AviSynth+ development?

ShamisOMally
19th September 2015, 17:47
I wonder if raising money could help AviSynth+ development?

Could you at least update the 1.3.1.6 package so we can use it?

I've been using 1.3.1.5 and just moved over Nvenc/x264 files manually because it works

*EDIT* Unless I'm missing something, you said its just missing a few of the mkv merge files right? Any way to import them?

stax76
19th September 2015, 18:30
You can try a build from today:

http://www.mediafire.com/download/61vlca92h51kltw/StaxRip_x64_2015.09.19.7z

stax76
21st September 2015, 06:03
test build for AviSynth+ r1825 x64, VapourSynth R28 test4 x64, Python 3.5 x64, DGDecodeNV x64 for VapourSynth.

many people reported problems caused by using wrong app versions so exact versions are now validated and enforced and download links to the exact versions are included, it'll reduce problems and makes the setup easier.

http://www.mediafire.com/download/loyu003b1ppa22y/StaxRip_x64_2015-09-21.7z

burfadel
21st September 2015, 08:41
test build for AviSynth+ r1825 x64, VapourSynth R28 test4 x64, Python 3.5 x64, DGDecodeNV x64 for VapourSynth.

many people reported problems caused by using wrong app versions so exact versions are now validated and enforced and download links to the exact versions are included, it'll reduce problems and makes the setup easier.

http://www.mediafire.com/download/loyu003b1ppa22y/StaxRip_x64_2015-09-21.7z

QAAC has been updated to v2.53, you have v2.52.

Also, the Apple Application support files have been updated. Most of the files have the same file version (except objc.dll which is now 1.528.0.129, the version with the 21 Sep Staxrip is 1.528.0.126).

Some of the other files, despite having the same version, have also been updated (May 2015 vs March 2015):

Not identical:
CoreAudioToolbox.dll
CoreFoundation.dll
icudt49.dll
libicuin.dll
libicuuc.dll

No difference:
asl.dll
libdispatch.dll

stax76
21st September 2015, 19:32
@burfadel

Thanks, I'll update it.

burfadel
24th September 2015, 04:17
@burfadel

Thanks, I'll update it.

QAAC has been updated now to v2.55 :).

edit: As has other files (Stax knows of this)

JohnLai
24th September 2015, 06:48
Good news for AMD purists.
Rigaya finally adds VCEenc command line version
http://rigaya34589.blog135.fc2.com/blog-entry-679.html

AMD APU and AMD CPU + AMD GPU will finally get hardware based encoding?

Summoning our beloved @stax76 to implement staxrip gui.

Note:StaxRip_x64_2015-09-21 = everytime when I drag and drop a mkv file into staxrip, it keep poping up a menu asking me to install avisynth 1825 even though I already have it installed. I even check the avisynth.dll version at system32 folder and yes, it is 1825.

NikosD
24th September 2015, 06:59
Excellent news.

It also supports B frames, but the quality is poor according to Rigaya.

I would definitely like to see the encoding speed on a 1080p H.264 clip using a fast VCE engine like Tonga, Carrizo or Fiji AMD card.

dvd_maniac
24th September 2015, 14:33
I am having an issue where i input a video and the initial resize is screwed up and does not enforce the Resize slider width limit I set. It starts with the actual size of the video instead.
I have to manually move the resize slider back and forth for it to correct itself. This is not a huge problem except that I cannot use batch mode and most of my encoding used to be done automatically through batch files and scheduled tasks.
I have tried to just let it encode but the resize limit did not get enforced.