StaxRip

[burfadel]

Any reason for there being the nnedi3.dll (the 10 May 2015 update) and _nnedi3.dll (01 December 2013) files?

[stax76]

Just forgot to remove it, thanks.

[videoh]

DGDecode does not work on Win10 That's hard to believe. Can you please tell us specifically what is not working for you?

[stax76]

That's hard to believe. Can you please tell us specifically what is not working for you?

StaxRip is now x64 only, if I remember right then DGDecode x64 ported by JoshyD worked on Win7 but on Win10 it's not working at all.

DGDecIM x64 is currently also not working with StaxRip, it's the same or similar problem as DGDecNV x64 had I would guess.

[videoh]

Ah, the 64-bit hacked one, OK. Thanks for the clarification.

I will fix DGDecIM right now and upload it. Thanks for pointing it out.

[videoh]

OK, please re-download DGDecIM b50. It has the same fix as we made for DGDecNV. Thank you for your testing.

[stax76]

Ah, the 64-bit hacked one, OK. Thanks for the clarification.

I will fix DGDecIM right now and upload it. Thanks for pointing it out.

Thanks for reading here and fixing it.

edit:

it works!

[detmek]

Hi Stax. I tried a few things with this pre-release and it works.
I encoded movie with x264 and just mux audio and worked (MKV to MKV).
QSVEncC supports cutting and resizing. I tried to manually enter cropping values as my test clip didn't need any cropping but nothing was passed to QSVEncC.

[stax76]

Hi, the whole QSVEncC change I made was like ten lines very simple code:

https://github.com/stax76/staxrip/blob/master/General/VideoEncoder.vb#L1371

I could not get it working so I thought maybe it's a Win10 only problem, I had also problems to create a fake monitor connection on Win10, on Win7 I had never problems with it, unfortunately I have quite many small issues on Win10, with Visual Studio 2015 RC I have no issues at all.

The generated command line looked good, it can be seen in the config dialog or log file. It adds the crop values from the cropping dialog and the trim values from the preview dialog.

[detmek]

