BD Rebuilder Beta - Bug Reports Only

[jdobbs]

I think the wait is over
5.08 is outThe issue is still there. It will probably have to be fixed by NVIDIA.

It's very obvious. Try this:

1. Run NVENCC with the --repeat-headers parameter
2. Open up Windows Task Manager and click on "Details"
3. Watch the memory usage for NVENCC.EXE.

The application's memory usage will continually rise (pretty quickly) until it eventually runs out and the app crashes. It's just more obvious on the 32 bit version because of 32 memory limitations.

[jdobbs]

Finished a remux and it seems to work
FF, REW and CHP skips
Even if you use the 64 bit version, the memory usage keeps growing (at least on my system). But the application is less likely to crash since 64 bit apps have much more memory available. I can use the --repeat-headers on the 64 bit version with a 2 1/2 hour movie and it will complete. But... the application is using about 600 Megabytes when it starts then slowly increases to point at which it is using over 2 GigaBytes when it finishes.

Who knows? It may act differently on your card and/or drivers.

[gonca]

Maybe a driver related issue, memory usage is constant at about 582 MB on my GTX1080ti
Driver is 445.87

[cartman0208]

I don't see a lot of memory growth, even on the 32bit version ... starts at 750MB and finishes with 850MB used by nvencc.exe

What I also noticed ... no matter what preset or rate factor ... the processing speed stays the same for a given resolution ... 4K is always around 75fps for me :cool:

Graphics driver was updated yesterday (451.48), but I'm not on Win10 May 2020 update yet, if that helps.

PS C:\WINDOWS\system32> U:\Temp\nvenc\NVEncC.exe --cqp 25 --codec h265 --preset quality --profile main10 --level 5.1 --output-depth 10 --max-bitrate 30000 --aq --aq-temporal --output-buf 128 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --colormatrix bt2020nc --colorprim bt2020 --transfer smpte2084 --max-cll "1000,0" --chromaloc 2 --output "U:\Temp\ALITA_BATTLE_ANGEL_temp\ALITA_BATTLE_ANGEL.hevc" --input "U:\Temp\ALITA_BATTLE_ANGEL_temp\ALITA_BATTLE_ANGEL.h265" --repeat-headers

--------------------------------------------------------------------------------
U:\Temp\ALITA_BATTLE_ANGEL_temp\ALITA_BATTLE_ANGEL.hevc
--------------------------------------------------------------------------------
NVEncC (x86) 5.08 (r1585) by rigaya, Jul 1 2020 14:48:28 (VC 1900/Win/avx2)
OS Version Windows 10 x64 (18363)
CPU Intel Core i7-6800K @ 3.40GHz [TB: 3.80GHz] (6C/12T)
GPU #0: GeForce GTX 1660 Ti (1536 cores, 1770 MHz)[2147483.64]
NVENC / CUDA NVENC API 9.1, CUDA 11.0, schedule mode: auto
Input Buffers CUDA, 16 frames
Input Info avcuvid: H.265/HEVC, 3840x2160, 24000/1001 fps
Vpp Filters copyDtoD
Output Info H.265/HEVC main10 @ Level 5.1
3840x2160p 1:1 23.976fps (24000/1001fps)
Encoder Preset quality
Rate Control CQP I:25 P:25 B:25
Lookahead off
GOP length 240 frames
B frames 3 frames [ref mode: disabled]
Ref frames 3 frames, MultiRef L0:auto L1:auto
AQ on
CU max / min auto / auto
VUI matrix:bt2020nc,colorprim:bt2020,transfer:smpte2084,chromaloc:topleft
MasteringDisp G(0.265000 0.690000) B(0.150000 0.060000) R(0.680000 0.320000)
WP(0.312700 0.329000) L(999.999975 0.000100)
MaxCLL/MaxFALL 1000/0
Others mv:auto repeat-headers

