StaxRip 2.0 Support Thread

[Revan654]

Thanks again for the new release.
IIUC the new update removes the beta from the name, so it's the first 2.0 stable release.

Does QSVEncC work with Win 10 October 2018 update eventually ?

I'll probably give it a try on two days using Skylake H.265 at work.

Have no idea, I could never get quicksync to work. It requires to many hoops to jump through to get it to work. I still hasn't been able to install newer Nvidia drivers on Windows 10 2018 update.

[NikosD]

Have no idea, I could never get quicksync to work. It requires to many hoops to jump through to get it to work. I still hasn't been able to install newer Nvidia drivers on Windows 10 2018 update. Happy New Year to everyone!

I downloaded StaxRip 2.0 today and started to run a few QSVEncC tests on my Haswell system (Win 10 ver 1809 build 17763.195) and iGPU HD 4400 (Drivers: 20.19.15.5058 MediaSDK Hardware API v1.20)

First of all, during installation, the StaxRip's installation stopped completely in order to force me to install FFTW (!)

Why ?

I saw that a filter needs that library, but I may not ever use this particular filter, so why is this installation mandatory in order to proceed to the StaxRip installation ?

I tried to install it from StaxRip by pressing the button, like AviSynth+, but the button didn't work and I had to google it in order to find the DLL.

Please, fix the button and remove it completely from the mandatory installations of StaxRip.

After StaxRip's installation I did some tests with QSVEncC v3.17, the built-in StaxRip version.

All "Decoders" options worked, except of the most interesting aka the fastest and with lower CPU utilization which is of course the "QSVEnc Intel".
StaxRip gave me a message of missing DLL files which I could see them all inside the folder - nothing was missing.

So, I downloaded the original files from Rigaya's repository and tried again by replacing your DLL files inside StaxRip.

It worked like a charm (!)

So, my friend Revan654, I compared the DLL files inside your StaxRip distribution with the original source DLL files from rigaya and I was shocked (!)

Your DLL files are x2 - x3 times bigger!

I checked them with VirusTotal site and fortunately it was not a virus.

But definitely something really, really bad is happening with ALL your DLL files for both hardware encoders of rigaya (NVEnc, QSVEnc)

For reasons unknown to me, it seems that VCEEnc version of StaxRip uses the right DLLs.

So, please RE-DOWNLOAD everything from rigaya's repository and all hardware encoders will work like a charm on every Windows 10 PC.

Thank you!

[minda76]

Hello,
QSVEnc still not working for me:

NullReferenceException (2.0.0.0)

Object reference not set to an instance of an object.

System.NullReferenceException: Object reference not set to an instance of an object.
at StaxRip.QSVEnc.EncoderParams.OnValueChanged(CommandLineParam item)
at StaxRip.BasicVideoEncoder.ImportCommandLine(String commandLine, CommandLineParams params)

[paauw]

Same over here, even after updating QSVencc from Rigaya latest version 3.17

[Revan654]

Happy New Year to everyone!

I downloaded StaxRip 2.0 today and started to run a few QSVEncC tests on my Haswell system (Win 10 ver 1809 build 17763.195) and iGPU HD 4400 (Drivers: 20.19.15.5058 MediaSDK Hardware API v1.20)

First of all, during installation, the StaxRip's installation stopped completely in order to force me to install FFTW (!)

Why ?

I saw that a filter needs that library, but I may not ever use this particular filter, so why is this installation mandatory in order to proceed to the StaxRip installation ?

I tried to install it from StaxRip by pressing the button, like AviSynth+, but the button didn't work and I had to google it in order to find the DLL.

Please, fix the button and remove it completely from the mandatory installations of StaxRip.

After StaxRip's installation I did some tests with QSVEncC v3.17, the built-in StaxRip version.

All "Decoders" options worked, except of the most interesting aka the fastest and with lower CPU utilization which is of course the "QSVEnc Intel".
StaxRip gave me a message of missing DLL files which I could see them all inside the folder - nothing was missing.

So, I downloaded the original files from Rigaya's repository and tried again by replacing your DLL files inside StaxRip.

It worked like a charm (!)

So, my friend Revan654, I compared the DLL files inside your StaxRip distribution with the original source DLL files from rigaya and I was shocked (!)

Your DLL files are x2 - x3 times bigger!

I checked them with VirusTotal site and fortunately it was not a virus.