For some reason encoder show error if I use QSV decoding and cropping. If I turn of QSV decoding it works but trimming can not be used.
Here is a log file:
MARINA VISKOVIC - GDE SAM GRESILA_StaxRip.log (http://www.4shared.com/file/MIot-bWlce/MARINA_VISKOVIC_-_GDE_SAM_GRES.html)

[stax76]

For some reason encoder show error if I use QSV decoding and cropping. If I turn of QSV decoding it works but trimming can not be used.
Here is a log file:
MARINA VISKOVIC - GDE SAM GRESILA_StaxRip.log (http://www.4shared.com/file/MIot-bWlce/MARINA_VISKOVIC_-_GDE_SAM_GRES.html)

I couldn't manage to download from 4shared, for log files there is nothing better then pastebin with auto expire. ;)

Unfortunately I already found the first problem, crop and trim should only be applied when hardware decoding is used, I upload a new build tomorrow.

edit:

fixed build using crop and trim only when hardware decoding is used:

http://www.mediafire.com/download/g8ijb2y2adxln12/StaxRip_QSVEncC_fix.7z

[detmek]

Still error:

https://www.dropbox.com/s/pzdnzatsaz84hw7/MARINA%20VISKOVIC%20-%20GDE%20SAM%20GRESILA_StaxRip.log?dl=0

Does Dropbox works?

[stax76]

DropBox is great (with large traffic they lock files quickly though). The command line looks good except -sar is used even when resizing is enabled, this should be a bug. I had the same error and don't really know what's wrong but we'll find out.

[dejong12]

With 1.3.1.0 and 1.3.1.1 the encoding speed with NVEnc drops to ~30fps with TDeint enabled. Version 1.2.2.2 with Yadif keeps the speed at around ~105fps while both versions have ~135fps without a deinterlace filter. All other settings are the same on both versions. Any reason why the x64 versions have such low encoding speeds? Indexing also takes three times longer on the x64 than on the x32 version too. The video is a 1080i AVC TV recording in MKV format.

[detmek]

It seams that it won't work only when crop is used. Maybe my CPU does not support crop?

P.S. I switched OS to Windows 7 SP1 due to a problems with WiFi adapter. Crop won't work even under Win 7.

[stax76]

With 1.3.1.0 and 1.3.1.1 the encoding speed with NVEnc drops to ~30fps with TDeint enabled.

Did you try to investigate it with AVSMeter? You can find AVSMeter at Tools/Advanced/AVSMeter. You could also try DSS2 using LAV Filters which you can configure at Tools/Advanced/LAV Filters config, Nikos reported that deinterlacing works with it. Overall I think there are quite a few options for deinterlacing.

Indexing also takes three times longer on the x64 than on the x32 version too. The video is a 1080i AVC TV recording in MKV format.

you mean ffms2? You can compare the ffms2 indexing speed against l-smash-works, it depends also on the source, there are differences. Can you record directly as MKV? I never knew a software that can do it.

It seams that it won't work only when crop is used. Maybe my CPU does not support crop?

P.S. I switched OS to Windows 7 SP1 due to a problems with WiFi adapter. Crop won't work even under Win 7.

What CPU do you use? I'll try it with my Ivy Bridge CPU.

[detmek]

Intel Pentium G3220 Haswell.

[dejong12]

Did you try to investigate it with AVSMeter? You can find AVSMeter at Tools/Advanced/AVSMeter. You could also try DSS2 using LAV Filters which you can configure at Tools/Advanced/LAV Filters config, Nikos reported that deinterlacing works with it. Overall I think there are quite a few options for deinterlacing.

This is being outputted with TDeint enabled in 1.3.1.1.
D:\StaxRip 1.3.1.1>"D:\StaxRip 1.3.1.1\Tools\AVSMeter\AVSMeter64.exe" "D:\Record
ed TV\Korra S4 FHD\De Legende van Korra - S04E01 temp files\De Legende van Korra
- S04E01_new.avs"

AVSMeter 2.0.2 (x64)
AviSynth+ 0.1 (r1825, MT, x86_64) (0.1.0.0)

Number of frames: 33247
Length (hh:mm:ss.ms): 00:22:09.880
Frame width: 1280
Frame height: 720
Framerate: 25.000 (25/1)
Colorspace: YV12

Frame (current | last): 7137 | 33246
FPS (cur | min | max | avg): 26.78 | 13.70 | 41.64 | 32.40
Memory usage (phys | virt): 114 | 117 MB
Thread count: 9
CPU usage (current | average): 35% | 35%

Time (elapsed | estimated): 00:03:40.312 | 00:17:06.157

Press 'Esc' to cancel the process...

And this is being outputted with Yadif enabled in 1.2.2.2.
D:\StaxRip 1.2.2.2 beta>"D:\StaxRip 1.2.2.2 beta\Tools\AVSMeter\AVSMeter64.exe" "D:\Record
ed TV\Korra S4 FHD\De Legende van Korra - S04E01 temp files\De Legende van Korra
- S04E01_new.avs"

AVSMeter 1.9.8.0 (x86)
AviSynth+ 0.1 (r1825, MT, i386) (0.1.0.0)

Number of frames: 33247
Length (hh:mm:ss.ms): 00:22:09.880
Frame width: 1280
Frame height: 720
Framerate: 25.000 (25/1)
Colorspace: YV12

Frame (current | last): 15099 | 33246
FPS (cur | min | max | avg): 112.0 | 65.88 | 118.1 | 101.4
Memory usage (phys | virt): 91 | 89 MB
Thread count: 9
CPU usage (current | average): 58% | 56%

Time (elapsed | estimated): 00:02:28.858 | 00:05:27.753

Press 'Esc' to cancel the process...


you mean ffms2? You can compare the ffms2 indexing speed against l-smash-works, it depends also on the source, there are differences. Can you record directly as MKV? I never knew a software that can do it.
Yeah with ffms2, but it's faster than I initially said, but a second slower than 1.2.2.2.

I can only record in .wtv because I use Windows Media Center and I haven't found a suitable successor yet. I use VideoRedo to cut out the commercials and save the resulting video in .mkv without recoding.

[stax76]

@detmek

Rigaya replied that it’s a bug of QSVEncC

@dejong12

It seems TDeint is rather slow, you could try Yadif with DSS2.

[detmek]

Thanks. So, we are waiting for a new version.

[NikosD]

A lot of fixes in latest β3 QSVEncC update, among them the crop issue:
http://rigaya34589.blog135.fc2.com/blog-entry-623.html

[Washka]

A lot of fixes in latest β3 QSVEncC update, among them the crop issue:
http://rigaya34589.blog135.fc2.com/blog-entry-623.html

Testing :)

[luigizaninoni]

Made some more tests on Staxrip 64 bit. In my opinion there are a few important issues:

For the following tests the configuration is: StaxRip x64 pre-release or Staxrip x32 1.2.2.0 - i7-4770S – x265 slow preset – Encode clip 1h 41m (same clip used throughout the tests)

Script:
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\ffms2\ffms2.dll")
Import("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\QTGMC\QTGMC.avsi")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\masktools2\masktools2.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\mvtools2\mvtools2.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\nnedi3\nnedi3.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\RgTools\RgTools.dll")
FFVideoSource("C:\Users\luigi.TZMS\Desktop\sherlock temp files\sherlock.m2v", cachefile = "C:\Users\luigi.TZMS\Desktop\sherlock temp files\sherlock.ffindex")
QTGMC(Preset="Slow") (InputType=1 for progressive)
SelectEven() (only for interlaced)
RemoveGrain()


ISSUE N.1: AVISYNTH+ GRADUALLY SLOWS DOWN


To show the progressive slowdown of Avisynth+ I made two checkpoints: one at 5.000 frames and one at 150.000 frames (near the end of the encode)

Single-threaded Avisynth+:
Progressive: Encode starts at full steam: CPU at average 75%, fps 19,20 at 5.000-frame checkpoint. CPU is split into about 60% x265, and 15% avs4x26x

However encode gradually gets slower: fps and cpu keep going down. At 150.000-frame checkpoint we have CPU 50% (x265:35% and avs4x26x:15%) and fps 14,50. Fps have gone down 25%

Interlaced: At 5.000 frame checkpoint CPU at average 48% (32% x265 and 16% avs), fps 10,46. Obviously processing interlaced requires more work, so avs produces less frames for x265 to work on. The slowdown of the encoding becomes quite serious on interlaced: at 150.000-frame checkpoint fps are 2,65. Fps have gone down 75% !!

It seems that Avisynth+ is producing less frames over time, so x265 becomes less busy. The more complex the avs script, the more Avisynth+ slows down over time.

I repeated the same test with traditional Avisynth (not plus), and the problem does not exist:
Progressive: 17,75 fps at first checkpoint, 17,89 at second checkpoint. CPU steady around 70%
Interlaced: 11,44 fps and 11,51 respectively; cpu around 51-54%

ISSUE N.2: MULTITHREADED AVISYNTH+ CRASHES TOO OFTEN

For multithreaded scripts add:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("FFVideoSource", 3) (at start of script)
Prefetch(6) (at end of script)

This issue has already been discussed in this thread, but the problem has not been solved yet. Encoding starts very fast, nearly 22 fps. However at a certain unpredictable point it crashes: it may be at the very beginning, it may be after a couple of hours, it seems totally random. If you are doing a very short encode, you might even manage to complete it without errors. Anyway MT Avisynth+ can’t be trusted at the moment.

ISSUE N.3: SOME 64-BIT PLUGINS ARE NOT AVAILABLE

For my workflow, I sometimes use MCTemporalDenoise for some noisy clips. I managed to find most 64-bit plugins required. However, I haven’t been able to find DCTFilter-64bit, so MCTD can’t be used. Is there any workaround, by the way ?

Although 64bit versions exist for most plugins, there is a still a fair number of 32bit-only dlls. So for more complex workflows you need to stick to avisynth-32bit.

CONCLUSIONS
Although very promising, Staxrip 64bit is not ready for prime time. The problems, it seems to me, lie not in Staxrip itself, but rather in Avisynth+ and/or its plugins (I don’t know exactly where the problem/s lie)

So in my opinion Staxrip 32bit should be kept alive at least for the time being, until problems are solved; not necessarily with the introduction of new features, but at least issuing maintenance releases.

Thanks Stax76 for your great work. Staxrip32 is an excellent program, and I am sure that, eventually, Staxrip64 will become very good,too

[stax76]

@luigizaninoni

Thanks for all the testing and feedback. I really hope these problem can be fixed within a few months, otherwise I will consider making StaxRip builds for both 64x and x86 or start with C++ programming.

StaxRip x64 1.3.1.2 pre-release (2015-05-19)


Added x265 switch --output-depth to choose between 8bit and 10bit output
Improved 'Demux Configuration' dialog
Fixed and changed cropping and resizing with QSVEncC, there is now for both crop and resize a special AviSynth filter profile 'Hardware Encoder' but if AviSynth is bypassed by enabling hardware decoding in QSVEncC then it's not necessary to use this special profiles, any crop or resize profile will do in this case.
Fixed bug audio streams not being detected for M2TS files
Updated x265 to x265_1.7+2
Updated QSVEncC to 2.0 beta 3


http://code.fosshub.com/StaxRip/downloads

https://github.com/stax76/staxrip/releases

[burfadel]

@Stax

QAAC 2.49 was just released yesterday.

[stax76]

Thanks, how did you find out? I've enabled a 'Watch' feature now on the qaac github page, I'm not sure what is does exactly though.

[burfadel]

I saw a new version of Staxrip, and just thought I'd check out the pages for QAAC etc, since I know it's in active development :). In other words, I wasn't expecting it, but since I use Firefox all I had to do was type in qa in the address bar and it was the first thing to show :).

