StaxRip x86 (development for x86 has been stopped) [Archive] - Page 99

View Full Version : StaxRip x86 (development for x86 has been stopped)

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

stax76

21st March 2015, 13:40

Seem like the resizer filter is using CPU. Is there any GPU based resizer? @stax76

This runs with 550 fps in avsmeter:

DGSource("%source_file%", deinterlace = 0, resize_w = 1280, resize_h = 720)

JohnLai

21st March 2015, 13:49

This runs with 550 fps in avsmeter:

DGSource("%source_file%", deinterlace = 0, resize_w = 1280, resize_h = 720)

Eh? I thought DGSource belongs to DGDecodeNV that required payment in order to use it?

EDIT:
Anyway, aside from resizer.....

Anyone notice rigaya nvencc got weird behavior? Note: I got a old 1280x720 XVID files decoded purely by Lavfilter in software mode (aka no dxva) with staxrip audio set to 'no audio' to eliminate any bottleneck by CPU (Core I5-3570K 4.2ghz overclocked). Look at scenario below :

Scenario 1
If I encode to HEVC using nvencc from XVID 720p to HEVC 720p at single instance of nvencc, I got 182fps.

Scenario 2
Similar to scenario 1, using the same XVID 720P, but this time, I make another copy and rename the same XVID video to TEST1.AVI and TEST2.AVI. When I re-encode TEST1 and TEST2 simultaneous together to HEVC using nvencc, I got 301fps reported for each of the staxrip windows and it did finish much more faster.

Originally, I thought it to be caused by nvidia power management. Thus I did set it to 'maximum performance' at nvidia control panel. However, running single instance of nvencc still resulted slow 182fps. Only running two instances of nvencc will result in 300+ fps for each of them.

klf

21st March 2015, 16:07

Hello

@Stax76

1.2.2.0 version work for me.

Thank you

NikosD

21st March 2015, 18:00

Originally, I thought it to be caused by nvidia power management. Thus I did set it to 'maximum performance' at nvidia control panel. However, running single instance of nvencc still resulted slow 182fps. Only running two instances of nvencc will result in 300+ fps for each of them.

I have done a lot of such tests in the past with QuickSync and HW transcoding.

You should monitor some parameters during your transcoding such as:

GPU clocks, GPU load, Video Engine Load and if there is a tool by Nvidia, the Video Encoding load.

There were situations during QuickSync transcoding with one file only, that various bottlenecks couldn't push the load at 100% to the transcoding engine, so a second process could be done in similar time like one process only.

But what you write is different because your second file pushed a lot both transcodings.

I would monitor GPU clocks and changed the input content to a different codec.

JohnLai

22nd March 2015, 09:29

@NikosD

I monitored the gpu parameters using GPUZ.

During single instance of nvencs, Video Engine has average utilization of 53%. GPU Load 3%.
When two instances of nvencs was started at same time, Video Engine utilization reached 96%-99%. GPU Load 6%.

For both scenarios, GPU core clock (1253 MHz) and GPU memory clock (1800MHz) at their maximum all the time during nvencc encoding.
Temperature for both scenario = 60' Celcius.

NikosD

22nd March 2015, 10:35

You said you decode XVID in software using LAV video, so I don't know the source of Video Engine Load of GPU-Z.

Maybe it shows not only HW decoding but HW encoding too.

It looks like that Video Engine is underutilised using one instance, but from 182 fps to 600+ fps the difference is more than 53% to 99%

Add a third process and look at the transcoding fps and the monitoring parameters.

JohnLai

22nd March 2015, 11:01

Strange thing is, rigaya also posted his/her nvencc hevc encoding. His/Her result for transcoding 720p to HEVC 720P also 300+ fps for single instance.
Though there is no info on what the original file is encoded with. The 'utvideo' probably refers to Ut Video Codec Suite. Hmm......the developer is using GTX970.

http://rigaya34589.blog135.fc2.com/blog-date-20150125.html#entry571aa

EDIT: Just click the " 続きを読む " to see the result.

EDIT2:
*solved the slow fps issue by taking apart the gpu and reinsert it + replugging the gpu power connector. I can get 300+fps at single nvencc instance now. Turn out the power connector wasn't plugged in properly >.< (how can I miss it?)

Anyway, there is no hardware/gpu accelerated resizer around other than 'shareware/payware' DGDecodeNV. The reason why handbrake can decode and encode to lower resolution video at high speed is due to usage of Quicksync VPP.
From handbrake log itself when downscaling using Quicksync :

+ decoder: h264_qsv
+ filter
+ Quick Sync Video VPP (848:478:0:0:0:0_dei:0)
+ source: 1280 * 720, crop (0/0/0/0): 1280 * 720, scale: 848 * 478

EDIT3: From what I can see from other users of DGDecodeNV, it appears this particular source filter will fill exactly my needs. Resizing video without severe performance penalty. Too bad it is a payware.

EDIT4:
I tried using _gpu25 (gpu25clone) using GPU_lanczosresize and GPU_bilinearresize modes, didnt make much difference in fps when downsizing from 1080 to 720.
Gpu utilization for using lanczos (17% average) and bilinear (9% average). Both resulted in 192fps. A slight increases in fps from 182fps. GPU_lanczosresize quality is quite acceptable. GPUZ Video Engine reports 53% for both mode >.<

Eureka! Found another plugin called "SimpleResize" at http://avisynth.nl/index.php/External_filters#Resizers. A simple CPU based resizer filter as its name implied. ^.^
I able to get 320fps transcoding HEVC 1080p to HEVC 720P using nvencc.
Resizing quality is a bit disappointing, but acceptable. Average CPU utilization is almost evenly spread across four cores (from windows task manager 50-56%). -.- Now I take a look again, only one core maxed for my core i5-3570k while the other three threads seems to be like around 15%-20%
GPUZ reports Video Engine utilization of 37% !!! Gpu utilization is merely averaging of 3%. Some correction edit

