View Full Version : StaxRip
Zetto
9th March 2017, 20:42
@Stax76
nvenc updated to 3.07
released Mar 8, 2017
add option to apply NVENC presets. (--preset [default, quality, performance])
please note that some options are overrided by user or application specified parameters.
add option to set H.264 B direct mode. (--direct [auto, none, spatial, temporal])
add option to enable H.264 adaptive transform mode. (--adapt-transform)
--enable-ltr is now for HEVC only, since it is mentioned in SDK that it does not currently work for H.264.
(just a day after your last test build lol)
VelleX
10th March 2017, 09:28
found some benchmarks for comparison between ryzen and single Xeon x5670 or Dual x5675, but test is with an old x264 build.
http://www.xin.at/x264/?comp_id=8&search=Suchen&custombuild=on&virtsys=on&subminspecs=on&systemclass=nonotebooks
5 0000:43:55.819 199.234x 11.906 79.23% Cracky 1/8/16 AMD Ryzen 7 1700 3.00GHz @ 3.90GHz 16GB DDR-IV/2400 13-13-13-35 Gigabyte AB350-Gaming 3 Windows 10 Pro x64
7 0000:48:20.084 181.079x 10.821 44.47% Soulreaver 2/6/12 Intel Xeon X5690 3.47GHz @ 4.21GHz 24GB DDR-III/1333 CL7 EVGA Classified SR-2 Windows 10 Enterprise x64
10 0000:48:52.220 179.094x 10.702 81.70% Yoshi 1/8/16 AMD Ryzen 7 1700X 3.40GHz 16GB DDR-IV/2400 14-14-14-34 ASUS PRIME X370-PRO Windows 10 Pro x64
15 0000:53:43.561 162.908x 9.735 84.22% Cracky 1/8/16 AMD Ryzen 7 1700 3.00GHz 16GB DDR-IV/2400 13-13-13-35 Gigabyte AB350-Gaming 3 Windows 10 Pro x64
21 0000:56:55.643 153.747x 9.188 51.85% Eisfuchs 2/6/12 Intel Xeon X5675 3.07GHz 24GB DDR-III/1333 CL9 Dell 06FW8P Windows 7 Pro x64
36 0001:10:29.641 124.158x 7.420 48.15% Elianda 2/6/12 Intel Xeon X5650 2.67GHz 8GB Reg. ECC DDR-III/1066 HP z600 Windows XP Pro x64
38 0001:11:28.877 122.443x 7.317 62.99% Grindhavoc 1/6/12 Intel Xeon X5650 2.67GHz @ 4.02GHz 24GB ECC DDR-III/1600 9-9-9-24 1T ASRock X58 Extreme3 Windows 7 Pro x64 SP1
41 0001:13:28.645 119.117x 7.118 63.16% Aristo084 1/6/12 Intel Xeon X5670 2.93GHz @ 3.90GHz 12GB DDR-III/1600 9-9-9-20 1T Gigabyte GA-EX58-UD5 Windows 7 Ultimate x64
Lupissimo
10th March 2017, 17:35
Not being an expert on encoding parameters I need help:
Comparing NVIDIA h264 encodes from StaxRip 1.401 (default settings CQP Profile 4.1 high) and Staxrip 1.407 (default settings VBRHQ Profile 4.1 high) I get of course much smaller file size but the quality is not quite as good. Which parameter(s) do I have to change to obtain a higher quality?
Edit: Having tried various files, the default settings for 1.407 are probably wrong. I get a file size of 750MB instead of 5GB using 1.401. The video is very jerky and pixelated.
jonesjrgr
11th March 2017, 21:24
Hello!!!
I searched the entire topic (staxrip),for a way to convert an HDR source to SDR output.
I have seen the user ready script (included in staxrip),but i can't reverse it.
Is there a way to do it?Another custom script perhaps?
Any kind of help is appreciated.
Thank you in advance,and sorry if it is already mentioned,and i missed it
Lupissimo
13th March 2017, 14:31
Testing 1.407 NVIDIA ENC 264:
Starting from the same 12 GB file using the default VBRHQ Profile 4.1 High values I get: 691.577 KB for the entire movie (length 01:47:26 ).
When I use the cutting option to reduce the length to 00:09:22
the file is 774.834 KB with the same settings.
?????????????????????:(:(:(
stax76
13th March 2017, 14:37
@Zetto
NVEncC and x265 are updated.
https://github.com/stax76/staxrip/blob/master/md/test-build.md
Khun_Doug
17th March 2017, 17:45
I have been using build 1.4.0.6 thru 1.4.0.8 without trouble. I have an I7-6850K with 32GB RAM, M.2 SSD PCI, ATI R9 GPU. StaxRip has been very responsive to mouse commands, accessing filters, cropping and preview. I am now using Windows 10 build 15048. This is one of the release candidates for the next Windows 10 update (I think it is called Creators Edition). Since being on this release StaxRip GUI is extremely laggy. Opening crop and preview take several seconds before I get a window. Even closing crop and preview is slow, again taking seconds for anything to happen. Using auto function in crop seems to use only one processor but I know that, previously, the auto cropping would use all processors. Attempting to add or modify filters is also lagging. Here again the operations also seem to take seconds before anything happens.
So far I tried loading 1.4.0.8 on a virtual machine that never had any other version installed. That includes a fresh install of Vapoursynth, Python 3.6, and AviSynth+. The GUI lag is very evident in this test setup.
My test file is a 15GB BD rip. I have also tested with other BD rips and see the same results, so I am sure the source material is okay. I will say that using SD files from DVD rips do not seem to be anywhere near as lagged. I believe there is something preventing StaxRip from operating multi-threaded (very evident in the auto crop operation). It is worth mentioning that encodes operate fine and X264 encoder saturates the machine. The trouble is isolated to the GUI.
Any thoughts or suggestions are welcome. Other tools are not exhibiting this problem with these same source BD files, so I am sure the trouble is isolated to my install of StaxRip on this system and a VM on the same hardware. I truly am stumped on how to resolve this and want to get it resolved.
stax76
17th March 2017, 18:14
@Khun_Doug
So it only happens with pre-release Windows builds?
Khun_Doug
17th March 2017, 19:33
I can say for certain that this is happening on build 15048 and now I just moved up to build 15060 (all release candidates). The problem persists. This was not happening on Anniversary Edition.
To help diagnose this I found folks referencing Process Monitor from Microsoft Sys Internals. I grabbed that and set a filter to only capture StaxRip.exe. I am attaching a link to a 7z of the CSV output. My source file is a BD of Kiss Of The Dragon. My operations were very simple.
https://www.dropbox.com/s/6kabm4gnhzame34/StaxRip%20ProcMon.7z?dl=0
1. Open the file
2. Open crop, and select auto
3. Close crop
4. Open preview (I did not scroll through the film)
5. Close preview
6. Add a noise filter and then choose finesharp
7. Add misc/fluxsmooth
8. Exit
I also timed the lag on mouse commands and it is approximately 5 seconds.
Khun_Doug
18th March 2017, 20:13
I have been able to garner a little more information that may be useful. I determined that some of my BD rips open fine and do not have this lag issue while other BD rips do. The one common factor that I found in files with the lag deals with the frame rate. Mediainfo reports the following for rips with GUI lag:
Frame rate mode : Constant
Frame rate : 24.000 FPS
Original frame rate : 23.976 (24000/1001) FPS
In BD rips that do not exhibit the lag, Mediainfo reports:
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
The format does not appear to be a factor. The only other difference is the length and file size of the rip. BD rips that are approximately 50 minutes long and file size no more than 9GB do not exhibit the lag. A BD rip that is 98 minutes and 16GB has lag, as done one that is 127 minutes and 30GB. All sources, lagged or regular, are 4:2:0 8 bit.
stax76
19th March 2017, 02:02
Maybe the source filter is just slow, you can try different source filters, slow seeking could be caused by a bad ripping method. I really need a log file.
Khun_Doug
19th March 2017, 04:45
I did more experimenting and verified the the frame rate discrepancy as the culprit. Of course it was coincidence that I installed the new ripping software after Windows 10 updated. The ripping software is Acrok Video Converter Ultimate, and is their latest version. I'll get on to them next week.
As a temporary workaround I found that using MKToolNix I could have the frame rate corrected. It's an extra step but the resultant file shows the correct fps and the GUI lag is gone! I did try difference source filters but the lag carried across each that I tried.
Here is the StaxRip log and the output from Mediainfo for one of the files that has the lag.
http://pastebin.com/JqHd03Je
stax76
19th March 2017, 11:41
Writing application : libmatroska built on Oct 15 2013 10:18:17
Writing library : libebml v1.2.0 + libmatroska v1.1.0
The problem could be how the app uses libmatroska. It uses a very old version from 2013. The file is VC-1, source filters generally have better support for AVC. Other rip apps you can try are MakeMKV and AnyDVD.
JohnLai
20th March 2017, 12:39
Hmm....stax76, can you implement a function to automatically run xxx instances of transcoding jobs?
I have queued 60 files to transcoding using Rigaya Nvenc HEVC.
As far as I know, https://developer.nvidia.com/video-encode-decode-gpu-support-matrix has list of how many nvenc engine for nvidia gpu.
GM204 Maxwell has 2 nvenc chips while Pascal has 3 nvenc chips.
Currently I make do by "File batch" 60 videos, click "Start", then on next windows, click "jobs", highlight next job and click "start in new instance". Voila, there will be automatic 2 instances of staxrip using nvenc transcoding until all remaining 58 jobs finish.
I hope the above method can be simplified a bit......
stax76
20th March 2017, 13:06
@JohnLai
Hopefully sometime this year, if possible please create a issue on the tracker.
edit:
because it's a bit difficult to code...
need4speed
20th March 2017, 18:12
Hi all,
wondering if there is any way to set a two pass process with different settings for pass 1 and pass 2. Thanks
Inviato dal mio GT-N7100 utilizzando Tapatalk
stax76
20th March 2017, 23:02
Hi all,
wondering if there is any way to set a two pass process with different settings for pass 1 and pass 2. Thanks
Inviato dal mio GT-N7100 utilizzando Tapatalk
There is a cli encoder, in the latest test build the gui encoder has dedicated custom options like the x264 gui encoder:
https://postimg.org/image/xxm4xeh55/
https://github.com/stax76/staxrip/blob/master/md/test-build.md
need4speed
21st March 2017, 09:33
There is a cli encoder, in the latest test build the gui encoder has dedicated custom options like the x264 gui encoder:
https://postimg.org/image/xxm4xeh55/
https://github.com/stax76/staxrip/blob/master/md/test-build.md
Many thanks
Inviato dal mio GT-N7100 utilizzando Tapatalk
burfadel
21st March 2017, 15:41
The Staxrip executable seems to be taking a lot of CPU use in test build 1.4.0.9 (shown in task manager processes list), after a while it's constantly a few percent. Version 1.4.0.8 works fine and uses no discernible CPU power when the encode is running in the system tray.
stax76
21st March 2017, 15:54
The Staxrip executable seems to be taking a lot of CPU use in test build 1.4.0.9 (shown in task manager processes list), after a while it's constantly a few percent. Version 1.4.0.8 works fine and uses no discernible CPU power when the encode is running in the system tray.
Maybe it's caused by VapourSynth or AviSynth, both were updated.
burfadel
22nd March 2017, 00:50
Maybe it's caused by VapourSynth or AviSynth, both were updated.
I've updated a lot of the components myself, so before 1.4.0.9 I already had the changes. The only thing needed to stop the CPU load was to copy back the 1.4.0.8 staxrip.exe and staxrip.pdb files. Version 1.4.0.9 worked, just the only symptom was the CPU load of staxrip.exe itself.
stax76
22nd March 2017, 01:02
@burfadel
Under which circumstances did it happen? While encoding? Which encoder?
burfadel
22nd March 2017, 01:56
While encoding using x265. It could be because I often do two encodes in parallel, which works fine normally! I find I get better encode speed overall than using MT in the script. When it did have high CPU use I was doing multiple encodes like that, and was repeatable, but thinking of it only one instance seemed to have high use.
JohnLai
22nd March 2017, 03:47
Hmm....my dad starts to record stuff from satellite broadcast.
The recorded file was in TS container.
There are 2 DVB bitmap subtitles within TS.
How can I simply mux these two DVB bitmap subtitles after transcoding using staxrip?
Mediainfo detail for one of many video stuff recorded by my dad, example, there are 3 dvb bitmap subtitles:
Video
ID : 851 (0x353)
Menu ID : 85 (0x55)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : 27
Duration : 44 min
Bit rate mode : Variable
Bit rate : 4 561 kb/s
Maximum bit rate : 19.2 Mb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.198
Stream size : 1.42 GiB (84%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio #1
ID : 852 (0x354)
Menu ID : 85 (0x55)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 6
Duration : 44 min
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 spf)
Compression mode : Lossy
Stream size : 123 MiB (7%)
Language : English
Audio #2
ID : 853 (0x355)
Menu ID : 85 (0x55)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 6
Duration : 44 min
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 spf)
Compression mode : Lossy
Stream size : 61.4 MiB (4%)
Language : English
Text #1
ID : 854 (0x356)
Menu ID : 85 (0x55)
Format : DVB Subtitle
Codec ID : 6
Duration : 44 min
Delay relative to video : 928 ms
Language : Chinese
Text #2
ID : 855 (0x357)
Menu ID : 85 (0x55)
Format : DVB Subtitle
Codec ID : 6
Language : English
Text #3
ID : 856 (0x358)
Menu ID : 85 (0x55)
Format : DVB Subtitle
Codec ID : 6
Duration : 44 min
Delay relative to video : 928 ms
Language : chs
Staxrip doesn't seem to show any of dvb subtitles at "Container Options"
EDIT: stax76 might wanna have a read on https://github.com/mbunkus/mkvtoolnix/issues/1843
Seem like mkvtoolnix 9.8.0 implemented dvb subtitle:
mkvmerge: added support for Digital Video Broadcasting (DVB) subtitles (CodecID S_DVBSUB). They can be read from MPEG transport streams and from Matroska files. Implements #1843.
and latest version 9.9.0 added bugfix on muxing dvb subtitle.
burfadel
22nd March 2017, 05:27
@burfadel
Under which circumstances did it happen? While encoding? Which encoder?
Further to my last post, I tried 1.4.0.9 again, and it doesn't seem to be doing it now. Previously I had the encodes running for a while before the issue started (two separate occasions), I'll let it run again for a while and see what happens.
Might be one of those things where a reboot solved the problem. Only change apart from the reboot was just updated to AMD Crimson 17.3.3 from 17.3.2 (hence the reboot).
need4speed
22nd March 2017, 06:25
Hi again,
sorry for the hassle but i am still trying to understand how the 2pass option screen works.
Here is a sample of my setup.
http://i68.tinypic.com/5dw7yq.jpg
Not sure if this is correct since what I check log when encoding first pass is that ME=dia. What I did wrong?
http://i63.tinypic.com/qmxna1.jpg
I expect me=star to be applied for both pass1 and pass2??
Basically the only difference between pass 1 and pass 2 should be pass2 with no --no-slow-firstpass switch.
Thanks in advance!
m-v-w
22nd March 2017, 06:27
Can be added like VidCoder, you can cut the film, more detailed adjustment items
https://vidcoder.codeplex.com/
Can increase NeuronDoubler
http://loggialogic.blogspot.tw/2012/06/neurondoubler.html
Can increase waifu2x
https://github.com/nagadomi/waifu2x
waifu2x-converter-cpp for nvidia
https://github.com/tanakamura/waifu2x-converter-cpp
waifu2x-caffe for amd
https://github.com/lltcggie/waifu2x-caffe
Can increase the function similar to AniZip
http://c00-c03.blogspot.tw/2017/02/AniZipReleaseNotes.html
https://www.youtube.com/watch?v=bVxqa66zEf8
burfadel
22nd March 2017, 07:19
@burfadel
Under which circumstances did it happen? While encoding? Which encoder?
While encoding using x265. It could be because I often do two encodes in parallel, which works fine normally! I find I get better encode speed overall than using MT in the script. When it did have high CPU use I was doing multiple encodes like that, and was repeatable, but thinking of it only one instance seemed to have high use.
Further to my last post, I tried 1.4.0.9 again, and it doesn't seem to be doing it now. Previously I had the encodes running for a while before the issue started (two separate occasions), I'll let it run again for a while and see what happens.
Might be one of those things where a reboot solved the problem. Only change apart from the reboot was just updated to AMD Crimson 17.3.3 from 17.3.2 (hence the reboot).
I've been running the encodes since about 10 minues before the last post, and now it is doing it again. This is new behaviour in 1.4.0.9, 1.4.0.8 does not do it.
1.4.0.9 This is what happens:
http://i.imgur.com/fvNZuO4.jpg
When I noticed the problem earlier, the encodes were running much longer, and the CPU use was around 4 percent on the errant staxrip process.
In all cases it seems to affect only one of the instances. I'm not sure what would happen if I run one encode for an extended period. The second encode was started a minute or so after the first. Both encodes are encoding files of the same source, same resolution, using the same script and encoder settings. Both windows are minimised, just then the usage was mostly 2 percent but raising to 3 percent and dropping to 1 percent rarely. It doesn't sound like much, but it shouldn't be doing it. The other instance of Staxip was as expected, I realise there is a little bit of CPU use but this usage is abnormal.
With 1.4.0.8, running the same encodes, only about 10 minutes so far though:
http://i.imgur.com/nT0OgVo.jpg
It doesn't matter that it's 10 minutes, even after two days of encoding with two instances, and it progresses through the job queue, there is no abnormal CPU use with 1.4.0.8 and earlier.
A big thing I'd like to point out is the memory usage. These are encoding the exact files, scripts etc. It seems that 1.4.0.9 uses less memory for Staxrip than 1.4.0.8?
Thanks :)
stax76
22nd March 2017, 12:40
@burfadel
I don't think that I have changed any code that runs and manages processes.
I get about max 0.3% for a single instance and max 1% as sum from 2 instances:
https://postimg.org/image/m3a675p8p/
It seems 2 instances take 4 times the cpu power of one instance, doesn't make much sense, probably I should try to profile/optimize it, as far as I know it does only a little string processing of stdout to decide to rather update the status area or to write to the log file.
EDIT: stax76 might wanna have a read on https://github.com/mbunkus/mkvtoolnix/issues/1843
Seem like mkvtoolnix 9.8.0 implemented dvb subtitle:
mkvmerge: added support for Digital Video Broadcasting (DVB) subtitles (CodecID S_DVBSUB). They can be read from MPEG transport streams and from Matroska files. Implements #1843.
and latest version 9.9.0 added bugfix on muxing dvb subtitle.
most libs/tools can't handle TS well enough because it's too difficult so don't expect much, if you just remux to mkv it might work but as soon as you encode async problems will occur with most libs/tools, new formats like avc/hevc and subtitles make things even more difficult, tools that have good ts reputation are project x, dgdecnv and ts doctor. Some years ago I gave up TV in favor of streaming/download so I'm not well informed. If you post samples and example command lines I'll take a look at it.
@need4speed
You can try 1.4.1.1 which eliminates duplicate switches, custom options override gui options, before this was implemented for custom options but not for 2 pass custom options, now it's implemented everywhere. Better post the command lines which you can find at: main menu > tools > log file
need4speed
22nd March 2017, 13:29
@burfadel
I don't think that I have changed any code that runs and manages processes.
I get about max 0.3% for a single instance and max 1% as sum from 2 instances:
https://postimg.org/image/m3a675p8p/
It seems 2 instances take 4 times the cpu power of one instance, doesn't make much sense, probably I should try to profile/optimize it, as far as I know it does only a little string processing of stdout to decide to rather update the status area or to write to the log file.
most libs/tools can't handle TS well enough because it's too difficult so don't expect much, if you just remux to mkv it might work but as soon as you encode async problems will occur with most libs/tools, new formats like avc/hevc and subtitles make things even more difficult, tools that have good ts reputation are project x, dgdecnv and ts doctor. Some years ago I gave up TV in favor of streaming/download so I'm not well informed. If you post samples and example command lines I'll take a look at it.
@need4speed
You can try 1.4.1.1 which eliminates duplicate switches, custom options override gui options, before this was implemented for custom options but not for 2 pass custom options, now it's implemented everywhere. Better post the command lines which you can find at: main menu > tools > log file
Thanks as always.
Truth to tell I was checking log and found something strange.
Version 1409: pass 1 is working with me Dia while pass 2 was correctly picking up ME Star.
I have posted the command line from log (second image) for pass 1. Pass 2 is picking up switches as expected. So question would be: what is the result of me different settings for pass 1 and pass 2? Sorry if this is dumb question but can't really understand.
For the record mkvinfo is showing me star for final output file.
Inviato dal mio GT-N7100 utilizzando Tapatalk
burfadel
22nd March 2017, 14:20
@burfadel
I don't think that I have changed any code that runs and manages processes.
I get about max 0.3% for a single instance and max 1% as sum from 2 instances:
https://postimg.org/image/m3a675p8p/
It seems 2 instances take 4 times the cpu power of one instance, doesn't make much sense, probably I should try to profile/optimize it, as far as I know it does only a little string processing of stdout to decide to rather update the status area or to write to the log file.
Two instances takes four times the CPU power? How does that work? For me the sum of the framerate achieved running two instances is greater than one, the difference roughly equal to the unused CPU usage of one instance. It might be different with different script complexities, different CPU's etc.
Actually having the option for two parallel encodes I think would greatly benefit those with 8-core, 16-thread Ryzens (like I'm in the process of building). Even a mutli-threaded script can only take the CPU utilisation so far. Even with a multithreaded script, I found that running two non-multithreaded scripts simulatenously is faster than one multithreading script. Not sure about running two multithreaded scripts, I guess that would help on 8-core, 16 thread systems systems.
The good thing of Staxrip and child processes running in idle priority is even with two encodes running it doesn't make any noticeable impact on system performance. I guess if you had a system limited by RAM this wouldn't be the case though (I have the 2017 'standard' of 16 GB).
Anyways, after several hours of encoding:
http://i.imgur.com/gu9pMXs.jpg
This is with 1.4.0.8, so my mistake :). The trick is it doesn't happen right away, but that second usage is high. Even with that use, it's still faster doing two parallel encodes! 4 percent is about the highest, it varies between 1 and 4 percent.
With the NET Framework files you have in the Staxrip folder, like with any DLL used by a program and placed in the programs folder, it uses that instead of those in the system path, correct? I was just wondering whether the issue is related to the version of .NET Framework, and running some 4.6 NET Framework files on .NET Framework 4.7 subsystem.
The Creators Update (currently on Insider but everyone will get it very shortly) for Windows 10 uses .NET Framework 4.7. I wonder if the code version mismatch is is causing the issue? There are several files for me in the Staxrip program folder that are older than that which would load if they aren't there. Too late to test tonight, but tomorrow I'll try 1.4.1.1 without the files already included with Windows 10 Creators', and see if that helps.
stax76
22nd March 2017, 15:26
@need4speed
If I understand correctly then your question is relates to x265.
@burfadel
I'm a bit clueless about nuget, all those dlls come from nuget which was only needed for the scripting feature, I don't think this creates a performance issue.
According to the Visual Studio CPU profiling feature the CPU load is due to message processing, I looked at the code that listens for messages, this code really don't do much, also only a couple of messages are received like WM_ENTERIDLE, I tried to make some tweaks and it helped a lot it seems which surprises me because all I did is removing 3 or 4 stack or field integer variables using literals instead. In my last test it showed most of the time 0 or 0.1 % no matter how many processes were running in parallel. I also changed the status update from 100 ms to 200 ms and replaced a delegate object creation in this time period with a static delegate object, the rest is probably just overhead windows creates which cannot be avoided, if you like you can also check how megui compares, I just ran the build/upload script so a new build will be online in a minute or two.
burfadel
22nd March 2017, 15:46
Thanks, I've got several encodes in queue, I'll run 1.4.1.1 overnight and see how it goes :).
Update: Just checked, so after a little over 50 minutes of running two encodes, CPU use is at 0 percent, and the CPU Time used is much lower for the same amount of time (even for the instance that wasn't loading the CPU)! So it seems the issue is fixed.
Is the update frequency of the status remain the same when Staxrip is down in the system tray? Even if it does I guess it's probably only a small fraction of CPU time.
Thanks! :)
burfadel
23rd March 2017, 03:45
It has been running non-stop for a smidgen under 12 hours:
http://i.imgur.com/kQRvS47.jpg
It's very much better! The little bit of CPU time (probably more accurately described as thread time) showing there is expected, so all good :).
lotnybartek
24th March 2017, 10:05
stax76 - I'm encoding for 2 years DVB-TS files without any problem - thank you. Now, there is one thing though...
Let's say I have two TS files. I add first file to StaxRip, set up all the details (QuickSync, Source is: 1080i25 to 1080p50, LA-VBR, BOB, Sound: Just Mux), push it to batch. Then, I add second file, set up everything the same as first file, push it to batch. Start the encoding.
My normal speed with this settings is around 110 fps/s. First file is encoding nicely with this speed. Second file is always encoding with half the speed of the first one - around 50-55 fps/s. I don't know why. Restarting application isn't enough. I need to restart my laptop - only then second file is encoding with normal speed.
Any hints?
burfadel
25th March 2017, 05:08
The new test build 1.4.1.3 has the CPU use of the second process going back to 2-4 percent constant, even in the system tray. I also notice the display rate of the info (such as encoding) updates extremely quickly with 1.4.1.3, the display rate in 1.4.1.2 is perfectly fine. Updating it multiple times a second like 1.4.1.3 isn't any more informative :). Actually even a single process of Staxrip with 1.4.1.3 has noticeably more thread time than 1.4.1.2. A single process of Staxrip uses enough to see it hit 1 percent regularly in the task manager whilst encoding in the system tray, with 1.4.1.2 it may show 1 percent (rounded I assume) for one refresh cycle of the task list about once a minute, running two processes it just means that each one only shows it once ever minute or so.
mcjordan
29th March 2017, 15:22
Frank, see into this thread -> https://forum.doom9.org/showthread.php?t=174469
Myrsloik make a modern /experimental test/ version of ffms2 (so called ffms2000)
May be can you add to the next version?
lotnybartek
31st March 2017, 10:34
stax76 - I'm encoding for 2 years DVB-TS files without any problem - thank you. Now, there is one thing though...
Let's say I have two TS files. I add first file to StaxRip, set up all the details (QuickSync, Source is: 1080i25 to 1080p50, LA-VBR, BOB, Sound: Just Mux), push it to batch. Then, I add second file, set up everything the same as first file, push it to batch. Start the encoding.
My normal speed with this settings is around 110 fps/s. First file is encoding nicely with this speed. Second file is always encoding with half the speed of the first one - around 50-55 fps/s. I don't know why. Restarting application isn't enough. I need to restart my laptop - only then second file is encoding with normal speed.
Any hints?
Bump.
burfadel
1st April 2017, 02:18
I forgot to mention, the second process of Staxrip doesn't start chewing the CPU straight away, it may take 30 minutes. It only happens when there are two instances open, one instance doesn't have any of the CPU usage issues.
I guess considering there's now 8-core, 16-thread machines, making use of that is important. Multithreading the script chain only goes so far. Being able to run multiple encodes simultaneously within one instance of Staxrip I think could be hugely beneficial for those with high end recent multicore processors.
burfadel
3rd April 2017, 17:33
I went back to 1.4.1.3, it actually seems to work great most of the time, and the display update is fine too.
The CPU use rarely goes up, however if you leave two windows open (without being down in the system tray) whilst processing, on two occasions the CPU use went up quite signficantly with them. It might be Staxrip code related, it might also be NET Framework 4.7 related (new bug?). In any case, sorry for inconsistent reports. That said, the changes you have made up to and including 1.4.1.3 are great! In fact, I have had two encode processes running for about 30 hours now non-stop, over multiple encodes, with it down in the system tray (only occasionally opening them and looking), and the CPU time used is very much less than any previous staxrip. Visibly in task manager it only uses a bit of CPU time when it goes through the process of doing the steps involved with starting and finishing an encode, and the amount is very minimal, expected, and unavoidable. When an encode is running, the usage is so low it doesn't register! This is much better than the 2-4 percent no matter what with the older versions. Thanks :).
need4speed
4th April 2017, 06:07
Hi all,
lately I am having issues with transcoding E-ac3 to AAC.
the log reports at beginning:
2: EAC3, English, 5.1 channels, 48kHz
"ENG E-AC3 5.1 640 Kbs"
3: Subtitle (SRT), English, "ENG Subs"
Bitstream parsing for track 2 failed.
Demuxing this track may still produce correct results - or not.
Track 2 is used for destination file "Legion 01x08 AMZN_out1.m4a".
This audio conversion is not supported.
and more..
Audio encoding using eac3to 3.31 x86
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
C:\Portable\StaxRip-x64-1.4.1.1-test\Apps\eac3to\eac3to.exe "D:\DA CONVERTIRE\Legion 01x08 AMZN_temp\Legion 01x08 AMZN.wav" "D:\DA CONVERTIRE\Legion 01x08 AMZN_temp\Legion 01x08 AMZN_out1.m4a" -quality=0.49 -normalize -down6 -progressnumbers
WAV, 5.1 channels, 0:49:08, 16 bits, 4608kbps, 48kHz
Reading WAV...
Writing WAV...
Creating file "D:\DA CONVERTIRE\Legion 01x08 AMZN_temp\Legion 01x08 AMZN_out1.m4a.pass1.wav"...
The original audio track has a constant bit depth of 16 bits.
Starting 2nd pass...
Reading WAV...
Reducing depth from 64 to 32 bits...
Encoding AAC <0.49> with NeroAacEnc...
Applying 3.5dB gain...
the output file seems to be ok, reported by mpc-hc as eac3 640kbs but once extracted mkvinfo is correctly reported as aac_lc 5.1.
Am I doing anything wrong?
Yups
7th April 2017, 19:22
After updating Windows 10 to the Creators update QSVEnc doesn't work anymore, is this a Staxrip or QSVEnc issue?
https://abload.de/img/errorf4sbh.png
edit: Solved by removing RTSS Rivatuner Statistics Server. Handbrake didn't even start. It might work with the newest RTSS, haven't tried yet.
Actually Afterburner itself was the culprit.
jordonb
8th April 2017, 23:15
Hi,
RE Staxrip,
I have used handbrake without issue except the time constraints to Take H.264 encoded Video and reduce the size using H.265. Staxrip works so much faster with my Nvidia 1070 I bought with using it for Hardware conversion in mind. I dont understand why AC3 seems to be the only 5.1 channel output. I would like to pass-through DTS-MA/DTS and Dolby TD when converting 264s to 265s using hardware. Any suggestions would be helpful and I would be more then happy to pay for a license. If Staxrip does not currently support any pass-through is there a way to mux/demux sound track and re-merge after the video is encoded without any timing issues? If that is possible what would I use? I'm also open to other programs and primarily Mint 18 16.04 XFCE with Windows 7 in Dual boot and plenty of large hard drives. You really hear the difference between AC3 and any other higher bitrate or loss-free codecs when you run 5.1.
stax76
12th April 2017, 14:51
@need4speed
You can try to ask in the eac3to thread, there is a moderator that knows a lot about this kind of issue.
@burfadel
Since then I made some changes (greatly simplified code, removed tray icon tooltip...), task manager should now show 0% most of the time if not always.
@lotnybartek
I remember having experienced qs performance drops same or similar, this looks more like a driver problem and can probably be reproduced without staxrip, maybe rigaya can help you with it.
Myrsloik make a modern /experimental test/ version of ffms2 (so called ffms2000)
Seem to work fine by just replacing the files, no breaking changes.
@ users not using creators update
the last test build runs only with Win 10 creators update because it requires .NET 4.7, Microsoft says following:
The .NET Framework 4.7 is available for Windows 10 Creators Update today. We expect to release it for earlier versions of Windows pretty soon. We’ll make an announcement when we have the final date.
.NET 4.7 has various High DPI improvements and High DPI is a staxrip feature that took a great amount of time to learn and implement so it's a topic of great interest for me, if MS don't release .NET 4.7 for Win 7 in a reasonable time frame, I promise to port it back to .NET 4.6.2 if a few people request it.
Taurus
12th April 2017, 21:05
the last test build runs only with Win 10 creators update because it requires .NET 4.7
Hmmh, doing fine here on my Win7 64bit.....:confused::D
fredlkrue
13th April 2017, 02:59
Hmmh, doing fine here on my Win7 64bit.....:confused::D
Same here; please continue supporting Starxrip under Windows 7.
stax76
13th April 2017, 12:43
I changed it back to 4.6.2. One weird issue I have now is a giant size mouse pointer hovering over the link labels in the main dialog.
Atlantis
14th April 2017, 02:26
1- What script to use to convert HDR to SDR video?
2- How to convert HDR to HDR? There is a HDR video when I compress it with x265, the HDR metadata seems to disappear.
Magik Mark
14th April 2017, 03:38
stax,
Can you pls check. Opting for "shutdown" after encoding doesn't work in the "Creative Update" of windows 10 aka Windows 10 Redstone 2
stax76
14th April 2017, 11:37
@Atlantis
Here is a thread about the topic: https://forum.doom9.org/showthread.php?t=174389
@Magik Mark
Next build will use the shutdown CLI tool instead of WMI. I've tested it successfully on Win 10 creators update and Win 7.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.