I notice there still isn't an inverse telecine and decimate filter in the latest build. This is vital if encoding telecined (29.97 fps) material. The filter you had in the 32-bit Staxrip, Decomb, was fine :). There is a 64 bit version of it:
http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins

I also notice you changed the 'tools' folder to 'apps'. If people just extract over what they already have, they may have a superfluous 'tools' folder... easy fixed I know, but may be worth mentioning :).

[Alexander]

@ Frank

[StaxRip x64 1.3.1.2 pre-release (2015-05-19)

with me DGDecodeNV does not work
error message

[Window Title]
StaxRip

[Main Instruction]
Failed to open source, try another method?

[Content]
DGSource: Invalid index file!
(Source.avs, line 2)

[stax76]

@Alexander

There is a issue you can fix yourself:

Tools > Settings > Demuxing > select DGIndexNV > Edit > Input Formats and Input File Types must be comma separated.

I'm still getting errors however, I try to find what's wrong.

@burfadel

I'm not sure Decomb works on Win10, I only include things that work on Win10, I'll try it. I didn't think renaming Tools to Apps could break something. Microsoft uses the name 'App' for both mobile and desktop applications, they will also allow to add desktop applications to the app store. When Win10 arrives I will try to add StaxRip to the app store, I don't know if it will work.

[videoh]

I'm not sure Decomb works on Win10, I only include things that work on Win10, I'll try it. It seems to work just fine on Win8.1 64-bit, so there's no reason it shouldn't work on Win10.

[stax76]

It seems to work just fine on Win8.1 64-bit, so there's no reason it shouldn't work on Win10.

I was getting all kind of crazy errors that all went away after reboot, Win10 is fairly buggy, I'm not having a great experience but it's OK.

I have a question to you however, I notice StaxRip is receiving progress from your indexing applications, the code is old and I don't remember if I monitor the title of the application or if this progress comes from stderr/stdout, if it comes from stdout/stderr which API do you use for this? I was suggesting to l-smash to send progress but nobody really knew how to do it.

edit:

I thought you were referring to my post about DGDecNV, I had problems with it that went away after reboot, I'm now trying Decomb.

edit 2:

Decomb x64 works on Win10

[videoh]

I have a question to you however, I notice StaxRip is receiving progress from your indexing applications, the code is old and I don't remember if I monitor the title of the application or if this progress comes from stderr/stdout, if it comes from stdout/stderr which API do you use for this? I was suggesting to l-smash to send progress but nobody really knew how to do it. Every 30 frames, this function is called to write to stdout:

void OutputProgress(int progr)
{
static int lastprogress = -1;

if (progr != lastprogress)
{
char percent[20];
DWORD written;

sprintf(percent, "%d\r", progr);
WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), percent, (DWORD) strlen(percent), &written, NULL);
lastprogress = progr;
}
}