encoded 175440 frames, 76.88 fps, 7280.96 kbps, 6351.12 MB
encode time 0:38:02, CPU: 9.8%, GPU: 7.4%, VE: 99.2%, VD: 20.6%
frame type IDR 731
frame type I 731, total size 70.98 MB
frame type P 43860, total size 2313.22 MB
frame type B 130849, total size 3966.92 MB

Edit: 1080p runs at 175fps stable with above settings, no big memory increase either...

[Mike-uk]

I don't see a lot of memory growth, even on the 32bit version ... starts at 750MB and finishes with 850MB used by nvencc.exe

What I also noticed ... no matter what preset or rate factor ... the processing speed stays the same for a given resolution ... 4K is always around 75fps for me :cool:

Graphics driver was updated yesterday (451.48), but I'm not on Win10 May 2020 update yet, if that helps.


[CODE]
--------------------------------------------------------------------------------
U:\Temp\ALITA_BATTLE_ANGEL_temp\ALITA_BATTLE_ANGEL.hevc
--------------------------------------------------------------------------------


where is your --avhw to enable fully hardware encode ?

[cartman0208]

Forgot about it ...
Maybe it was auto detected?

from the help text...
--avhw use libavformat + hw decode for input

Does it matter what is used for decoding?
Just started another run ... not much of a difference in speed

[jdobbs]

Maybe a driver related issue, memory usage is constant at about 582 MB on my GTX1080ti
Driver is 445.87I'm using Driver 451.48, dated June 24th, 2020 on a GTX1660

[jdobbs]

I don't see a lot of memory growth, even on the 32bit version ... starts at 750MB and finishes with 850MB used by nvencc.exe

What I also noticed ... no matter what preset or rate factor ... the processing speed stays the same for a given resolution ... 4K is always around 75fps for me :cool:

Graphics driver was updated yesterday (451.48), but I'm not on Win10 May 2020 update yet, if that helps.



--------------------------------------------------------------------------------
U:\Temp\ALITA_BATTLE_ANGEL_temp\ALITA_BATTLE_ANGEL.hevc
--------------------------------------------------------------------------------
NVEncC (x86) 5.08 (r1585) by rigaya, Jul 1 2020 14:48:28 (VC 1900/Win/avx2)
OS Version Windows 10 x64 (18363)
CPU Intel Core i7-6800K @ 3.40GHz [TB: 3.80GHz] (6C/12T)
GPU #0: GeForce GTX 1660 Ti (1536 cores, 1770 MHz)[2147483.64]
NVENC / CUDA NVENC API 9.1, CUDA 11.0, schedule mode: auto
Input Buffers CUDA, 16 frames
Input Info avcuvid: H.265/HEVC, 3840x2160, 24000/1001 fps
Vpp Filters copyDtoD
Output Info H.265/HEVC main10 @ Level 5.1
3840x2160p 1:1 23.976fps (24000/1001fps)
Encoder Preset quality
Rate Control CQP I:25 P:25 B:25
Lookahead off
GOP length 240 frames
B frames 3 frames [ref mode: disabled]
Ref frames 3 frames, MultiRef L0:auto L1:auto
AQ on
CU max / min auto / auto
VUI matrix:bt2020nc,colorprim:bt2020,transfer:smpte2084,chromaloc:topleft
MasteringDisp G(0.265000 0.690000) B(0.150000 0.060000) R(0.680000 0.320000)
WP(0.312700 0.329000) L(999.999975 0.000100)
MaxCLL/MaxFALL 1000/0
Others mv:auto repeat-headers

encoded 175440 frames, 76.88 fps, 7280.96 kbps, 6351.12 MB
encode time 0:38:02, CPU: 9.8%, GPU: 7.4%, VE: 99.2%, VD: 20.6%
frame type IDR 731
frame type I 731, total size 70.98 MB
frame type P 43860, total size 2313.22 MB
frame type B 130849, total size 3966.92 MB