On the other hand....when I use SimpleResize plugin for my old PC Core 2 Quad Q8200 2.33ghz with GTX 960.......CPU utilization rate is nearly 100% with 220-222 fps. Ugh, SimpleResize got bottlenecked by old CPU. Probably due to nvencc overhead or dxva copy back overhead?

NikosD

23rd March 2015, 17:34

The reason why handbrake can decode and encode to lower resolution video at high speed is due to usage of Quicksync VPP.

Interesting, I hadn't done any scaling tests with HB and after my H.264 1080p -> 720p transcoding, I found out you 're right.

HB managed to do it in "Balanced" speed and CQP 23 at ~360fps

StaxRip on the other hand using QSVEncC and exactly same parameters, did the transcoding at a rate from 112 fps using difficult algorithms like Lanczos4, BlackMan, Gauss to ~163 fps using Bilinear.

Anyway, there is no hardware/gpu accelerated resizer around other than 'shareware/payware' DGDecodeNV

For us QuickSync users, QS supports the VPP of scaling/resizing so you don't have to look anywhere else.

There is an option inside QSVEncC called --output-res <int>x<int> which if it's different from input it uses vpp resizing

@Stax76

How could we ignore the resize filters and use QSVEncC for resizing ?

I did it in the console window and got ~273 fps using FFVideo and ~223 fps using DSS

JohnLai

24th March 2015, 04:16

Interesting, I hadn't done any scaling tests with HB and after my H.264 1080p -> 720p transcoding, I found out you 're right.

HB managed to do it in "Balanced" speed and CQP 23 at ~360fps

StaxRip on the other hand using QSVEncC and exactly same parameters, did the transcoding at a rate from 112 fps using difficult algorithms like Lanczos4, BlackMan, Gauss to ~163 fps using Bilinear.

For us QuickSync users, QS supports the VPP of scaling/resizing so you don't have to look anywhere else.

There is an option inside QSVEncC called --output-res <int>x<int> which if it's different from input it uses vpp resizing

@Stax76

How could we ignore the resize filters and use QSVEncC for resizing ?

I did it in the console window and got ~273 fps using FFVideo and ~223 fps using DSS

Try this.
Set Lavfilter to use "Intel Quicksync" at 'hardware acceleration'.
Then use Win7DSFilterTweaker_5.9 to set lavfilter as preferred directshow decoder for both x86 and x64.
At staxrip, for the 'Source' filter, change it to "DirectShow"

Finally, use the QSVEncC --output-res <int>x<int> that you mentioned through command line to transcode H264 1080 to H264 720. In theory, you ought to get 310+ fps (depending on your quicksync target usage and parameters) with very low cpu usage.

EDIT :
More info on how handbrake can turbo boost the transcoding.
It turns out handbrake also use hardware accelerated YV12 --> NV12 conversion
https://software.intel.com/en-us/articles/media-sdk-tutorial-tutorial-samples-index
Avisynth still use CPU AVX instruction set to do the color conversion from YV12-->NV12.
Another bottleneck at front-end.

No idea what form of resizing filter used by Intel Quicksync VPP. It is not mentioned at all. Probably bilinear or bicubic? Anyone know?
I read somewhere in madvr thread that intel was using bicubic filter for dxva scaling. Probably the same for encoding?
If you can get 360fps with the method I described above, good for you. Probably around 310fps due to avisynth cpu based color conversion during decoding. I am not certain if lavfilter in quicksync decoding mode will autoconvert to the surface format required by QSVEncC.

Meanwhile, I stuck with using "SimpleResize" cpu plugin for nvencc hevc encoding >.<

NikosD

24th March 2015, 05:14

I think you 've missed something.

The instructions you gave me are the same instructions that I gave to another member in a previous post in order to use LAV Video with DSS filter!

I've already done that in order to achieve 223 fps using DSS QS decoder and 273 fps using FFVideoSource, as I wrote in my previous post.

The problem I mentioned to Stax76 (Frank) is that I couldn't find a way to activate the resize feature of StaxRip without enabling one of the CPU based resizing filters.

So, all of my tests were done inside the console window of QSVEncC, as I wrote above.

JohnLai

24th March 2015, 06:41

Ah, pardon me, I did miss something. XD

Anyway, how does FFVideoSource (I presume ffmpeg?) decode faster than LAVvf Quicksync DSS? I know your CPU is considered top end model.

NikosD

24th March 2015, 07:23

QS decoder uses a copy-back mechanism, just like LAV DXVA copy-back decoder, just a little faster.

Only pure DXVA native decoding that HandBrake uses is faster than FFVideoSource on a CPU like Core i7 4790.

The advantage of QS decoder compared to FFVideo is low CPU utilisation, of course.

IbrahimKh

24th March 2015, 10:18

cant encode audio
please help
Audio
Format : DTS
Format/Info : Digital Theater Systems
Mode : 16
Format settings, Endianness : Big
Duration : 1h 54mn
Bit rate mode : Constant
Bit rate : 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 1.21 GiB (100%)

------------------------------------------------------------
Convert to WAV/FLAC using eac3to
------------------------------------------------------------

"C:\Users\Administrator\Desktop\New folder\Applications\eac3to\eac3to.exe" "C:\Users\Administrator\Desktop\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD temp files\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD - ID2 - English.dts" "C:\Users\Administrator\Desktop\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD temp files\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD - ID2 - English.wav" -down2 -simple -progressnumbers