progr is an int 0-100 indicating the percent completed. The caller determines the percent complete from the ratio of the current file position and the size of the file. That way you don't need to know the number of frames in the file.

Decomb x64 works on Win10 Sweet.

[stax76]

Every 30 frames, this function is called to write to stdout:

void OutputProgress(int progr)
{
static int lastprogress = -1;

if (progr != lastprogress)
{
char percent[20];
DWORD written;

sprintf(percent, "%d\r", progr);
WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), percent, (DWORD) strlen(percent), &written, NULL);
lastprogress = progr;
}
}

progr is an int 0-100 indicating the percent completed. The caller determines the percent complete from the ratio of the current file position and the size of the file. That way you don't need to know the number of frames in the file.

Sweet.

Thanks, would be a great improvement for L-Smash-Works, I'll forward it.

[Alexander]

@Frank


Ok, thank
I did not see that there are missing commas

[luigizaninoni]

Stax, have you seen Rean's reply on Avisynth+ thread ?:

Quote:
ISSUE N.1: AVISYNTH+ GRADUALLY SLOWS DOWN
It is not an Avisynth problem. It is because the user uses very complex QTGMC script with many plugins. Many MT processing = many bottleneck states. And x264 is extreme optimized software.

ISSUE N.2: MULTITHREADED AVISYNTH CRASHES TOO OFTEN
It is a non-compatibility of FFVideoSource with some video sources and MT. I was getting constant crashes with this plugin. Therefore, I stop using it.
But, the majority of Avisynth crashes is that in 32 bits there is no free memory for all plugin buffers and frame cache.