Edit: 1080p runs at 175fps stable with above settings, no big memory increase either...Part of that might be because you are using GOPs of 240 frames. That's 10 times larger than what it would need to be for a UHD-BD encode. The --repeat-headers would not be activated as often and would probably not hit the routine that causes the memory leak as often. Try adding --gop-len 24 and see what happens.

[Edit] Yeah. I just set the GOP length to 240 frames and it is barely growing at all... but, of course, that encode would fail to meet the UHD-BD standard. I would assume that it would also mean that as you attempt to fast forward, each picture step would jump 10 seconds instead of 1. The table used for these actions only logs IDR positions.

Finished a remux and it seems to work FF, REW and CHP skips
I just went back and looked at your post again as well... and you are also using the default 240 frame GOP. That's probably why you're not seeing the issue as well. You are only having to insert the SPS/VPS/PPS once every 10 seconds instead of once per second. The headers are only inserted on the IDR frame that begins a GOP.

[jdobbs]

Here's a look at memory usage at the start of an encode and then after 35,000 frames. Considering that a 2 hour movie would be 172,627 frames, you can see how this can become an issue.

[Mike-uk]

am i right in seeing nvencc uses SDK version 9.1, i think there is a version 10 now ??, unfortunatly that would mean we need to wait for nvencc to compile sdk 10 versions

mayby ask him if he intends to compile a SDK 10 verstion ? mayby that will solve the memory leak

What's new in Video Codec SDK 10
New H.264 NVENC presets for improved flexibility and granularity
Finer control of rate control modes
Use-case Setting (also referred to as Tuning information)
NVDEC Support for GA100

[jdobbs]

I think the bottom line for now is that I am going to have to insert the headers myself from within BD-RB, which will increase the overall job time by about 10 or 15 minutes. It's a shame, but based on the last response I saw, I have doubts that the issue is going to be addressed. Apparently no one except me is even attempting to create a UHD-BD that is standards compliant (at least with NVENCC), or the --repeat-headers issue would have been brought up long ago.

[gonca]

I should have checked the cmd line a little better
Still, 45 min encode and 15 min clean up for 4K movie isn't bad
By the way, username eddie haskell
Leave it to Beaver fan?

[Mike-uk]

how do you view if repeat headers worked ?? i tried another encoder that uses nvencc and added --repeat-headers and it started off allocating 1,2 gig of memory and stayed around there but no idea if headers are repeated

[jdobbs]

I should have checked the cmd line a little better
Still, 45 min encode and 15 min clean up for 4K movie isn't bad
By the way, username eddie haskell
Leave it to Beaver fan?I watched it after school when I was a kid. Eddie Haskell was quite a character -- I've been using that name for one thing or another for years. If you look hard enough you might even find the name "Haskell Industries" buried somewhere in the BD Rebuilder code...

[jdobbs]

how do you view if repeat headers worked ?? i tried another encoder that uses nvencc and added --repeat-headers and it started off allocating 1,2 gig of memory and stayed around there but no idea if headers are repeatedIt's not easy without the right tools. I have an HEVC browser.

If you're good with a hex editor, you can find the delimiters between headers, slices etc by searching for the start code delimiter (00 00 00 01) -- it is prohibited from appearing anywhere else in the elementary stream. But even if you find the delimiters you'll need to reference the H265 standard (T-REC-H.265-201802-I) to find the format of all the segments that might follow a delimeter (see page 68). The standard is available for free download as a PDF.

The best way to see if the headers are there is to use TSMUXER to create a UHD-BD structure and play it back on a UHD compatible BD player. If FF/REW works... it's probably safe to assume the headers are repeated.

Just out of curiosity... what is the other encoder? It would likely be random luck if it would use the same command line parameter. I think NVENCC uses it because I suggested it (so it would match the parameter in X265).

[GreasyGreedo]

Hello,

I tried searching to see if this problem has been reported otherwise, but didn't see it.

When I author a UHD disc with multiple movie files (quick reauthored import), the subtitles are lost from the final disc. I have not had this problem with HD discs. Is there some difference that prevents the subtitles from being present on a UHD disc of this type?