DTS, 5.1 channels, 1:54:28, 1510kbps, 48kHz
The ArcSoft and Sonic decoders don't seem to work, will use libav instead.
Decoding with libav/ffmpeg...
Downmixing multi channel audio to stereo...
Reducing depth from 64 to 24 bits...
Writing WAV...
Creating file "C:\Users\Administrator\Desktop\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD temp files\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD - ID2 - English.wav"...
Clipping detected, a 2nd pass will be necessary.
Starting 2nd pass...
Decoding with libav/ffmpeg...
Downmixing multi channel audio to stereo...
Reducing depth from 64 to 24 bits...
Writing WAV...
Applying -2.61dB gain...
Creating file "C:\Users\Administrator\Desktop\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD temp files\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD - ID2 - English.wav"...
eac3to processing took 24 minutes, 55 seconds.
Done.

Start: 4:00:43 AM
End: 4:25:43 AM
Duration: 00:24:59

General
Complete name : C:\Users\Administrator\Desktop\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD temp files\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD - ID2 - English.wav
Format : Wave
File size : 1.84 GiB
Duration : 1h 54mn
Overall bit rate mode : Constant
Overall bit rate : 2 304 Kbps

Audio
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 1h 54mn
Bit rate mode : Constant
Bit rate : 2 304 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Stream size : 1.84 GiB (100%)

------------------------------------------------------------
Audio encoding using eac3to
------------------------------------------------------------

"C:\Users\Administrator\Desktop\New folder\Applications\eac3to\eac3to.exe" "C:\Users\Administrator\Desktop\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD temp files\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD - ID2 - English.wav" "C:\Users\Administrator\Desktop\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD temp files\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD - ID2 - English_out.m4a" -quality=0.35 -normalize -down16 -downStereo -progressnumbers