----------------------------------------------------------
I thought that perhaps he was right about FFvideosource, so in Staxrip64 I tried with Frimsource instead of FFVideoSource (installed intel media sdk and so on)

Well, he really was right: no more slowdowns, fps steady at 19,10 (qtgmc progressive) and cpu at 67% throughout the encode. Speed improvement of 7% over classic Avisynth, not a great deal but still appreciated.

Then I thought, if Ffvideo source is causing the slowdown, it might also be the cause of the crashes in MT.

Look and behold, tried Frimsource MT and encode is not yet finished but it is at 21fps, cpu 100% and no sign of slowdown or crashes.

So I may have incorrectly blamed Avisynth+, while the real culprit was FFVideoSource

So, if this is the situation, I'd like to ask your advice for my .ts qtgmc encodes:

1- I can't use Frimsource, because it works only on QTGMC progressive. If I try QTCMC interlaced, if fails with message:

MergeLuma: Images must have same width and height!
(C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Apps\Plugins\QTGMC\QTGMC.avsi, line 394)
(C:\Users\luigi.TZMS\Desktop\Film\sherlock temp files\sherlock.avs, line 8)

Have you any solution for this error ? Any idea what might be the cause ?

2- If there is no solution, what other source filters could I try instead of FFVideoSource ?

[stax76]

@Frank


Ok, thank
I did not see that there are missing commas

There was a bug separating the file types by space only, that's the only problem I'm aware, I tested it and it worked.

@luigizaninoni

Thanks for the info and investigation, keep going, I'm looking into it once I finish a few other things I currently investigate.