[cartman0208]

[Edit] Yeah. I just set the GOP length to 240 frames and it is barely growing at all... but, of course, that encode would fail to meet the UHD-BD standard. I would assume that it would also mean that as you attempt to fast forward, each picture step would jump 10 seconds instead of 1. The table used for these actions only logs IDR positions.



Ok, so that's why I saw blocky artifacts for several seconds when jumping to random positions in the SW Player...
So I started a new run with gop-len 24 and the memory increase is actually higher ... started out at around 600 and went up to 1500MB after 180000 frames.
Maybe with a 3hr movie file the 2GB mark would have cracked ... maybe...

Then I tried your commandline and an 1080p video ... stable at around 300MB, no increase at all
The only difference ... I didn't use the keyfile-parameter
.\NVEncC.exe --avhw -i U:\Temp\Spectre_temp\Spectre.h264 --codec h264 --preset quality --bluray --qp-min 0 --vbr 22429 --sar 1:1 --aud --pic-struct --vbv-bufsize 30000 --max-bitrate 35000 --gop-len 24 -o U:\Temp\Spectre_temp\Spectre.264 --repeat-headers
--------------------------------------------------------------------------------
U:\Temp\Spectre_temp\Spectre.264
--------------------------------------------------------------------------------
NVEncC (x86) 5.08 (r1585) by rigaya, Jul 1 2020 14:48:28 (VC 1900/Win/avx2)
OS Version Windows 10 x64 (18363)
CPU Intel Core i7-6800K @ 3.40GHz [TB: 3.80GHz] (6C/12T)
GPU #0: GeForce GTX 1660 Ti (1536 cores, 1770 MHz)[2147483.64]
NVENC / CUDA NVENC API 9.1, CUDA 11.0, schedule mode: auto
Input Buffers CUDA, 20 frames
Input Info avcuvid: H.264/AVC, 1920x1080, 24000/1001 fps
Vpp Filters copyDtoD
Output Info H.264/AVC high @ Level auto
1920x1080p 1:1 23.976fps (24000/1001fps)
Encoder Preset quality
Rate Control VBR
Bitrate 22429 kbps (Max: 35000 kbps)
Target Quality auto
Initial QP I:20 P:23 B:25
QP range I:0-51 P:0-51 B:0-51
VBV buf size 30000 kbit
Lookahead off
GOP length 24 frames
B frames 3 frames [ref mode: disabled]
Ref frames 3 frames, MultiRef L0:auto L1:auto
AQ off
Others mv:auto cabac deblock adapt-transform:auto bdirect:auto aud pic-struct repeat-headers

encoded 213072 frames, 412.48 fps, 21838.53 kbps, 23135.71 MB
encode time 0:08:36, CPU: 9.5%, GPU: 7.1%, VE: 96.2%, VD: 78.7%
frame type IDR 8878
frame type I 8878, total size 1702.42 MB
frame type P 53268, total size 8475.27 MB
frame type B 150926, total size 12958.02 MB

Apparently I cannot reproduce the error ... only a memory increase :o

[jdobbs]

@cartman0208

I removed the keyfile parameter and the memory leak persists for me. Not sure how my test differs from yours. As for the encode failure... I think the problem would also depend on the source you are using. So it will happen, it's just a matter of time. You actually need the keyfile to make sure there is an IDR frame at each chapter point.

But... I have good news. If you change the output format from an elementary stream (.hevc) to a container (e.g. .m2ts)... the problem seems to go away. That provides a good workaround that won't require BD-RB to have to rewrite the entire HEVC stream! I should be able to use the .m2ts as an input file for the TSMUXER muxing. It'll require some code changes -- but I don't think it should be anything too extreme.

My thanks to jkiku101 for experimenting with encodes and finding this potential workaround!

[jdobbs]

Hello,

I tried searching to see if this problem has been reported otherwise, but didn't see it.