WAV, 2.0 channels, 1:54:28, 24 bits, 2304kbps, 48kHz
Reading WAV...
Reducing depth from 24 to 16 bits...
Writing WAV...
Creating file "C:\Users\Administrator\Desktop\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD temp files\Poltergeist.1982.BluRay.1080p.DTS.x264-CtrlHD - ID2 - English_out.m4a.pass1.wav"...
The original audio track has a constant bit depth of 24 bits.
The processed audio track has a constant bit depth of 16 bits.
Starting 2nd pass...
Reading WAV...
Reducing depth from 64 to 16 bits...
Encoding AAC <0.35> with NeroAacEnc...
Applying -0.001dB gain...
The processed audio track has a constant bit depth of 16 bits.
The Nero AAC encoder seems to be stuck...
NeroAacEnc Processed 0 seconds...
NeroAacEnc Processed 1 seconds...
NeroAacEnc Processed 2 seconds...
NeroAacEnc Processed 3 seconds...
NeroAacEnc Processed 4 seconds...
NeroAacEnc Processed 5 seconds...
NeroAacEnc Processed 6 seconds...
NeroAacEnc Processed 7 seconds...
NeroAacEnc Processed 8 seconds...
NeroAacEnc Processed 9 seconds...
NeroAacEnc Processed 10 seconds...
NeroAacEnc Processed 11 seconds...
NeroAacEnc Processed 12 seconds...
NeroAacEnc Processed 13 seconds...
NeroAacEnc Processed 14 seconds...
NeroAacEnc Processed 15 seconds...
NeroAacEnc Processed 16 seconds...
NeroAacEnc Processed 17 seconds...
NeroAacEnc Processed 18 seconds...
NeroAacEnc Processed 19 seconds...
NeroAacEnc Processed 20 seconds...
NeroAacEnc Processed 21 seconds...
NeroAacEnc Processed 22 seconds...
NeroAacEnc Processed 23 seconds...
NeroAacEnc Processed 24 seconds...
NeroAacEnc Processed 25 seconds...
NeroAacEnc Processed 26 seconds...
NeroAacEnc Processed 27 seconds...
NeroAacEnc Processed 28 seconds...
NeroAacEnc Processed 29 seconds...
NeroAacEnc Processed 30 seconds...
NeroAacEnc Processed 31 seconds...
NeroAacEnc Processed 32 seconds...
NeroAacEnc Processed 33 seconds...
NeroAacEnc Processed 34 seconds...
NeroAacEnc Processed 35 seconds...
NeroAacEnc Processed 36 seconds...
NeroAacEnc Processed 37 seconds...
NeroAacEnc Processed 38 seconds...
NeroAacEnc Processed 39 seconds...
NeroAacEnc Processed 40 seconds...
NeroAacEnc Processed 41 seconds...
NeroAacEnc Processed 42 seconds...
NeroAacEnc Processed 43 seconds...
NeroAacEnc Processed 44 seconds...
NeroAacEnc Processed 45 seconds...
NeroAacEnc Processed 46 seconds...
NeroAacEnc Processed 47 seconds...
NeroAacEnc Processed 48 seconds...
NeroAacEnc Processed 49 seconds...
NeroAacEnc Processed 50 seconds...
NeroAacEnc Processed 51 seconds...
NeroAacEnc Processed 52 seconds...
NeroAacEnc Processed 53 seconds...
NeroAacEnc Processed 54 seconds...
NeroAacEnc Processed 55 seconds...
NeroAacEnc Processed 56 seconds...
NeroAacEnc Processed 57 seconds...
NeroAacEnc Processed 58 seconds...
NeroAacEnc Processed 59 seconds...
NeroAacEnc Processed 60 seconds...
NeroAacEnc Processed 61 seconds...
NeroAacEnc Processed 62 seconds...
NeroAacEnc Processed 63 seconds...
NeroAacEnc Processed 64 seconds...
NeroAacEnc Processed 65 seconds...
NeroAacEnc Processed 66 seconds...
NeroAacEnc Processed 67 seconds...
NeroAacEnc Processed 68 seconds...
NeroAacEnc Processed 69 seconds...
NeroAacEnc Processed 70 seconds...
NeroAacEnc Processed 71 seconds...
NeroAacEnc Processed 72 seconds...
NeroAacEnc Processed 73 seconds...
NeroAacEnc Processed 74 seconds...
NeroAacEnc Processed 75 seconds...
NeroAacEnc Processed 76 seconds...
NeroAacEnc Processed 77 seconds...
NeroAacEnc Processed 78 seconds...
NeroAacEnc Processed 79 seconds...
NeroAacEnc Processed 80 seconds...
NeroAacEnc Processed 81 seconds...
NeroAacEnc Processed 82 seconds...
NeroAacEnc Processed 83 seconds...
NeroAacEnc Processed 84 seconds...
NeroAacEnc Processed 85 seconds...
NeroAacEnc Processed 86 seconds...
NeroAacEnc Processed 87 seconds...
NeroAacEnc Processed 88 seconds...
NeroAacEnc Processed 89 seconds...
NeroAacEnc Processed 90 seconds...
NeroAacEnc Processed 91 seconds...
NeroAacEnc Processed 92 seconds...
NeroAacEnc Processed 93 seconds...
NeroAacEnc Processed 94 seconds...
NeroAacEnc Processed 95 seconds...
NeroAacEnc Processed 96 seconds...
NeroAacEnc Processed 97 seconds...
NeroAacEnc Processed 98 seconds...
NeroAacEnc Processed 99 seconds...
NeroAacEnc Processed 100 seconds...
NeroAacEnc Processed 101 seconds...
NeroAacEnc Processed 102 seconds...
NeroAacEnc Processed 103 seconds...
NeroAacEnc Processed 104 seconds...
NeroAacEnc Processed 105 seconds...
NeroAacEnc Processed 106 seconds...
NeroAacEnc Processed 107 seconds...
NeroAacEnc Processed 108 seconds...
NeroAacEnc Processed 109 seconds...
NeroAacEnc Processed 110 seconds...
NeroAacEnc Processed 111 seconds...
NeroAacEnc Processed 112 seconds...
NeroAacEnc Processed 113 seconds...
NeroAacEnc Processed 114 seconds...
NeroAacEnc Processed 115 seconds...
NeroAacEnc Processed 116 seconds...
NeroAacEnc Processed 117 seconds...
NeroAacEnc Processed 118 seconds...
NeroAacEnc Processed 119 seconds...
NeroAacEnc Processed 120 seconds...
NeroAacEnc Processed 121 seconds...
NeroAacEnc Processed 122 seconds...
NeroAacEnc Processed 123 seconds...
NeroAacEnc Processed 124 seconds...
NeroAacEnc Processed 125 seconds...
NeroAacEnc Processed 126 seconds...
NeroAacEnc Processed 127 seconds...
NeroAacEnc Processed 128 seconds...
NeroAacEnc Processed 129 seconds...
NeroAacEnc Processed 130 seconds...
NeroAacEnc Processed 131 seconds...
NeroAacEnc Processed 132 seconds...
NeroAacEnc Processed 133 seconds...
NeroAacEnc Processed 134 seconds...
NeroAacEnc Processed 135 seconds...
NeroAacEnc Processed 136 seconds...
NeroAacEnc Processed 137 seconds...
NeroAacEnc Processed 138 seconds...
NeroAacEnc Processed 139 seconds...
NeroAacEnc Processed 140 seconds...
NeroAacEnc Processed 141 seconds...
NeroAacEnc Processed 142 seconds...
NeroAacEnc Processed 143 seconds...
NeroAacEnc Processed 144 seconds...
NeroAacEnc Processed 145 seconds...
NeroAacEnc Processed 146 seconds...
NeroAacEnc Processed 147 seconds...
NeroAacEnc Processed 148 seconds...
NeroAacEnc Processed 149 seconds...
NeroAacEnc Processed 150 seconds...
NeroAacEnc Processed 151 seconds...
NeroAacEnc Processed 152 seconds...
NeroAacEnc Processed 153 seconds...
NeroAacEnc Processed 154 seconds...
NeroAacEnc Processed 155 seconds...
NeroAacEnc Processed 156 seconds...
NeroAacEnc Processed 157 seconds...
NeroAacEnc Processed 158 seconds...
NeroAacEnc Processed 159 seconds...
NeroAacEnc Processed 160 seconds...
NeroAacEnc Processed 161 seconds...
NeroAacEnc Processed 162 seconds...
NeroAacEnc Processed 163 seconds...
NeroAacEnc Processed 164 seconds...
NeroAacEnc Processed 165 seconds...
NeroAacEnc Processed 166 seconds...
NeroAacEnc Processed 167 seconds...
NeroAacEnc Processed 168 seconds...
NeroAacEnc Processed 169 seconds...
NeroAacEnc Processed 170 seconds...
NeroAacEnc Processed 171 seconds...
NeroAacEnc Processed 172 seconds...
NeroAacEnc Processed 173 seconds...
NeroAacEnc Processed 174 seconds...
NeroAacEnc Processed 175 seconds...
NeroAacEnc Processed 176 seconds...
NeroAacEnc Processed 177 seconds...
NeroAacEnc Processed 178 seconds...
NeroAacEnc Processed 179 seconds...
NeroAacEnc Processed 180 seconds...
NeroAacEnc Processed 181 seconds...
NeroAacEnc Processed 182 seconds...
NeroAacEnc Processed 183 seconds...
NeroAacEnc Processed 184 seconds...
NeroAacEnc Processed 185 seconds...
NeroAacEnc Processed 186 seconds...
NeroAacEnc Processed 187 seconds...
NeroAacEnc Processed 188 seconds...
NeroAacEnc Processed 189 seconds...
NeroAacEnc Processed 190 seconds...
NeroAacEnc Processed 191 seconds...
NeroAacEnc Processed 192 seconds...
NeroAacEnc Processed 193 seconds...
NeroAacEnc Processed 194 seconds...
NeroAacEnc Processed 195 seconds...
NeroAacEnc Processed 196 seconds...
NeroAacEnc Processed 197 seconds...
NeroAacEnc Processed 198 seconds...
NeroAacEnc Processed 199 seconds...
NeroAacEnc Processed 200 seconds...
NeroAacEnc Processed 201 seconds...
NeroAacEnc Processed 202 seconds...
NeroAacEnc Processed 203 seconds...
NeroAacEnc Processed 204 seconds...
NeroAacEnc Processed 205 seconds...
NeroAacEnc Processed 206 seconds...
NeroAacEnc Processed 207 seconds...
NeroAacEnc Processed 208 seconds...
NeroAacEnc Processed 209 seconds...
NeroAacEnc Processed 210 seconds...
NeroAacEnc Processed 211 seconds...
NeroAacEnc Processed 212 seconds...
NeroAacEnc Processed 213 seconds...
NeroAacEnc Processed 214 seconds...
NeroAacEnc Processed 215 seconds...
NeroAacEnc Processed 216 seconds...
NeroAacEnc Processed 217 seconds...
NeroAacEnc Processed 218 seconds...
NeroAacEnc Processed 219 seconds...
NeroAacEnc Processed 220 seconds...
NeroAacEnc Processed 221 seconds...
NeroAacEnc Processed 222 seconds...
NeroAacEnc Processed 223 seconds...
NeroAacEnc Processed 224 seconds...
NeroAacEnc Processed 225 seconds...
NeroAacEnc Processed 226 seconds...
NeroAacEnc Processed 227 seconds...
NeroAacEnc Processed 228 seconds...
NeroAacEnc Processed 229 seconds...
NeroAacEnc Processed 230 seconds...
NeroAacEnc Processed 231 seconds...
NeroAacEnc Processed 232 seconds...
NeroAacEnc Processed 233 seconds...
NeroAacEnc Processed 234 seconds...
NeroAacEnc Processed 235 seconds...
NeroAacEnc Processed 236 seconds...
NeroAacEnc Processed 237 seconds...
NeroAacEnc Processed 238 seconds...
NeroAacEnc Processed 239 seconds...
NeroAacEnc Processed 240 seconds...
NeroAacEnc Processed 241 seconds...
NeroAacEnc Processed 242 seconds...
NeroAacEnc Processed 243 seconds...
NeroAacEnc Processed 244 seconds...
NeroAacEnc Processed 245 seconds...
NeroAacEnc Processed 246 seconds...
NeroAacEnc Processed 247 seconds...
NeroAacEnc Processed 248 seconds...
NeroAacEnc Processed 249 seconds...
NeroAacEnc Processed 250 seconds...
NeroAacEnc Processed 251 seconds...
NeroAacEnc Processed 252 seconds...
NeroAacEnc Processed 253 seconds...
NeroAacEnc Processed 254 seconds...

