StaxRip 2.0 Support Thread

[44vince44]

Originally Posted by Atlantis

Thanks. Staxrip should change the behavior. The mod warning should be based on the output resolution and not the input resolution.

For the mod check, Staxrip traces video dimensions though the crop feature (meaning: the values of crop defined in the crop window) and though the resize feature (meaning: the values you set in the middle of the main window.

Any filter manually inserted, that changes geometry will not be taken into account. E.g:
-other crop filter
-other resize filter
-Addborder filter
-flip, rotate filters

I agree, this is not good. StaxRip should check the same way it gets the information in the preview window and in the info menu.

But in the meantime, use the Mod2 workaround, I've processed hundreds of clips like that.

[44vince44]

The above issue is fixed in Beta v2.1.4.2

[Dann0245]

[Sorry, my bad English]

There is an issue in multi-pass encode.

When I do x265 three pass encode, the order/sequence of each pass is
--pass 1
--pass 2
--pass 3

The correct order/sequence should be
--pass 1
--pass 3
--pass 2

The issue happen in StaxRip-x64-2.1.3.0-stable and StaxRip-x64-2.1.4.2-Beta.

I don't see this issue in StaxRip-x64-2.0.6.0-stable.

[Atlantis]

(The above issue is fixed in Beta v2.1.4.2) Great. You mean Staxrip now looks at the real output resolution for mod checking? Since I don't install beta, I wont see it immediately.

[jlw_4049]

Originally Posted by Atlantis

(The above issue is fixed in Beta v2.1.4.2) Great. You mean Staxrip now looks at the real output resolution for mod checking? Since I don't install beta, I wont see it immediately.

The betas are usually stable

Sent from my SM-G986U1 using Tapatalk

[Patman]

Originally Posted by Dann0245

[Sorry, my bad English]



There is an issue in multi-pass encode.



When I do x265 three pass encode, the order/sequence of each pass is

--pass 1

--pass 2

--pass 3



The correct order/sequence should be

--pass 1

--pass 3

--pass 2



The issue happen in StaxRip-x64-2.1.3.0-stable and StaxRip-x64-2.1.4.2-Beta.



I don't see this issue in StaxRip-x64-2.0.6.0-stable.

Are you sure?

[Dann0245]

Originally Posted by Patman

Are you sure?

Yeah!

--pass 1 is first pass, creates stats file, NUL output.

--pass 2 is last pass, does not overwrite stats file, writes the output.

--pass 3 is Nth pass, overwrites stats file from pass 1, or previous pass 3 (4th, 5th pass encode), NUL output.


So the order/sequence when I run command line is
--pass 1
--pass 3
--pass 2

And 5th pass
--pass 1
--pass 3
--pass 3
--pass 3
--pass 2



StaxRip-x64-2.1.4.2-Beta, with three pass encode, the current order/sequence is

--pass 1, creates stats file.
--pass 2, does not overwrite stats file (No thing was improved), NUL output.
--pass 3, overwrites stats file, writes the output (but after pass 2).

(Or I just miss something?)

[Patman]

Originally Posted by Dann0245

Yeah!

--pass 1 is first pass, creates stats file, NUL output.

--pass 2 is last pass, does not overwrite stats file, writes the output.

--pass 3 is Nth pass, overwrites stats file from pass 1, or previous pass 3 (4th, 5th pass encode), NUL output.


So the order/sequence when I run command line is
--pass 1
--pass 3
--pass 2

And 5th pass
--pass 1
--pass 3
--pass 3
--pass 3
--pass 2



StaxRip-x64-2.1.4.2-Beta, with three pass encode, the current order/sequence is

--pass 1, creates stats file.
--pass 2, does not overwrite stats file (No thing was improved), NUL output.
--pass 3, overwrites stats file, writes the output (but after pass 2).

(Or I just miss something?)

Thx, will be changed in next beta.

[44vince44]

From the documentation:

--pass <integer>
Enable multi-pass rate control mode. Input is encoded multiple times, storing the encoded information of each pass in a stats file from which the consecutive pass tunes the qp of each frame to improve the quality of the output. Default disabled

1. First pass, creates stats file
2. Last pass, does not overwrite stats file
3. Nth pass, overwrites stats file

Range of values: 1 to 3

Are you sure it means that second pass is the LAST pass ? Please confirm it before code is changed.
Is it only for x265 or also x264 too ?

EDIT: it appears confirmed, the x264 docs show the same thing: x264 follows the same scheme: pass "2" means always the LAST pass
So this affects x265 and x264 as well


From x264 docs:

--pass has three settings:
1: Create a new stats file. Use this on the first pass.
2: Read the stats file. Use this on the final pass.
3: Read the stats file, and update it as well.

So if you want to do a 2-pass operation,
1st command will use --pass 1
2nd command will use --pass 2

And if you want to use a 3-pass operation,
1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 2

And if you want to use a 5-pass operation,
1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 3
4th command will use --pass 3
5th command will use --pass 2

I guess this confirms exactly what Dann0245 said. Thanks Dann0245!

[Dann0245]

Originally Posted by Patman

Thx, will be changed in next beta.

Great news.

Originally Posted by 44vince44

From the documentation:



Are you sure it means that second pass is the LAST pass ? Please confirm it before code is changed.
Is it only for x265 or also x264 too ?

EDIT: it appears confirmed, the x264 docs show the same thing: x264 follows the same scheme: pass "2" means always the LAST pass
So this affects x265 and x264 as well


From x264 docs:


So if you want to do a 2-pass operation,
1st command will use --pass 1
2nd command will use --pass 2

And if you want to use a 3-pass operation,
1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 2

And if you want to use a 5-pass operation,
1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 3
4th command will use --pass 3
5th command will use --pass 2

I guess this confirms exactly what Dann0245 said. Thanks Dann0245!

x264 and x265 do the same.

I was confused when the first time encode 3 pass.

Some google search and found this post from 2013, then I figured out how strange the number go with the operation.

Originally Posted by sneaker_ger

If the stats file is not updated then the pass did nothing to improve the following pass. So if you want to do e.g. 5 passes you would use:

--pass 1
--pass 3
--pass 3
--pass 3
--pass 2 (or --pass 3)

That's all there is to it. But that's for x264(cli), no clue about HandBrake.

[Patman]

Originally Posted by 44vince44

From the documentation:



Are you sure it means that second pass is the LAST pass ? Please confirm it before code is changed.
Is it only for x265 or also x264 too ?

EDIT: it appears confirmed, the x264 docs show the same thing: x264 follows the same scheme: pass "2" means always the LAST pass
So this affects x265 and x264 as well


From x264 docs:


So if you want to do a 2-pass operation,
1st command will use --pass 1
2nd command will use --pass 2

And if you want to use a 3-pass operation,
1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 2

And if you want to use a 5-pass operation,
1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 3
4th command will use --pass 3
5th command will use --pass 2

I guess this confirms exactly what Dann0245 said. Thanks Dann0245!

I found it in the docs from x264 and x265 too, so I've confirmed the changes. But thx for your investigation on that @44vince44

[44vince44]

Only (and always) trying to help Patman !!! ;-)