When I author a UHD disc with multiple movie files (quick reauthored import), the subtitles are lost from the final disc. I have not had this problem with HD discs. Is there some difference that prevents the subtitles from being present on a UHD disc of this type?I can't think of a difference. But I'll look and see.

[cartman0208]

@cartman0208

I removed the keyfile parameter and the memory leak persists for me. Not sure how my test differs from yours. As for the encode failure... I think the problem would also depend on the source you are using. So it will happen, it's just a matter of time. You actually need the keyfile to make sure there is an IDR frame at each chapter point.

But... I have good news. If you change the output format from an elementary stream (.hevc) to a container (e.g. .m2ts)... the problem seems to go away. That provides a good workaround that won't require BD-RB to have to rewrite the entire HEVC stream! I should be able to use the .m2ts as an input file for the TSMUXER muxing. It'll require some code changes -- but I don't think it should be anything too extreme.

My thanks to jkiku101 for experimenting with encodes and finding this potential workaround!

Ok, then maybe it's really my 1909 Win10 Build for which I did not receive an update yet ... and 2004 is messed up with memory leak ...

Doesn't matter ... good to have a solution for this ... now to find the best settings for awesome quality :D

[Mike-uk]

Doesn't matter ... good to have a solution for this ... now to find the best settings for awesome quality :D

yes being hardware encoding and to contend with x265/264 we need to get the best possible settings dialed in, but will be nice to have the option of considerably faster encodes but slightly less quality with HW, or still the SW/cpu at 16Hrs for absolute best :/

[jdobbs]

yes being hardware encoding and to contend with x265/264 we need to get the best possible settings dialed in, but will be nice to have the option of considerably faster encodes but slightly less quality with HW, or still the SW/cpu at 16Hrs for absolute best :/Yep. It's all about choice.

[gonca]

NVEncC 5.09 is out
Supposed to fix memory leak

[Mike-uk]

NVEncC 5.09 is out
Supposed to fix memory leak

darn you beat me too it :(

[gonca]

Presently testing 5.09, looking promising

[gonca]

Completed fine but have to repeat test
Forgot --repeat-headers in cmd line

[gonca]

cmd line
nvencc64.exe --codec hevc --preset quality --cqp 22 --profile main10 --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll 902,182 --chromaloc 2 --colormatrix bt2020nc --colorprim bt2020 --transfer smpte2084 --gop-len 24 --lookahead 32 --sar 1:1 --repeat-headers
tested only on software player
no memory leak during encode
appears ok but requires more testing

[gonca]

Burned to disc and played on stand alone player (Sony)
Seems fine

[Mike-uk]

Burned to disc and played on stand alone player (Sony)
Seems fine

nice :),

[Mike-uk]

cmd line

tested only on software player
no memory leak during encode
appears ok but requires more testing

yep can confirm it seems fixed stayed arounf 700 Mb, not tested on a disc as not got any RWs

--avhw --vpp-pad 0,276,0,278 -i F:\Movies\uhd2019\BDMV\STREAM\00014.m2ts --codec hevc --preset quality --profile main10 --output-depth 10 --repeat-headers --chromaloc 2 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) --qp-min 0 --vbrhq 0 --vbr-quality 25 --sar 1:1 --aud --pic-struct --vbv-bufsize 45000 --max-bitrate 48000 --gop-len 24 --slices 4 -o "D:\test\VID_00000.hevc

RTX 2070 Super

encoded 175243 frames, 62.57 fps, 12390.37 kbps, 10795.88 MB
encode time 0:46:40, CPU: 7.2%, GPU: 6.3%, VE: 99.2%, VD: 18.1%
frame type IDR 7302
frame type I 7302, total size 1246.97 MB
frame type P 43811, total size 4712.77 MB
frame type B 124130, total size 4836.14 MB

[jdobbs]

Good to hear... I wasn't expecting that one to get fixed so fast. I'll test it tomorrow. Sigh... now I need to go back through my code and remove all the changes I made for outputting to .m2ts. It resulted in a lot more changes than I'd expected, and I was still testing it and finding stuff. Two steps forward and one step back. :)