But definitely something really, really bad is happening with ALL your DLL files for both hardware encoders of rigaya (NVEnc, QSVEnc)

For reasons unknown to me, it seems that VCEEnc version of StaxRip uses the right DLLs.

So, please RE-DOWNLOAD everything from rigaya's repository and all hardware encoders will work like a charm on every Windows 10 PC.

Thank you!

Allot of filters use FFTW, Not just one or two. Even more on VapourSynth side. I have FFTW tied to AVS instead of any selected filter(Since System only allows One Filter), This removes the issue of possible null values, exit1 codes or filter not loading correctly.

Unless you know how the code work with every single file supplied & the source, I wouldn't be asking to remove things that could break the software.

Next time read the complete doc for Staxrip, since it outlines everything you need to know. The files are in the Support folder.

---

ffmpeg files are directly from ffmpeg website(and Most Up to date version & the core version). His Builds are likely built with only a few flags enabled(aka Only whats needed to run). I have no idea what flags he has enabled or disabled. Not to mention he has a habit of forgetting to add all the required files.

ffmpeg has dozens and dozens of flags that can be enabled or disabled.

ffmpeg can reach over 200Megs per file if you enabled everything.

NVEnc works perfectly fine with the supplied dll files, I already tested a few times.

QuickSync is a massive PIA due to how it gets enabled. You must pass certain checks (This is set in stone by Intel & your CPU) for QS to work 100% correctly. Each CPU & Motherboard is different when enabling QVS.

VCEEnc never gets any new functions, everything is pretty much the same since 2016 release.

------

Don't go around Saying there something wrong with the files when there clearly no issue with them.

All this is going to do is spread false information.

-----

Lastly you need to make sure you have fresh Settings file, if older Setting file is used then none of newer functions will work or know where certain folders are.

Everything is fully Tested before being released.

[Revan654]

Hello,
QSVEnc still not working for me:

NullReferenceException (2.0.0.0)

Object reference not set to an instance of an object.

System.NullReferenceException: Object reference not set to an instance of an object.
at StaxRip.QSVEnc.EncoderParams.OnValueChanged(CommandLineParam item)
at StaxRip.BasicVideoEncoder.ImportCommandLine(String commandLine, CommandLineParams params)

Run Check Hardware, if you get Error or not available Then your System does not have QS enabled. Staxrip will always return null value if it can't find QS. Since the hardware can not be enabled.

Don't bother with the intel SDK since it will not help in this type of scenario.

[NikosD]

Many things to resolve and correct, so let's start !

Unless you know how the code work with every single file supplied & the source, I wouldn't be asking to remove things that could break the software. I clearly didn't say to remove the FFTW completely, just from the mandatory installations of StaxRip v2.0.
Unless you say to me that StaxRip is unusable without FFTW, so we have to install FFTW in order for StaxRip to work (!)

Next time read the complete doc for Staxrip, since it outlines everything you need to know. The files are in the Support folder. In all other cases of StaxRip, when you press the install button, it just runs the installer or redirect you to the installer's site.
If an installer is not provided and run automatically, then instead of an install button you could have a link or mention the path for DLLs in order to install them manually.

ffmpeg files are directly from ffmpeg website(and Most Up to date version & the core version). His Builds are likely built with only a few flags enabled(aka Only whats needed to run). I have no idea what flags he has enabled or disabled. Not to mention he has a habit of forgetting to add all the required files.

ffmpeg has dozens and dozens of flags that can be enabled or disabled.

ffmpeg can reach over 200Megs per file if you enabled everything. It really doesn't matter how the files are produced and how big they are, for the user.
I only mentioned the size in order to say that your versions are a lot different.
The DLLs provided only need to work and the files provided by you do not work.
On the other hand the files provided by rigaya do work.

Maybe because the hardware encoders are his and not yours and probably he knows better his apps.
Maybe he has made custom compilations and the DLLs are special and not generic FFMPEG in order to work for his apps.

NVEnc works perfectly fine with the supplied dll files, I already tested a few times. How do you know that ? In the post above you replied to me that you couldn't install drivers for the nVidia card on Win 10 October 2018 Update.

QuickSync is a massive PIA due to how it gets enabled. You must pass certain checks (This is set in stone by Intel & your CPU) for QS to work 100% correctly. Each CPU & Motherboard is different when enabling QVS. You don't seem to understand the problem or you are pretending that you don't understand.
QSV works just fine and it can be detected by QSVEnc.
The problem is that QSVEnc is complaining about the DLLs regarding FFMPEG support.
The DLLs mentioned above.