[NikosD]

Just a new VCEEnc v6.03 version
https://github.com/rigaya/VCEEnc/rel...cC_6.03_x64.7z

[NikosD]

@stax76

Hello Frank.

I'm trying to experiment with VCEEnc v6.03 using large uncompressed files and CBR/VBR modes and I see that StaxRip calculates arbitrarily --cbr and --vbr to a value of 4194299 which exceeds maximum supported by device.

How is this calculated internally from StaxRip and how can I change it ?

Because after --cbr/ -- vbr been set to 4194299 by StaxRip automatically, VCEEnc complains and has a fallback to 2147483 kbps which is still enormous.

Haven't touched yet Max Bitrate and VBV Bufsize which they are still at the default 20000 kbps but due to --cbr/--vbr 4194299 the output is 2147483 kbps (!)

[44vince44]

@NikosD:
when you set Mode = CBR or VBR, you need to close the encoder options window, and return to the main window.
There you'll notice that under "Target", you have two new values that you can modify: size and Video Bitrate. Change the value of Video Bitrate there.

[NikosD]

Originally Posted by 44vince44

...There you'll notice that under "Target", you have two new values that you can modify: size and Video Bitrate. Change the value of Video Bitrate there.

I tried that as I remembered that it was working for Intel's QSVEnc which was my first HW encoder, but this time it didn't work.
StaxRip didn't leave me change the values.
But if you say so, I'll try again when I go home and report back.