[cartman0208]

yep can confirm it seems fixed stayed arounf 700 Mb, not tested on a disc as not got any RWs

--avhw --vpp-pad 0,276,0,278 -i F:\Movies\uhd2019\BDMV\STREAM\00014.m2ts --codec hevc --preset quality --profile main10 --output-depth 10 --repeat-headers --chromaloc 2 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) --qp-min 0 --vbrhq 0 --vbr-quality 25 --sar 1:1 --aud --pic-struct --vbv-bufsize 45000 --max-bitrate 48000 --gop-len 24 --slices 4 -o "D:\test\VID_00000.hevc

RTX 2070 Super

encoded 175243 frames, 62.57 fps, 12390.37 kbps, 10795.88 MB
encode time 0:46:40, CPU: 7.2%, GPU: 6.3%, VE: 99.2%, VD: 18.1%
frame type IDR 7302
frame type I 7302, total size 1246.97 MB
frame type P 43811, total size 4712.77 MB
frame type B 124130, total size 4836.14 MB

I can also confirm, that there is a stable RAM usage.

And the best part ... it doesn't seem to matter which turing chip ... i tried with Mike's settings and got around 61 fps on my 1660ti, while the card costs about half ;)
Maybe a Titan would make a difference ... but people could buy a decent car in that price range :eek:

BTW: I think with your settings you actually add some height to the video ( pad: [3840x2160]->[3840x2714] (right=0, left=0, top=276, bottom=278) ) ... forgot some dashes? :)

@jdobbs: why not use the code from 0.61.0.5 and start over?

[Mike-uk]

I can also confirm, that there is a stable RAM usage.

And the best part ... it doesn't seem to matter which turing chip ... i tried with Mike's settings and got around 61 fps on my 1660ti, while the card costs about half ;)
Maybe a Titan would make a difference ... but people could buy a decent car in that price range :eek:

hmm yeh interesting encoding fps is the same :confused:

[gonca]

Dedicated encoding hardware is probably the same

[jdobbs]

@jdobbs: why not use the code from 0.61.0.5 and start over? You underestimate how much code it took to integrate it in. I also have implemented a host of other changes since that version. Anyway, I've already reversed most of the code I'd written for it.

[Mike-uk]

Dedicated encoding hardware is probably the same

hmm yeh quite possibly found this on a forum

Turing NVENC is slower at higher quality settings than Pascal NVENC. The NVIDIA application note for NVENC states that at highest quality you should expect no more than 130fps at 1080p (or around 33fps at 4K).

[gonca]

Extra switches (cmd line options) available
NVenc is on a dedicated chip, same chip across the "line" (family) of cards
https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
Chip number and number of encoding chips per card

[MrVideo]

You underestimate how much code it took to integrate it in. I also have implemented a host of other changes since that version. Anyway, I've already reversed most of the code I'd written for it.
Don't you use Revision Control Software? Programs like Git, CVS and SVN (subversion, which I've managed at a work place) would have allowed you to back out those changes. But, as you've pointed out, a little late now.

[jdobbs]

Don't you use Revision Control Software? Programs like Git, CVS and SVN (subversion, which I've managed at a work place) would have allowed you to back out those changes. But, as you've pointed out, a little late now.I am my revision control software.

[cartman0208]

...
Turing NVENC is slower at higher quality settings than Pascal NVENC. ....

I assume, that's because of the B-Frame capability of Turing ... which I don't want to miss, because there is the bitrate saving ...

[jdobbs]

I assume, that's because of the B-Frame capability of Turing ... which I don't want to miss, because there is the bitrate saving ...I'm with you. I want the B-Frame efficiency.

[Mike-uk]

jdobbs do you think you'll add true CPU first pass, then GPU second pass ?? seems the only way to get true 2 pass or maybe add it as an option so people can choose what they want,