Start: 4:25:43 AM
End: 4:44:25 AM
Duration: 00:18:42

------------------------------------------------------------
Error
------------------------------------------------------------

no output found

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

Patman

25th March 2015, 13:50

Hi Stax,

for the x264 encoding process are some options to tune/ to customize the profile. In tab "rate control" can be selected aq mode 0 (disabled), aq mode 1 (variance) and aq mode 2 (auto-variance). Since december 2014 there is the option to select aq mode 3 (auto-variance with bias to dark scenes). Please expand the selection and add aq mode 3. Release 1.2.2.0 works very well!!!

stax76

30th March 2015, 10:09

1.2.2.1 beta (2015-03-30)

Added GUI for NVEncC (tool for NVIDIA H.264/H.265 GPU encoding)
Added GUI for QSVEncC (tool for Intel Quick Sync H.264 GPU encoding)
Added x265 option --pools
Added x265 option --frame-threads
Added x265 option --min-cu-size
Added x265 option --log-level frame and updated help for --log-level
Added x264 option --aq-mode 3 (Auto-variance AQ with bias to dark scenes)
Fixed video stream of audio source being muxed into MP4
Reverted to old shutdown method due to bug report
Updated mkvtoolnix version 7.8.0 (River Man) supporting DTS Express
Updated eac3to to version 3.29 supporting DTS-HD decoding
Updated ffmpeg supporting DTS-HD decoding
Updated x265 to version 1.5+370
Updated QSVEncC (tool for Intel H.264 GPU encoding) to version 1.32

http://sourceforge.net/projects/staxmedia/files/StaxRip%20beta/StaxRip_1.2.2.1_beta.7z/download

Anybody using the Intel encoder should press F1 in the options dialog, it queries useful info from QSVEncC which takes time but when it finally shows up you won't be disappointed, I promise!

@IbrahimKh

Is the nero encoder in the eac3to directory? You could use qaac.

Alexander

31st March 2015, 13:37

Hello

@Stax76

Version 1.2.2.1 beta

Shutdown fails, the user is only logged out.

Win 7 64bit.

kevbo

31st March 2015, 20:11