Don't mess general QSV support in this discussion.
It's a completely different subject.

The DLLs of FFMPEG provided by StaxRip is the problem.

Don't go around Saying there something wrong with the files when there clearly no issue with them.

All this is going to do is spread false information. As explained above the DLLs are definitely wrong regarding QSVEnc support.
Because with your ffmpeg distribution DLL files, QSVEnc doesn't work but with rigaya's ffmpeg DLL files, QSVEnc does work.

All in all, the solution for QSVEnc's malfunction using StaxRip with Win 10 October 2018 Update, is just to use rigaya's original source DLLs and not generic FFMPEG files.

You have said a lot of times that you hadn't manage to make QSVEnc and NVEnc to work with Win 10 October 2018 update.

Well, I found out a very simple solution and I told you about in order to correct it.

It's so simple, where exactly is the problem ?

If you don't like my solution to the problem (to include original DLLs from rigaya) and you want to use generic FFMPEG files, please provide a working solution because StaxRip doesn't work as is.

And please stop saying wrong things like QSV support of Win 10 October 2018 update or QSV support of motherboards.
This has nothing to do with the problem.

Sometimes it's much easier and efficient to go by the book and just copy the original repository of third party apps, instead of trying to do it your way, unless you are in a position to test it - and you aren't as you have already said.

[paauw]

I checked the qsvencc --check-hw..it said it is enabled...b.t.w. staxrip 1.7 till 2 beta are working fine

if i choose the intel h265 with the stax 2.000 after a fresh install it also comes with the error if i choose intel h265 profile

if i ignore it en run the movie conversion it crashes when starting with qsvenc...the pre jobs run fine









NullReferenceException (2.0.0.0)

Object reference not set to an instance of an object.

System.NullReferenceException: Object reference not set to an instance of an object.
at StaxRip.QSVEnc.EncoderParams.OnValueChanged(CommandLineParam item)
at StaxRip.QSVEnc.Encode()
at StaxRip.GlobalClass.ProcessVideo()
at System.Threading.Tasks.Parallel.<>c__DisplayClass4_0.<Invoke>b__0()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at StaxRip.GlobalClass.ProcessJob(String jobPath)
at StaxRip.GlobalClass.ProcessJobs()

[minda76]

QSVEnc

Checked hardware too:

Success: QuickSyncVideo (hw encoding) available

[AMED]

Just wondering if anybody knows an easyish way of automating the copying the network located source file in to the local staxrip temp folder so it can be processed a little faster and not encoded over the local network.

[Atak_Snajpera]

Just wondering if anybody knows an easyish way of automating the copying the network located source file in to the local staxrip temp folder so it can be processed a little faster and not encoded over the local network.

It won't be processed faster. 100Mbps network is more than enough for encoding blu-ray movie (~40Mbps). I doubt that your pc can encode 1920x1080 frames faster than 2xrealtime (48fps+) with x264/x265.

[AMED]

ahh ok, thanks for the answer.

I thought copying the source locally would speed up the demuxing, FFMS indexing and other staxrip functions. Then again probably time for the copy would offset the gains if any.

[Revan654]

Many things to resolve and correct, so let's start !

I clearly didn't say to remove the FFTW completely, just from the mandatory installations of StaxRip v2.0.
Unless you say to me that StaxRip is unusable without FFTW, so we have to install FFTW in order for StaxRip to work (!)

In all other cases of StaxRip, when you press the install button, it just runs the installer or redirect you to the installer's site.
If an installer is not provided and run automatically, then instead of an install button you could have a link or mention the path for DLLs in order to install them manually.


It transfer the files to System Directory, Just Incase. I updated the Source code with additional syntax(Code is on Github).



It really doesn't matter how the files are produced and how big they are, for the user.
I only mentioned the size in order to say that your versions are a lot different.
The DLLs provided only need to work and the files provided by you do not work.
On the other hand the files provided by rigaya do work.



ffmpeg is ffmpeg, Only thing that differs is what switches are enabled during compile time and how new the source code is. ffmpeg gets re-built every day. It could be a bug that happened.

They work fine for NVEnc, ffmpeg could have removed QS support from the default files. It's doubtful since there dev site still has it listed as active. Might be an issue at your end. Plus additional files like intel SDK will create problems.