[stax76]

The version of xvid_encraw included does not support the "-metric [integer]"

I replaced it with your version.

An xvid_encraw encoding process cannot be aborted via the GUI.

It should work in recent builds, for two command lines you have to abort two times.

While the "filters" edit window now postions itself properly on the screen

You mean the new editor? It adjusts the vertical size automatically every time enter or backspace is pressed, what it lacks so far is auto adjust for cut and paste. I'm willing to improve it but would need a detailed description.

The sample code for xvid_encraw does not include a sample for the compressibility check.

I've added it.

edit:

both builds work but Patman's is newer.

[jkilez]

Thanks for the quick update! Sorry if I was in the wrong thread--I am playing catch-up on what you have done. Good stuff.
You mean the new editor? It adjusts the vertical size automatically every time enter or backspace is pressed, what it lacks so far is auto adjust for cut and paste. I'm willing to improve it but would need a detailed description.
I mean the AviSynth Editor window, which (unless you have already fixed it) looks like this:
http://i.imgur.com/AXTGRji.png

My filters are difficult to edit in that space as they often have long chains that look like this:
b1.trim(0, 620) ++ \
b2.trim(621,622) ++ b1.trim(623,623) ++ b2.trim(624,626) ++ b1.trim(627,627) ++ b2.trim(628,658) ++ \
mt_merge(b1.ColorYUV(gamma_y=-6),last.ColorYUV(off_y=-2),mask,luma=true,chroma="process").trim(659,660) ++ \
mt_merge(b2.ColorYUV(gamma_y=-1),last.ColorYUV(off_y=-1),mask,luma=true,chroma="process").trim(661,665) ++ \
mt_merge(b1.ColorYUV(gamma_y=-5),last,mask,luma=true,chroma="process").trim(666,666) ++ \
mt_merge(b1,last,mask,luma=true,chroma="process").trim(667,2026) ++ \
b2.trim(2027,2033) ++ b3.trim(2034,2101) ++ b5.trim(2102,2821) ++ b4.trim(2822,8300) ++ trim(8301,0)

[Patman]

Hi Stax,

ffms2 was updated to version 2.21 before 5 days. Which version of ffms2 do you use? msvc or icl?

[stax76]

Hi Stax,

ffms2 was updated to version 2.21 before 5 days. Which version of ffms2 do you use? msvc or icl?

Hello Patman,

IIRC I updated to 2.21 MSVC

[NikosD]

Hello.

Using latest StaxRip x86 (1.2.2.2) /x64 (1.3.1.2) and latest nightly HandBrake x64 svn7214 I tested QSVEncC x86 (v1.33) /x64 (v2.00β3) in both modes SW and HW decoding for x64 version.

The system used is Core i7 4790 – Win 8.1 x64 Pro – iGPU HD 4600@1.5GHz – Drivers 4206

I used CQP encoding mode which is available for both applications using the 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)

For HandBrake I used the command la=0 in order to disable LookAhead option, but the result was the same like the default setting which had LookAhead enabled (at least in the older versions), so probably LookAhead was used resulting in lower performance for HandBrake.

The CPU decoding mode used all 8 cores (HT) with the default sources for StaxRip x86/x64 (usually FFVideoSource/ LSMASH). The HW decoding mode used CPU at about 2-3% for both StaxRip and HandBrake except in HEVC (look below)
For HEVC I used another decoder which is LAV v0.65 DXVA copy-back decoder with DSS2 source filter.

I tested all three video formats available for HW decoding (H.264, MPEG2, H.265) with progressive clips.

I also tested the scaling option (resize) for all apps using always in all cases the HW resizer.


H.264 – Chimei inn-2160p clip – 50Mbps


StaxRip x64 QSV 84 fps – Time 15s
HandBrake x64 72 fps – Time 21s
StaxRip x64 51 fps – Time 25s
StaxRip x86 48 fps – Time 26s


Same clip 2160p -> 1080p