I'm having trouble with both 1.2.2.0 and 1.2.2.1. Here's my "normal" workflow:

I end up with the streams of a movie as separate files. I drag the .h264 file into StaxRip, where it would immediately start to index it. When that's done, I'd drag the audio in, and set up the subtitles.

With these new versions, when I drag the .h264 file in, StaxRip becomes unresponsive. Task Manager shows lots of I/O Reads. I used ProcessMonitor and it appears that StaxRip.exe itself is reading through the entire .h264 file. If I wait long enough, the GUI will return.

However, at random times (loading a saved project, starting a batch, heck, even sliding the "resize" slider), it will lock up again, and appear to start reading through the .h264 file again.

Any ideas?

Edit:
Note, I have to think that something is weird here, because if others were seeing this behavior, it would already have been reported. I just can't figure out what it would be.

Windows 7 64-bit
32GB RAM
i7-4790K

stax76

31st March 2015, 21:48

Hello

@Stax76

Version 1.2.2.1 beta

Shutdown fails, the user is only logged out.

Win 7 64bit.

I've uploaded a pre-release fixing this:

https://www.dropbox.com/sh/xiyz10pghli8pvf/AAB3k0Dg-TRF-vh6srbITYDBa?dl=0

@kevbo

Currently there is no filter included that can handle elementary streams, how did you get a elementary stream? When I removed DGAVCDec I didn't know there is no other filter that can handle elementary streams, maybe I add DGAVCDec again. If you want to become a certified StaxRip professional you could integrate DGDecNV, it does elementary streams and transport streams better then any other tool, DGAVCDec integration should also be possible.

@all

source code from now on is on github:

https://github.com/stax76/staxrip

I'm just learning using git.

pre-releases are from now on available under this URL:

https://www.dropbox.com/sh/xiyz10pghli8pvf/AAB3k0Dg-TRF-vh6srbITYDBa?dl=0

changes since the last beta are minor:

Improved ffmpeg video encoding, VP9 two pass still don't work, apparently bug in libvpx 1.3
Improved GUI for QSVEncC (tool for Intel Quick Sync H.264 GPU encoding)
Fixed help browser not using word wrap
Fixed shutdown not working

kevbo

31st March 2015, 22:16

Oh...that's interesting.

I end up with the raw streams from the output of eac3to when I grab them off of a disc.

Maybe my workflow is broken. I'm OK if that's the case. I've been doing this this way a long time.

stax76

31st March 2015, 22:19

You can also choose mkv output (which is the default) in the eac3to dialog, by default StaxRip opens MKV then with ffms2/FFVideoSource.

kevbo

31st March 2015, 22:29

I've been using Clown BD as my front end to eac3to. It doesn't appear to have an .mkv option. It has a tsmuxer option, but I didn't think that could handle all of the stream types, and it seemed silly to remux a bunch of things that I'll end up needing separate anyways, so I didn't bother.

I'll look into other options, now that I know what the issue is.

Thanks, and thanks for StaxRip. It has done a lot of work for me over the years.

Kevin

stax76

31st March 2015, 23:14

You could try StaxRip's eac3to dialog, it has improved a lot this year, I don't know how it compares to Clown BD which won't start due to Java detection being broke, my Java detection works so I posted my code to their support forum.

kevbo

1st April 2015, 00:00

Great, thanks!

burfadel

2nd April 2015, 06:34

In the x265 options, if you enable the noise reduction, only the --nr-intra setting is set, but there is also a --nr-inter setting. There should be separate options for the two.

Also, in the help it says the --psy-rdoq default is 0.00 (basically it's disabled), however in the x265 settings page in Staxrip it has it as 1.00, which it thinks is the default. Also, this setting has no effect when RDOQ level is at the default of 0.

I also have an idea for the --me-range option. Realistically this idea should apply to x265 itself, but it can also apply to Staxrip. Basically, the default setting is 57, which makes x265 quite slow. This default setting seems to be with ultra high definition content in mind, if you are encoding lower resolution material this setting actually becomes 'stronger', since the range is greater with a lower resolution. Having an option for 'auto', with a metric based on the quality settings would be handy. For example, if you are encoding 720P stuff, a value of 24 really gives you the same results with a massive speedup. In fact, you can set some other settings to a higher value which results in better quality and efficiency and still be massively faster than at 57. It should probably scale at the standard preset from say, 16 at <480P, to 24 to 1080P, and then scale it up to 57 for high resolutions. Just an idea :).

alrmothe

2nd April 2015, 19:43

I downloaded StaxRip 1.2.2.0 and StaxRip 1.2.2.1 beta

But I have a problem

http://i.imgur.com/CRXqHCf.jpg

ShamisOMally

2nd April 2015, 20:41

I'm getting zero difference with H265 Nvenc encoder with Staxrip setting any amount of B-Frames or Reference frames using my Nvidia 980 GTX

dejong12

2nd April 2015, 21:34

Stax, I've downloaded the latest version of StaxRip which you uploaded three hours ago on DropBox. Could you add a changelog to the 7z file? I'm curious in the changes you've made.

stax76

2nd April 2015, 22:18

@burfadel

I'll look into this, thanks.

@alrmothe

Maybe you don't have .NET 4.5.2 or there is a problem with old settings. You can try to delete the settings, do you know where they are stored? You can find the location here:

HKEY_CURRENT_USER\Software\StaxRip

or when you still can start a version you can go to the main menu at Tools/Directories/Settings

I'm getting zero difference with H265 Nvenc encoder with Staxrip setting any amount of B-Frames or Reference frames using my Nvidia 980 GTX

Does the nvencc output state anything related this options, can post the output?