Maybe because the hardware encoders are his and not yours and probably he knows better his apps.
Maybe he has made custom compilations and the DLLs are special and not generic FFMPEG in order to work for his apps.

How do you know that ? In the post above you replied to me that you couldn't install drivers for the nVidia card on Win 10 October 2018 Update.



Not sure you understand how programming works or how ffmpeg code works.


You don't seem to understand the problem or you are pretending that you don't understand.
QSV works just fine and it can be detected by QSVEnc.
The problem is that QSVEnc is complaining about the DLLs regarding FFMPEG support.
The DLLs mentioned above.



I don't think your comprehending what I'm saying.



You have said a lot of times that you hadn't manage to make QSVEnc and NVEnc to work with Win 10 October 2018 update.

I never said that, I said I could get drivers installed. Two very different things. If you actually read my comment I said I tested NVEnc and it worked perfectly.



And please stop saying wrong things like QSV support of Win 10 October 2018 update or QSV support of motherboards.
This has nothing to do with the problem.

Sometimes it's much easier and efficient to go by the book and just copy the original repository of third party apps, instead of trying to do it your way, unless you are in a position to test it - and you aren't as you have already said.

again your not comprehending what I'm saying.

[Revan654]

QSVEnc

Checked hardware too:

Success: QuickSyncVideo (hw encoding) available


This is null value for not being able to start-up intel Encoder or able to find the Encoder path.

since you can do Checked hardware you can rule out path issue.

Have your tried to input the commandline into cmd prompt to see if QVSEnc will run without StaxRip? If it does, Then we can rule out QSVEnc, if it doesn't then the issues is something to do with your setup or QVSEnc.

Try other decoders and see if anything changes.

[Revan654]

For those using AVS, This only effects anyone who has AVX2 only CPU's. Which effects Skylake(6700)+ CPU's. Not sure what CPU's on AMD side are AVX2 Only.

- If you have a CPU with only AVX2 support, Any AVX coded filter will not work. You will get a return code of no module found, no entry point found or no platform was found.

For example: FFT3DGPU. Which also effects the usage of XAA, DeNoiseMF & MCTemporalDenoise. They could be more, but I haven't gone through each one filter yet.

If one of the filters you use is effected my suggestion would be heading to Vapoursynth and see if it's been ported or try to find a different filter to use.

[paauw]

if i use execute command (encoder option) line with intel h265 encoder option it starts converting but if i use de default 'next' it comes with the error mentioned

ps..

x265 is working fine so others work

[Revan654]

if i use execute command (encoder option) line with intel h265 encoder option it starts converting but if i use de default 'next' it comes with the error mentioned

ps..

x265 is working fine so others work

x265 is pure software based, so it will run no matter what unless you get a bad filter into the mix. Intel is both software & hardware based on the options you select. if it doesn't like one flag it will return null value which creates your issue. In Programming null usually crashes the program. Debugging hardware encoders are harder to do. Plus I don't have QS enabled PC, I kind of limited of type of help I can offer.

Have your checked to make sure your CPU/iGPU can encode HEVC? Some can only do AVC Encoding. Others can only do decoding.

QS is PIA sometimes get up and running, Even on Handbrake support there many that can't get QS to work.

1. Check both Frameservers, it could just be an issue with AVS or VS and how the script is sent.

2. If you haven't update your iGPU drivers, Update the drivers to latest version.

3. Last thing could be something in VS2017/dotnet, I have no way to test & debug QVSEnc at my end.

The Encoding process hasn't been touched since 1.7. The flags & everything else looks the same based off the doc. The dev tool helper that reads each encoder and reports the changes is not reporting any kind of new or remove additions.

It would be a good idea to upload your log.

[Revan654]

Tweaked a few functions in the source for QVSEnc, Anyone having issues can try to compile it and report the outcome.

[paauw]

@Nikosd

maybe not intended but your reply is to aggressive and Revan deserves more respect for taking staxrip to the next level...and yes troubleshooting could be better but lack to own intel/qsv does not help...

@revan

QSV is working fine till 2.0 (from 1.7 till beta) the problem is not qsv because the commandline works.

Something inside of staxrip must have changed after 2.0 beta in the gui or in the call to start qsv .

as i mentioned , choosing the qsv profile (intel h265) the first time without starting qsv already brings up the error...

is there something changed in the gui or in the way you start/choose the profile in the gui after beta2 of staxrip ?

[Zetti]

MKVToolNix v30.0.0 is released.