StaxRip x64 QSV 169 fps – Time 7s
HandBrake x64 155 fps – Time 11s
StaxRip x64 61 fps – Time 21s
StaxRip x86 61 fps – Time 21s


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


StaxRip x64 QSV 301 fps – Time 11s
HandBrake x64 240 fps – Time 14s
StaxRip x86 239 fps – Time 14s
StaxRip x64 229 fps – Time 14s


Same clip 1080p -> 720p


StaxRip x64 QSV 462 fps – Time 7s
HandBrake x64 393 fps – Time 9s
StaxRip x86 268 fps – Time 12s
StaxRip x64 268 fps – Time 12s


MPEG2 – 1080p30fps – 22Mbps


StaxRip x64 QSV 275 fps – Time 12s
StaxRip x64 227 fps – Time 14s
StaxRip x86 216 fps – Time 15s
HandBrake x64(CPU) 198 fps – Time 16s


HEVC – Girls – 1080p – 11Mbps


StaxRip x64 173 fps – Time 68s
StaxRip x86 112 fps – Time 106s
StaxRip x64 QSV 90 fps – Time 132s CPU 15%
HandBrake x64(CPU) 90 fps – Time 132s
StaxRip x64 (DSS2+LAV(CB) 86 fps – Time 138s CPU 22%


So, the huge difference is in resizing and the CPU usage (which drops near 2-3%)

For HEVC the x64 CPU decoders are much faster than hybrid GPU decoders, besides HandBrake which is x64 but has a very slow CPU HEVC decoder
The x86 CPU decoders are much closer to hybrid decoders.

HandBrake supports only H.264 in HW decode mode.

[Patman]

Hello Patman,

IIRC I updated to 2.21 MSVC

Ah okay. The date that was shown was 2015-05-02 but the latest version is 2015-05-16. That's the reason why i'm asking.

[NikosD]

QSVEncC v2.00β4 is out fixing 10bit HEVC decoding for Broadwell among a few things.

[stax76]

Hello everybody,

I was working on a couple of improvements and uploaded a new beta. I still like GUI programming so I improved the AviSynth editor a lot.

I'm pausing StaxRip now again for a while but don't worry, I'll be back and catch up with unanswered questions.

StaxRip x64 1.3.1.3 beta (2015-05-21)

Added Decomb x64 plugin
Greatly improved AviSynth editor
eac3to dialog is now suppressed in batch mode
Improved frame rate correction
Replaced DGAVCDec with dsmux
Re-added backup feature to keep backup of filter, audio and video encoder profiles. It means when filter, audio or video encoder profiles are reset, previous profiles are still available in a Backup sub menu, the menu structure is customizable so profiles of the backup sub menu can be moved to top level using the profiles editor which supports multi-select.
Fixed wrong DGIndexNV demux configuration
Updated ffms2 to 2.21

http://code.fosshub.com/StaxRip/downloads

http://www.mediafire.com/folder/0jakce45o99kb/StaxRip_beta

[burfadel]

I'm running Windows 10 TP, and updated to build 10122 that just came out. Just thought I'd let people know there seems to be a strange issue with Staxrip and QAAC. I mentioned this in the LAV filters thread, but I was all over the place about what was causing it. QAAC seemed to stop part way through the actual encode process, and staxrip would throw the error. When copied and pasted the command line to the command line, it worked fine! Now, I thought it was one thing then thought it was another, but in reality it seems to work properly all the time... for now... when it is minimised to the system tray! I normally have it this way anyway, but since it goes pretty quickly etc it never occurred to me initially that it was the cause. So, for the times I did find it working as mentioned, it was probably because it was minimised? I can't remember!

Anyways, so it seems there may be a new bug in the new build with, or affecting, NET Framework. I guess it's with the new build of NET Framework 4.6 (which is the Windows 10 version of NET Framework 4.5).

I'll let you know how the new Staxrip version goes.

[stax76]

I'm running Windows 10 TP, and updated to build 10122 that just came out. Just thought I'd let people know there seems to be a strange issue with Staxrip and QAAC. I mentioned this in the LAV filters thread, but I was all over the place about what was causing it. QAAC seemed to stop part way through the actual encode process, and staxrip would throw the error. When copied and pasted the command line to the command line, it worked fine! Now, I thought it was one thing then thought it was another, but in reality it seems to work properly all the time... for now... when it is minimised to the system tray! I normally have it this way anyway, but since it goes pretty quickly etc it never occurred to me initially that it was the cause. So, for the times I did find it working as mentioned, it was probably because it was minimised? I can't remember!

Anyways, so it seems there may be a new bug in the new build with, or affecting, NET Framework. Not sure what version of NET Framework is now used for Staxrip...

I'll let you know how the new Staxrip version goes.

Minimum .NET version is 4.5, I'll use qaac for my next encodes and don't minimize, maybe I can reproduce it.

[burfadel]

Any reason for the 1.3.1.3 build using the old QAAC 2.48? It happens with 2.48 as with 2.49.

The error is now happening again, but only after I closed Staxrip so I could use the new version!

Error Audio encoding using qaac

Audio encoding using qaac failed with exit code 255

qaac 2.48, CoreAudioToolbox 7.9.9.6
2006-02-19 - s13e05 - Utrecht, The Netherlands - The Boat On The Rhine ID2 English_out.m4a
Scanning maximum peak...
127172608/127172608 samples processed in 0:00.797
Peak value: 0.279785
AAC-LC Encoder, TVBR q64, Quality 96



StaxRip.ErrorAbortException: Audio encoding using qaac failed with exit code 255

qaac 2.48, CoreAudioToolbox 7.9.9.6
2006-02-19 - s13e05 - Utrecht, The Netherlands - The Boat On The Rhine ID2 English_out.m4a
Scanning maximum peak...
127172608/127172608 samples processed in 0:00.797
Peak value: 0.279785
AAC-LC Encoder, TVBR q64, Quality 96


at StaxRip.Proc.Start() in D:\Projekte\GitHub\staxrip\General\Proc.vb:line 226
at StaxRip.GUIAudioProfile.Encode() in D:\Projekte\GitHub\staxrip\General\AudioProfile.vb:line 612
at StaxRip.MainForm.Encode() in D:\Projekte\GitHub\staxrip\Forms\MainForm.vb:line 2220
at StaxRip.MainForm.RunJobRecursive() in D:\Projekte\GitHub\staxrip\Forms\MainForm.vb:line 3446

The above message only shows the first pass for the normalisation. It's the second, slower pass that fails. It failed at 17.6 percent in this case. As I said, even if it constantly fails in Staxrip, the same command line constantly works from the command prompt!

Any chance of a couple of different builds (just staxrip) using different compiler/compiler settings? Just curious :)