maybe get some comparisons of CPU first pass and the lookahead feature to see if theres any quality difference

[MrVideo]

I am my revision control software.
:scared:

[Mike-uk]

Nvidia 3xx series rumoured to be released in aug, wonder if they have improved NVenc, and x266 being developed ohhhh its like xmas

[Mark_Venture]

...
And the best part ... it doesn't seem to matter which turing chip ... i tried with Mike's settings and got around 61 fps on my 1660ti, while the card costs about half ;)
Maybe a Titan would make a difference ... but people could buy a decent car in that price range :eek: So are you saying that as long as its card with a Turing chip, the Cuda cores, clock, etc. doesn't really impact the FPS much when using NVEncC? They're all about the same?

[cartman0208]

So are you saying that as long as its card with a Turing chip, the Cuda cores, clock, etc. doesn't really impact the FPS much when using NVEncC? They're all about the same?

I was wondering, too ...
But i used the same settings as Mike-uk, only a different source (with the same dimensions)
I could try different sources, but my experience so far was an almost unnoticable FPS change, even when changing presets.
We need someone with RTX 2060 / 2080 to verify :rolleyes:

[jdobbs]

I was wondering, too ...
But i used the same settings as Mike-uk, only a different source (with the same dimensions)
I could try different sources, but my experience so far was an almost unnoticable FPS change, even when changing presets.
We need someone with RTX 2060 / 2080 to verify :rolleyes:I'm seeing quite a bit of difference between presets when running against the same source. The "performance" preset, for example, is running much faster than "default" or "quality". It can also change based on whether I am using --vbr or --vbrhq.

For example, on a specific UHD source I'm using for testing with preset "performance" and "--vbr" I am getting 127.49 fps -- the same source with "quality" and "--vbrhq" it is doing 77.67 fps (with an otherwise identical command line).

I am also seeing fluctuations depending upon the size (on disc) of the source. An imported 10GB source M2TS encodes faster than a full 60GB untouched source.

The largest factor to speed I've seen (as you might expect) is whether I am using --avs as the input type as opposed to --avhw or --avsw.

[cartman0208]

Ok, I didn't do extended tests ... only constant QP on a small source file ... I wanted to check out resulting file sizes

[Mark_Venture]

I'm seeing quite a bit of difference between presets when running against the same source. The "performance" preset, for example, is running much faster than "default" or "quality". It can also change based on whether I am using --vbr or --vbrhq.

For example, on a specific UHD source I'm using for testing with preset "performance" and "--vbr" I am getting 127.49 fps -- the same source with "quality" and "--vbrhq" it is doing 77.67 fps (with an otherwise identical command line).

I am also seeing fluctuations depending upon the size (on disc) of the source. An imported 10GB source M2TS encodes faster than a full 60GB untouched source.

The largest factor to speed I've seen (as you might expect) is whether I am using --avs as the input type as opposed to --avhw or --avsw.you mention different presets. I was wondering about using the same source, with the same preset, across different cards.

cartman0208 indicated using the same command line that Mike-uk posted, resulted in similar FPS using different video cards (GTX1660ti vs RTX 2070 Super) based on their posts. And using the same string Mike-uk posted on a UHD rip on my PC also came out with the same FPS (using GTX1660ti here).

When all is said and done, it will be interesting to compare results if we could each run tests on our respective systems using the SAME pre-sets and (if possible) the same source.

[gonca]

you mention different presets. I was wondering about using the same source, with the same preset, across different cards.

cartman0208 indicated using the same command line that Mike-uk posted, resulted in similar FPS using different video cards (GTX1660ti vs RTX 2070 Super) based on their posts. And using the same string Mike-uk posted on a UHD rip on my PC also came out with the same FPS (using GTX1660ti here).

When all is said and done, it will be interesting to compare results if we could each run tests on our respective systems using the SAME pre-sets and (if possible) the same source.
https://forum.doom9.org/showthread.php?p=1917767#post1917767