Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
19th May 2015, 22:36 | #181 | Link | |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Quote:
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 Last edited by stax76; 19th May 2015 at 22:51. |
|
19th May 2015, 23:39 | #182 | Link | ||
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
Quote:
Code:
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; } } Quote:
Last edited by videoh; 19th May 2015 at 23:46. |
||
20th May 2015, 00:29 | #183 | Link | |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Quote:
|
|
20th May 2015, 14:39 | #185 | Link |
Registered User
Join Date: Apr 2015
Posts: 163
|
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 ? Last edited by luigizaninoni; 20th May 2015 at 14:42. |
20th May 2015, 15:14 | #186 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
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. |
20th May 2015, 21:43 | #187 | Link | ||||
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Quote:
Quote:
Quote:
Quote:
edit: both builds work but Patman's is newer. Last edited by stax76; 20th May 2015 at 21:52. |
||||
20th May 2015, 22:27 | #188 | Link | |
Registered User
Join Date: May 2014
Posts: 33
|
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.
Quote:
My filters are difficult to edit in that space as they often have long chains that look like this: Code:
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) Last edited by jkilez; 20th May 2015 at 22:33. |
|
21st May 2015, 13:27 | #191 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
First test with full QSV transcoding (dec+enc)
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.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all Last edited by NikosD; 21st May 2015 at 16:18. |
21st May 2015, 16:16 | #193 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
QSVEncC v2.00β4 is out fixing 10bit HEVC decoding for Broadwell among a few things.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
21st May 2015, 16:23 | #194 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
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)
http://code.fosshub.com/StaxRip/downloads http://www.mediafire.com/folder/0jak...b/StaxRip_beta |
21st May 2015, 16:30 | #195 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
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. Last edited by burfadel; 21st May 2015 at 16:39. |
21st May 2015, 16:38 | #196 | Link | |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Quote:
|
|
21st May 2015, 16:43 | #197 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
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! Code:
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 Any chance of a couple of different builds (just staxrip) using different compiler/compiler settings? Just curious Last edited by burfadel; 21st May 2015 at 17:01. |
21st May 2015, 17:52 | #199 | Link | ||
Registered User
Join Date: Aug 2006
Posts: 2,229
|
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: Quote:
Quote:
Last edited by burfadel; 21st May 2015 at 17:59. |
||
21st May 2015, 18:10 | #200 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
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. Last edited by stax76; 21st May 2015 at 18:15. |
|
|