Stax, I've downloaded the latest version of StaxRip which you uploaded three hours ago on DropBox. Could you add a changelog to the 7z file? I'm curious in the changes you've made.

My release process is automated with a script, the script, copies the two files, packs them with 7z and moves the archive to my dropbox folder, the changelog is VB.NET code which generates HTML dynamically, without making some change I can not access the changelog from script so you have to run StaxRip if you want to see the changelog.

dejong12

2nd April 2015, 23:21

My release process is automated with a script, the script, copies the two files, packs them with 7z and moves the archive to my dropbox folder, the changelog is VB.NET code which generates HTML dynamically, without making some change I can not access the changelog from script so you have to run StaxRip if you want to see the changelog.
Ah, I forgot that StaxRip includes a changelog. Thanks for reminding me. :)

I love how you incorporated NVEncC into StaxRip. It's the only thing I use now because it speeds up my encoding times a lot.

stax76

3rd April 2015, 18:32

In the x265 options, if you enable the noise reduction, only the --nr-intra setting is set, but there is also a --nr-inter setting. There should be separate options for the two.

Added, please tell me if you find something else missing.

Also, in the help it says the --psy-rdoq default is 0.00 (basically it's disabled), however in the x265 settings page in Staxrip it has it as 1.00, which it thinks is the default.

The official help page says it's 1

http://x265.readthedocs.org/en/latest/cli.html#cmdoption--psy-rdoq

Also, this setting has no effect when RDOQ level is at the default of 0.

I don't think some action is necessary here.

I also have an idea for the --me-range option. Realistically this idea should apply to x265 itself, but it can also apply to Staxrip. Basically, the default setting is 57, which makes x265 quite slow. This default setting seems to be with ultra high definition content in mind, if you are encoding lower resolution material this setting actually becomes 'stronger', since the range is greater with a lower resolution. Having an option for 'auto', with a metric based on the quality settings would be handy. For example, if you are encoding 720P stuff, a value of 24 really gives you the same results with a massive speedup. In fact, you can set some other settings to a higher value which results in better quality and efficiency and still be massively faster than at 57. It should probably scale at the standard preset from say, 16 at <480P, to 24 to 1080P, and then scale it up to 57 for high resolutions. Just an idea :).

I made it auto for 0.

Here is a pre-release you can use on top of the last beta:

https://www.dropbox.com/sh/xiyz10pghli8pvf/AAB3k0Dg-TRF-vh6srbITYDBa?dl=0

As far as I know x265 is now up to date.

burfadel

4th April 2015, 05:08

Thanks, just did a quick test and it seems to work great :)

dirk362

4th April 2015, 11:46

Feature Request: Can we have x265 profile load/save, as we have with others such as x264 (found under options when in Video Encoder settings)
Will allow settings to be exported to other machines, and as a backup.

stax76

4th April 2015, 11:57

@dirk362

I'll investigate it, maybe it's easy to add, meanwhile you can open the profiles editor from the menu in the main dialog, maybe you missed this way.

Dust Signs

4th April 2015, 16:57

Hi,

I noticed a really strange bug since upgrading to version(s) 1.2.* (non-beta as well as beta). When muxing SRT subtitles to MP4 (regardless of the used video/audio formats), the time code of the last subtitle is incorrect in the final file. To be more precise, when demuxing the MP4 file, the end time code of the last subtitle turns out to be the same as the end time code of the second-to-last subtitle (making the duration of the last subtitle negative). During playback (in MPC HC) this means that the last subtitle is shown from its start until the end of the video, which is quite irritating.
I don't know whether this is a problem with MP4Box or the way the new Staxrip version is invoking MP4Box. This problem did not show with older versions (I verified it with 1.7.*, which definitively use an older MP4Box version).

Dust Signs

stax76

4th April 2015, 18:26

Hi,

you could have just tried replacing the new mp4box version with the old one. ;)

Dust Signs

4th April 2015, 19:37

@stax76: Right, so it's definitively an MP4Box bug.

Dust Signs

stax76

4th April 2015, 19:43

You could try making a bug report here:

https://github.com/gpac/gpac/issues

Dust Signs

4th April 2015, 20:17

I just did. I'll keep you posted so StaxRip can be shipped with a fixed version as soon as it is available.

Dust Signs

mcgills

4th April 2015, 20:56

I got this problem from version 1.2.0.1 , .2 , .4 and .5 (when the video time is about an hour or more)
I didn't know what is that, but I hope this would not exist
on the latest version. Yes I'm too late to post this problem
but I'm still thinking that it would help to minimize further issue.
http://fs2.directupload.net/images/150404/ww8lp7mw.jpg

Patman

6th April 2015, 11:50

Hi Stax,

where staxrip gets the info for subtitles?
This option:

http://s10.postimg.org/8uel0q1mt/Subs.jpg (http://postimg.org/image/8uel0q1mt/)

doesn't work. Staxrip loads all subtitles and not only the listed ones.

stax76

6th April 2015, 14:27

Patman

6th April 2015, 15:00

stax76

6th April 2015, 15:44

It's a bit complicated as .NET knows neither ger or gez (StaxRip does some mapping here), making a change here would involve some research.

Bob.Dig

6th April 2015, 16:55

Hi stax, I have the following problem, which earlier was still, after cutting it gives an error message for the audio encoding and DVB-C HDTV recordings are completely green after encoding and async ...

Hi stax, ich hab folgendes Problem, was früher noch ging, nach dem Schneiden gibt es eine Fehlermeldung für das Audio encoding und DVB-C HDTV Aufnahmen sind nach dem encoding komplett grün und async, mit mpg geht es...

stax76

6th April 2015, 17:19