[Revan654]

@Nikosd

maybe not intended but your reply is to aggressive and Revan deserves more respect for taking staxrip to the next level...and yes troubleshooting could be better but lack to own intel/qsv does not help...

@revan

QSV is working fine till 2.0 (from 1.7 till beta) the problem is not qsv because the commandline works.

Something inside of staxrip must have changed after 2.0 beta in the gui or in the call to start qsv .

as i mentioned , choosing the qsv profile (intel h265) the first time without starting qsv already brings up the error...

is there something changed in the gui or in the way you start/choose the profile in the gui after beta2 of staxrip ?

The core gui is untouched, The process commands that sends out the command is also untouched. Basically the entire code for QSVEnc is untouched other then a few flag updates. Those would not create those issues. Since NVEnc got the same flags and runs. It has to be something package file, dotnet and how it all links up.

I could revert back to 1.7 code and see if that helps. I not sure if that would help or not. The commands called are the same, I compared the two codes last night and there the same. It's likely something in dotnet broke it.

Current Code to call the process:
Using proc As New Proc
proc.Header = "Video encoding"
proc.Package = Package.QSVEnc
proc.SkipString = " frames: "
proc.File = "cmd.exe"
proc.Arguments = "/S /C """ + Params.GetCommandLine(True, True) + """"
proc.Start()
End Using

Original Code:

Using proc As New Proc
proc.Header = "Video encoding"
proc.Package = Package.QSVEnc
proc.SkipString = " frames: "
proc.File = "cmd.exe"
proc.Arguments = "/S /C """ + Params.GetCommandLine(True, True) + """"
proc.Start()
End Using

[paauw]

Hi Revan

I tested staxrip 2 with an old qsv enc and its dll's ...same error...i updated .dot 4.8 preview ...same error
here's my log file of staxrip

[Zetti]

MKVToolNix v30.1.0 is released.

[Revan654]

Hi Revan

I tested staxrip 2 with an old qsv enc and its dll's ...same error...i updated .dot 4.8 preview ...same error
here's my log file of staxrip

I found the issue, I had to go line by line. to find it. It was one of the filters throwing in null value if it was used or not. The next update will have this fixed or re-compile it from source.

[paauw]

Thanx revan...i must admit that my next step intended to check the option changes from the encode options...

How can i recompile it ...is that easy ?

[Revan654]

Thanx revan...i must admit that my next step intended to check the option changes from the encode options...

How can i recompile it ...is that easy ?

Install VS 2017.

- At the Top Select Release & x64 (if it isn't already selected)

Click on the Build tab & Select Build Staxrip. The software will do the rest of the work.

Make sure you read the changelog to add any additional filters that have been added or removed since the last release.

Remember this is Dev Build, Sometimes there can be be bugs or hiccups in the code.

----

hmm this just showed up on my PC:

https://i.imgur.com/5M56jMD.png

It not longer says Error.

I guess QS is now working on my PC, I don't have H.265 encodinig functon since Intel didn't create that feature for my CPU/iGPU.

[paauw]

well never done this before but i managed to instal VS2017..
clone your git and started to build...but unfortunitely it gave errors...see screenshot...any ideas or should i just wait til staxrip 2.0.0.1

[Arhu]

I'm having various problems in 2.0 related to the length of temporary folders / file names. It was fine in the last 2.0 beta release.

Before, temporary folder names were truncated like this: "Very Long Fil..._temp". Now in staxrip 2.0 they have this format: "Very Long Filename that really is way too long_temp". As a result, often ffmpeg can't find some wrongly demuxed files. I tried using older versions of MediaInfo / mkvtoolnix, but that didn't really help. Anything I can do on my end (besides renaming source files to make them shorter)?

[Revan654]

I'm having various problems in 2.0 related to the length of temporary folders / file names. It was fine in the last 2.0 beta release.

Before, temporary folder names were truncated like this: "Very Long Fil..._temp". Now in staxrip 2.0 they have this format: "Very Long Filename that really is way too long_temp". As a result, often ffmpeg can't find some wrongly demuxed files. I tried using older versions of MediaInfo / mkvtoolnix, but that didn't really help. Anything I can do on my end (besides renaming source files to make them shorter)?

Many of the cli lines need to be updated, This is specially true for the decoders.

Anything that gets passed to the cli just make sure it's in quotes which will solve most of the problem. The cli doesn't like spaces and such.

I'll likely add an option in the next update for this.

Also enable LongPath, How to do that is posted a few pages back.

[Revan654]

well never done this before but i managed to instal VS2017..
clone your git and started to build...but unfortunitely it gave errors...see screenshot...any ideas or should i just wait til staxrip 2.0.0.1

Can't view the image.

Don't upload to the site, Upload to imgur or something like that. Files need approval for others to see. Your log still hasn't been approved.

[paauw]

https://imgur.com/a/vbBiBgp



hope this helps

[K.i.N.G]

Is there any way to manually add an audio encoder?
I'd like to add OpusEnc.exe ... since it results in better quality than the ffmpeg included one (according to ffmpeg documentation).

[Revan654]

https://imgur.com/a/vbBiBgp



hope this helps

It's likely you have the strict option enable which throw up an warning if it doesn't follow it's guideline.

Right click on Staxrip on right menu -> Properties

Compile Tab -> Disable all warnings.

FYI, I don't use github app when import project. I do it all manually, I found the github to be a giant PIA to use and creates a bunch of issues.

[Revan654]

Is there any way to manually add an audio encoder?
I'd like to add OpusEnc.exe ... since it results in better quality than the ffmpeg included one (according to ffmpeg documentation).

The audio should be very similar to one another since, OpusEnc libs are used to compile ffmpeg.

----

Technically yes, You have to create command events and command cli. Not sure how well it will work in automation chain. You will have to disable the main audio function.

Just remember, Staxrip also has normalize audio functions and such. Not sure if OpusEnc has additional functions.

[paauw]

you were right the github clone was PIA...
i downloaded master.zip from github...opened the staxrip file
(had to install 4.7.2. sdk) and the build did go well...

I hope i did the right thing and copied the files in the bin directory of the unzipped masterfile (staxrip.exe and others) to your staxrop 2.0.0.0 directory and started staxrip...no more errors like before but when i started to encode it failed when it did try to start qsvencc with the message :

----------------------------- QSVEnc Error -----------------------------

H.265/HEVC isn't supported by your Hardware.



any suggestions ?

[paauw]

this is the message also

QSVEnc Error (2.0.0.0)

H.265/HEVC isn't supported by your Hardware.

StaxRip.ErrorAbortException: H.265/HEVC isn't supported by your Hardware.
at StaxRip.QSVEnc.Encode()
at StaxRip.GlobalClass.ProcessVideo()
at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at StaxRip.GlobalClass.ProcessJob(String jobPath)

[paauw]

is it also possible that paralel processing does not work anymore...?

[katzenjoghurt]

Thanks for keeping StaxRip alive, Revan!

I got the feeling that the colors aren't off in the video comparison tool any more when comparing an 8bit with am 10bit encoded movie - could that be?
If yes... great work!!

I got two other issues though with the tool...

1) After importing a bigger video file (like a 20GB AVC clip taken from a BluRay) the comparer seems to take a long break now where the application won't react for minutes.

2) For whatever reason source and encoded video are often (not always!) async by one frame now in the video comparison tool although frame count and fps are the same.
The same videos would show in sync when comparing with 1.7.0.6.
Would have loved to give you examples but I couldn't reproduce it with test clips.
But this could also be turned into a feature request - the ability to set a frame offset for each compared video would be something I always missed as I rarely had problems with async files in old StaxRip as well.

[Revan654]

you were right the github clone was PIA...
i downloaded master.zip from github...opened the staxrip file
(had to install 4.7.2. sdk) and the build did go well...

I hope i did the right thing and copied the files in the bin directory of the unzipped masterfile (staxrip.exe and others) to your staxrop 2.0.0.0 directory and started staxrip...no more errors like before but when i started to encode it failed when it did try to start qsvencc with the message :

----------------------------- QSVEnc Error -----------------------------

H.265/HEVC isn't supported by your Hardware.



any suggestions ?

Source files are Work in Progress, Assume you may run into a bug or two as progress goes on. Just have to re-check for updated files as progress goes on.

It's just part of programming, you fix one thing but breaks another.

[Revan654]

is it also possible that paralel processing does not work anymore...?

Depends on you expect to happen. It does encode, audio & video at the same time.

[Revan654]

Thanks for keeping StaxRip alive, Revan!

I got the feeling that the colors aren't off in the video comparison tool any more when comparing an 8bit with am 10bit encoded movie - could that be?
If yes... great work!!

I got two other issues though with the tool...

1) After importing a bigger video file (like a 20GB AVC clip taken from a BluRay) the comparer seems to take a long break now where the application won't react for minutes.

2) For whatever reason source and encoded video are often (not always!) async by one frame now in the video comparison tool although frame count and fps are the same.
The same videos would show in sync when comparing with 1.7.0.6.
Would have loved to give you examples but I couldn't reproduce it with test clips.
But this could also be turned into a feature request - the ability to set a frame offset for each compared video would be something I always missed as I rarely had problems with async files in old StaxRip as well.

I usually forget that app even exist at times. It has not been updated since 1.7.

- You are loading a massive file into the code, it takes time to index & cache that file. It uses FFVideoSource as the source filter using AVS.

- Many of offset is usually based off the codec, filter, or if the fps is off by .1 even if it doesn't show it in info data.

It's why it's usually a good idea to respec the video before encoding just incase something is off.

- There allot of elements to take into account like range, Depth, and the display. Most PC Monitors are only 8Bit. You will not get the full effect of 10Bit color.

[Forteen88]

@Revan654. When I used your Staxrip.2.0.0.0.x64, and "aq-mode" set to "Enabled", it still sets aq-mode to 2...
I hope you fix that, because I've gone over to use MeGUI instead (even though MeGUI produced a green video when using DGDec on a mpeg1-video, while Staxrip2.0 didn't (I don't know which mpeg-1 decoder it uses)).
Thanks in advance, if you fix that bug.

[videoh]

MeGUI produced a green video when using DGDec on a mpeg1-video DGDecNV does not support MPEG1. DGMPGDec (DGIndex + MPEG2Source) does support MPEG1.

[Forteen88]

DGDecNV does not support MPEG1. DGMPGDec (DGIndex + MPEG2Source) does support MPEG1.Thanks, but I don't think that I used DGDecNV, I used MeGUI:s default MPEG-1 decoder. I don't see DGDecNV in,
C:\Utils\MeGUI-2896-64\tools\dgindex

The only DLL in that directory is DGDecode.dll

[videoh]

If you can give me a link to the source file, I can look into it.

Does the file open when opening with DGIndex/DGDecode directly, rather than through MeGUI?

[Forteen88]

If you can give me a link to the source file, I can look into it.

Does the file open when opening with DGIndex/DGDecode directly, rather than through MeGUI?Download source from here, https://www5.zippyshare.com/v/1par8rZv/file.html

It's a very small video file, I just used it for test, so don't bother fixing that bug if it takes much time fixing it.

I don't know exactly what you mean, I think I saw something in MeGUI mentioning DGDec (but I'm not 100% sure) when encoding this video to x265-video with "One-click" encode mode.
Thanks.

[videoh]

Works fine using DGIndex/DGDecode standalone, so any issue you see must be MeGUI-related.

[Revan654]

@Revan654. When I used your Staxrip.2.0.0.0.x64, and "aq-mode" set to "Enabled", it still sets aq-mode to 2...
I hope you fix that, because I've gone over to use MeGUI instead (even though MeGUI produced a green video when using DGDec on a mpeg1-video, while Staxrip2.0 didn't (I don't know which mpeg-1 decoder it uses)).
Thanks in advance, if you fix that bug.

aq-mode in what Encoder. aq-mode doesn't give much details, since most encoders have aq-mode.

[Natty]

I got two other issues though with the tool...

1) After importing a bigger video file (like a 20GB AVC clip taken from a BluRay) the comparer seems to take a long break now where the application won't react for minutes.

2) For whatever reason source and encoded video are often (not always!) async by one frame now in the video comparison tool although frame count and fps are the same.
The same videos would show in sync when comparing with 1.7.0.6.
Would have loved to give you examples but I couldn't reproduce it with test clips.
But this could also be turned into a feature request - the ability to set a frame offset for each compared video would be something I always missed as I rarely had problems with async files in old StaxRip as well.
i have the same issue along with a few other bugs/issues but revan always replies stuffs like "nothing has been changed much" so i dont report the issues/bugs anymore.

[Forteen88]

aq-mode in what Encoder. aq-mode doesn't give much details, since most encoders have aq-mode.In x265-3.0_RC+10-672ce05_vs2017-AVX2 (msystem).7z

EDIT: Thanks videoh, for telling me. Then I can report to MeGUI-devs that there's a bug in their MPEG-1 conversion.