[stax76]

It must be specific to your system, here everything is fine:

http://pastebin.com/ukmKMK65

[burfadel]

Probably an issue in the update process, apparently it's been finicky and not working/not working properly for a lot of people.

It's interesting yours says:
v4\Client : 4.6.00073
v4\Client\1031 : 4.6.00073
v4\Full : 4.6.00073
v4\Full\1031 : 4.6.00073
v4.0\Client : 4.0.0.0

and mine says:
v2.0.50727 : 2.0.50727.4927
v3.0 : 3.0.30729.4926
v3.5 : 3.5.30729.4926
v4\Client : 4.6.00073
v4\Full : 4.6.00073
v4.0\Client : 4.0.0.0

Of course I realise you don't have the 3.5 installed, I'm referring to the 4.6 entries. Language pack? Anyways, it's now working again. I won't touch it!

[stax76]

StaxRip redirects the output from qaac but qaac is still a separate process, it's hard to tell why it works with cmd.exe, there might be different environment variables. What can be done is attaching a debugger to a running process, I can only do it with Visual Studio which is a huge download and setup and it's not clear it would catch a exception. Did you check the windows event log?

edit:

If it don't terminate instantly maybe you could make a crash dump, the windows task manager has a option in the context menu.

Also remember you can still use Nero or FDK AAC.