Hi, please mail me log file, regarding async, did StaxRip ask to install Haali Splitter?

mcgills

8th April 2015, 09:58

@mcgills

On ErrorAbortException it should ask to mail me the log file.

@Patman

I tried it with mkv source with and without demuxing using your pattern and it worked every time.

It checks against two letter codes and 'all', everything else gets ignored.

Hi stax76 thanks for your quick reply.

I didn't have a test already on 1.2.2.2 using x265
but I have encounter another issue using vp9.

Here's the log.. (sorry if I made a mistake I don't know if it is right to post this log like this):scared:

------------------------------------------------------------
Environment
------------------------------------------------------------

StaxRip version : 1.2.2.2
OS Name : Windows 7 Professional
OS Type : 64-bit
OS Culture : Filipino (Philippines)
LAV Filters :
AviSynth : AviSynth 2.5

------------------------------------------------------------
.NET
------------------------------------------------------------

v2.0.50727 : 2.0.50727.5420
v3.0 : 3.0.30729.5420
v3.5 : 3.5.30729.5420
v4\Client : 4.5.50938
v4\Full : 4.5.50938
v4.0\Client : 4.0.0.0

------------------------------------------------------------
Source file MediaInfo
------------------------------------------------------------

C:\Users\mcgills\Desktop\Chicken Embryo Development.mp4

General
Complete name : C:\Users\mcgills\Desktop\Chicken Embryo Development.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 18.8 MiB
Duration : 2mn 8s
Overall bit rate mode : Variable
Overall bit rate : 1 232 Kbps
Encoded date : UTC 2014-04-26 21:32:04
Tagged date : UTC 2014-04-26 21:32:04
gsst : 0
gstd : 128080
gssd : B7A0299C5HH1428435194276056
gshh : r1---sn-2aqu-hoae7.googlevideo.com

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 1 frame
Format settings, GOP : M=1, N=60
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 8s
Bit rate : 1 038 Kbps
Maximum bit rate : 2 932 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.047
Stream size : 15.8 MiB (84%)
Tagged date : UTC 2014-04-26 21:32:05

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 2mn 8s
Bit rate mode : Variable
Bit rate : 192 Kbps
Maximum bit rate : 205 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 2.93 MiB (16%)
Title : IsoMedia File Produced by Google, 5-11-2011
Encoded date : UTC 2014-04-26 21:32:05
Tagged date : UTC 2014-04-26 21:32:05

------------------------------------------------------------
AviSynth Filters
------------------------------------------------------------

FFVideoSource("C:\Users\mcgills\Desktop\Chicken Embryo Development.mp4", cachefile = "C:\Users\mcgills\Desktop\Chicken Embryo Development temp files\Chicken Embryo Development.ffindex")
AssumeFPS(24.000000)

------------------------------------------------------------
AviSynth Properties
------------------------------------------------------------

source frame count : 3072
source frame rate : 24.000000
source duration : 00:02:08
target frame count : 3072
target frame rate : 24.000000
target duration : 00:02:08

------------------------------------------------------------
Encoding VP9 using ffmpeg
------------------------------------------------------------

"D:\Program Files\StaxRip_1.2.2.1_beta\Applications\ffmpeg\ffmpeg.exe" -i "C:\Users\mcgills\Desktop\Chicken Embryo Development temp files\Chicken Embryo Development.avs" -c:v libvpx-vp9 -speed 2 -lag-in-frames 25 -crf 30 -b:v 0 -y "C:\Users\mcgills\Desktop\Chicken Embryo Development.webm"

ffmpeg version N-71120-g56b7aa2 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enable-zlib
libavutil 54. 20.101 / 54. 20.101
libavcodec 56. 31.100 / 56. 31.100
libavformat 56. 26.101 / 56. 26.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 13.101 / 5. 13.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
C:\Users\mcgills\Desktop\Chicken Embryo Development temp files\Chicken Embryo Development.avs: Unknown error occurred

------------------------------------------------------------
Error Encoding VP9 using ffmpeg
------------------------------------------------------------

Encoding VP9 using ffmpeg failed with exit code 1

ffmpeg version N-71120-g56b7aa2 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enable-zlib
libavutil 54. 20.101 / 54. 20.101
libavcodec 56. 31.100 / 56. 31.100
libavformat 56. 26.101 / 56. 26.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 13.101 / 5. 13.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
C:\Users\mcgills\Desktop\Chicken Embryo Development temp files\Chicken Embryo Development.avs: Unknown error occurred

Start: 4:38:41 PM
End: 4:38:41 PM
Duration: 00:00:00

stax76

8th April 2015, 12:20

mcgills

8th April 2015, 14:15

Bob.Dig

8th April 2015, 19:47

Hi, please mail me log file, regarding async, did StaxRip ask to install Haali Splitter?
Thanks again for your support. :D

ShamisOMally

9th April 2015, 07:58

VP9 is totally poor documented and has completely hard to use CLI options, I'm *EXTREMELY* disappointed from it, almost as much as from mp4box.

I'll switch from ffmpeg to vpxenc which is slightly better documented and available with newer library version, I hope I'll get it out within 1-2 weeks.

VP9 is amazing, but its encoder is probably the most broken thing I've ever used. The format itself is amazing, but its encoder literally sits around and does nothing all day long.

I can encode a 1 min x265 clip with 16 reference frames, 5 B-frames etc on highest settings in 6 minutes, the same clip running through VP9 encoder set to "Best" and 16 ref frames takes, I kid you not, SEVEN HOURS to process

EDIT: I have to say these random questions whenever I want to make a post is probably the most irritating thing I could possibly think of ever being added to a forum