[NikosD]

Originally Posted by 44vince44

@NikosD:
when you set Mode = CBR or VBR, you need to close the encoder options window, and return to the main window.

Yes, of course!
By closing the options window, allows you to change the values in the main window.
I had forgotten it, it's been a while since my last HW encoding attempt.
Thank you.

BTW, the support of VCEEnc and all the other HW encoders (QSVEnc, NVEnc) is impressive regarding options and parameters.
It's almost everything inside!

[BobbyBoberton]

Originally Posted by 44vince44

From the documentation:



Are you sure it means that second pass is the LAST pass ? Please confirm it before code is changed.
Is it only for x265 or also x264 too ?

EDIT: it appears confirmed, the x264 docs show the same thing: x264 follows the same scheme: pass "2" means always the LAST pass
So this affects x265 and x264 as well


From x264 docs:


So if you want to do a 2-pass operation,
1st command will use --pass 1
2nd command will use --pass 2

And if you want to use a 3-pass operation,
1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 2

And if you want to use a 5-pass operation,
1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 3
4th command will use --pass 3
5th command will use --pass 2

I guess this confirms exactly what Dann0245 said. Thanks Dann0245!

The answer to this is probably yes but I want to make sure that there is no real difference between

1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 3
4th command will use --pass 3
5th command will use --pass 2

and

1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 4
4th command will use --pass 5
5th command will use --pass 2

right? because I have definitely used integers higher than 3 for passes before and I'm curious if its just the same thing written a different way.

thanks

[44vince44]

Originally Posted by NikosD

Yes, of course!
By closing the options window, allows you to change the values in the main window.
I had forgotten it, it's been a while since my last HW encoding attempt.
Thank you.

You're welcome!

Originally Posted by BobbyBoberton

The answer to this is probably yes but I want to make sure that there is no real difference between

1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 3
4th command will use --pass 3
5th command will use --pass 2

and

1st command will use --pass 1
2nd command will use --pass 3
3rd command will use --pass 4
4th command will use --pass 5
5th command will use --pass 2

right? because I have definitely used integers higher than 3 for passes before and I'm curious if its just the same thing written a different way.

There is no documentation for switches --pass 4 --pass 5.
Your experience with those means that --pass 4 and --pass 5 would be unofficially supported as --pass 3.

If switches --pass 4 and --pass 5 perform a pass, by reading current stats and updating it, that would mean that they are acting as --pass 3.

Staxrip uses the syntax that is documented, and I suggest you do the same, for obvious reasons!

[44vince44]

Note for the multiple --pass 3 users: read this (link at the bottom of this post) old thread involving a developer of x264 stating that it is a USELESS waste of time.
He explains that either you perform a two pass scheme with switch --slow-firstpass, or perform a three pass scheme with only ONE --pass 3 pass, is almost the same, and doing more than one --pass 3 pass is a waste of time.
In other words:

Either you do this:
pass 1 with --slow-firstpass
pass 2

or do that:
pass 1
pass 3
pass 2

But that is a waste of time:
pass 1
pass 3
pass 3 again
pass 2

He says doing more than one pass 3 is for "Heating your house if your heater is broken."
And he recommends the two pass solution with --slow-firstpass as the best one.


He explains also that they implemented the updating of stats (i.e. the feature in pass 3) for reasons other than improving quality at every stats updating pass. It was not implementing "pass 3", it was implementing stats updating for many reasons other than "pass 3".

You should read it, who more than a x264 developer knows that kind of information?
Link for the discussion.