StaxRip

[stax76]

Originally Posted by videoh

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]

Originally Posted by stax76

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]

Originally Posted by videoh

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]

Originally Posted by Alexander

@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.

Originally Posted by stax76

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:


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]

Originally Posted by Patman

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]

Originally Posted by stax76

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/0jak...b/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]

Originally Posted by 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. 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.