NVEnc_3.29: --weightp unfortunately does not work with NVIDIA drivers 390.77 #34
Comments
HEVCでweightpを使うと、nvEncLockBitstreamでエラーを吐くことが多いのが改善するか?( #34 を参考、ただまあ、他のエラーコードの場合もあるが…)
|
Thank you for the sample, but unfortunately I wasn't able to reproduce the error. Since it is an errror around bitstream output, I've changed the way of bitstream ouput buffer allocation in NVEnc 3.30. Would you check if it make some change? |
|
Right now i doing it. Wait... |
|
Apparently, the error occurs when the scene changing from dark to light. I attached ORIGINAL video (10 sec this scene). But, if you try to encode only these 10 seconds - the error does not appear. This indicates that it's not a matter of the --weightp function or in the API or drivers, namely NVEnc. This faulty scene is in the center of the movie and it's possible that by this time some bug is accumulating (the buffer is full, or something like that), which leads to a crash. |
|
I'm sorry, but the error appeared again. This time in another place. Coding was not interrupted. |
|
Coding was interrupted, NVEnc crashed with an error in the same place where the scene changes. |
|
I cut out the smallest possible piece of the original file, when encoding it, an error always appears and NVEnc crashes always on the same place. Error occurs on this fragment only if use Crop with Output Mod = 2 or 4. Fragment 1min 20sec: http://gofile.me/2bfU9/8gLB2C1hT |
|
Well, I successfully re-encoded your "crashing" fragment (1m:20s) using command line from your log.txt without crash, so if you truly want to say this is nvenc fault you should try direct re-encode (exclude staxrip and avisynth) on your system (yes, you can directly reencode m2ts streams with nvenc :), if it pass - its not error in nvenc, but somewhere else... In general helps reinstalling video driver (Nvidia offers clean install (I am using driver 385.28 a no problem with weightp whatsoever (in ffmpeg or nvenc))), reinstalling staxrip or avisynth, etc. |
|
Yes, drivers up to version 385.69 inclusive, work fine. With the release of version 387.92 --weightp stopped working stably. But installing older drivers is not a solution. Need to understand, what is wrong with the drivers since the version 387.92. Approximately from this version NVIDIA has added changes to fix the problems with Spectre / Meltdown security. |
|
Re-encoding h265 video track extracted from remux, using command line. The same errors in the same places. On the second error NVEnc crashes (at the fragment I sent earlier)... |
|
I have the same problem with all versions of Nvidia drivers posterior to 385.69, both with NVEnc and with ffmpeg. |
|
Today, new drivers have come out 391.01 - the problem has not been fixed. |
|
@drSHLEFF , could you post your sample over https://devtalk.nvidia.com/default/topic/1035419/video-codec-sdk/bug-report-weight-p-does-not-work-properly-since-nvidia-drivers-387-92-onwards-/ ? rypark from nvidia said their 'SA team cannot reproduce the problem in order for them to identify and fix the issue.' The video SDK team needs a sample. @rigaya , if you still have his sample, could you send it to nvidia team? |
|
I made archive with a 30-second fragment of the original 4K UHD BD and necessary software (NVEncC 4.03, avs script, ffindex and batch file), and post it at the NVIDIA forum. In principle, anyone can download, unpack the archive in any folder and run "sample--weightp.bat" (Previously, need to install Avisynth+ 2.60). http://gofile.me/2bfU9/qY2ik2Qax In my case, the error looks like this: |
|
Dear drSHLEFF --aq is NOT supported by h265 |
|
AQ (--aq) - supported (Spatial). |
|
I always thought the --aq was in nvenc was temporal and strength only....ah
well learn something new every day :)
However I never used --aq and the videos look perfectly okay with hdr etc
etc
2018-05-28 22:06 GMT+02:00 drSHLEFF <notifications@github.com>:
… AQ (--aq) - supported (Spatial).
AQ Temporal (--aq-temporal & --aq-strength) - is NOT supported.
Try to encode one sample with it, and without it, and you will see a
significant difference in detailing (and in size, of course). Use "--aq"
required, otherwise the target 4K UHD will look like an old VideoCD ;)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#34 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AdX5NAIOK5c3OQcf48PcVSkbeAeuYQhTks5t3FjTgaJpZM4SLtNs>
.
|
|
Now you have to re-encode everything again. At the same time you'll practice...) |
|
well if I could give you a sample of something you can check it
yourself...looks fine to me
2018-05-28 22:18 GMT+02:00 drSHLEFF <notifications@github.com>:
… Now you have to re-encode everything again. At the same time you'll
practice...)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#34 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AdX5NCcci08kdTNKCqPvbMkxynoQjqVxks5t3FuggaJpZM4SLtNs>
.
|
|
ok well 1 question then for a h265 vbr 25000 of 2 hours is it normal to
reach 30gb without --aq?
2018-05-28 22:19 GMT+02:00 Pieter Cooijmans <pwacooijmans@gmail.com>:
… well if I could give you a sample of something you can check it
yourself...looks fine to me
2018-05-28 22:18 GMT+02:00 drSHLEFF ***@***.***>:
> Now you have to re-encode everything again. At the same time you'll
> practice...)
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#34 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AdX5NCcci08kdTNKCqPvbMkxynoQjqVxks5t3FuggaJpZM4SLtNs>
> .
>
|
|
That has to be Gigabyte btw
2018-05-28 22:25 GMT+02:00 Pieter Cooijmans <pwacooijmans@gmail.com>:
… ok well 1 question then for a h265 vbr 25000 of 2 hours is it normal to
reach 30gb without --aq?
2018-05-28 22:19 GMT+02:00 Pieter Cooijmans ***@***.***>:
> well if I could give you a sample of something you can check it
> yourself...looks fine to me
>
>
> 2018-05-28 22:18 GMT+02:00 drSHLEFF ***@***.***>:
>
>> Now you have to re-encode everything again. At the same time you'll
>> practice...)
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <#34 (comment)>, or mute
>> the thread
>> <https://github.com/notifications/unsubscribe-auth/AdX5NCcci08kdTNKCqPvbMkxynoQjqVxks5t3FuggaJpZM4SLtNs>
>> .
>>
>
>
|
|
Without adaptive quantization, the video loses details. Of course, the bitrate is reduced, but due to a very strong decrease in quality. I would advise using --aq in any case, and then, by the result, adjust the bitrate. I think 25Mbit/s is not enough for a quality 4K, but it all depends on the original. |
|
one last question then....does --strict-gop and --aq work together?
2018-05-28 22:36 GMT+02:00 drSHLEFF <notifications@github.com>:
… Without adaptive quantization, the video loses details. Of course, the
bitrate is reduced, but due to a very strong decrease in quality. I would
advise using --aq in any case, and then, by the result, adjust the bitrate.
I think 25Mbit/s is not enough for a quality 4K, but it all depends on the
original.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#34 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AdX5NDoPrjNPdobn-NU_LDICTVIGOFcdks5t3F-0gaJpZM4SLtNs>
.
|
|
Yes. But a fixed GOP makes sense to use with small GOP values: 12, 15, 24, 30... Better use Auto GOP. |
|
|
|
Top one - with aq, bottom - without. Undoubtedly, the upper one is much closer to the original, details and noise are kept, I personally would leave the upper version. |
|
Well the problem is the upper version only works on a very small amount of hardware while the lower version is nearly compatible with everything and has 1/4th the size, my mediaplayer can only handle so much :) So not much options it seems :( |
|
How much % on avg would you say --aq will increase the file size if I stick at the same vbr rate? Simply because I have a storage problem on the mediaplayer :) |
|
30-50%. Then there's no point in storing 4K. By removing details and natural noise, you make the film - plastic. It's better to store 1080p, but encoded with HEVC and extreme quality, i think... |
|
The only reason I store 4K at 25000kilobits is because h265 at 12000kilobits is equal to h264 for the human eye, you can check wiki for that fact. So figured the tiny improvement would be worth it :) But many thx for your input :) |
|
Maybe I am stupid, prolly am, but for me 12000 at 1920x1080 was like 52,6% of the bitrate of a normal bd50 h264 so my simple math was that with 3840x2160 I would get an avg of 1,5 to 2 pixels at the same resolution per dot due to higher resolutions compressing better and stuff. So on avg for the human eye it "should" look better on a 4K monitor/tv....at least that was my reasoning :).... |
|
Luckaly I have a large family (100+) so I asked everyone if they found it an improvement and they happen to agree it does look better than the old h264 :) So that's why I did it :) |
|
For 4K La La Land, the minimum possible bitrate is 27 Mbps, in order to maintain an acceptable detailing, IMHO. Try this command line: NVEncC64.exe --avhw cuda --vbrhq 160000 --codec h265 --preset quality --output-depth 10 --lookahead 32 --no-b-adapt --no-i-adapt --qp-init 1 --max-bitrate 160000 --vbr-quality 23 --aq --cuda-schedule auto --output-buf 128 --colormatrix bt2020nc --colorprim bt2020 --transfer smpte2084 --mv-precision q-pel --chromaloc 2 --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) --max-cll 1000,640 --crop 0,328,0,328 -i "La La Land.h265" -o "La La Land_new.h265" If you encoding on HDD, change --output-buf to 32. If you want smaller bitrate and size of target file, just increase --vbr-quality to 24-28. But for my opinion, 23 is a maximum for real good quality. For very good quality: --vbr-quality = 22, with 19-21 - ultra quality, and accordingly max target file size. PS: But all of this does not matter. Because La La Land is not a true 4K, it's an up-scale from 2K-mastering. And the advantages he has only in the Dolby Atmos sound and HDR. It seems to me that if you have a shortage of storage, it makes no sense to store a bloated 2K. |
|
Thank you SOOOOOOOOOOOOO much for this line of compression....the quality
improvement is AMAZING....20% bigger files when I make a print
screen....that says something and the total size isn't even that much
bigger :)
Well lots of work todo thx to you now...:)
2018-05-29 9:58 GMT+02:00 drSHLEFF <notifications@github.com>:
… For 4K La La Land, the minimum possible bitrate is 27 Mbps, in order to
maintain an acceptable detailing, IMHO. Try this command line:
*NVEncC64.exe --avhw cuda --vbrhq 160000 --codec h265 --preset quality
--output-depth 10 --lookahead 32 --no-b-adapt --no-i-adapt --qp-init 1
--max-bitrate 160000 --vbr-quality 23 --aq --cuda-schedule auto
--output-buf 128 --colormatrix bt2020nc --colorprim bt2020 --transfer
smpte2084 --mv-precision q-pel --chromaloc 2 --master-display
G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)
--max-cll 1000,640 --crop 0,328,0,328 -i "La La Land.h265" -o "La La
Land_new.h265"*
If you encoding on HDD, change --output-buf to 32. If you want smaller
bitrate and size of target file, just increase --vbr-quality to 24-28. But
for my opinion, 23 is a maximum for real *good quality*. For *very good
quality*: --vbr-quality = 22, with 19-21 - ultra quality, and accordingly
max target file size.
PS: *But all of this does not matter. Because La La Land is not a true
4K, it's an up-scale from 2K-mastering. And the advantages he has only in
the Dolby Atmos sound and HDR. It seems to me that if you have a shortage
of storage, it makes no sense to store a bloated 2K.*
[image: default]
<https://user-images.githubusercontent.com/11748220/40645236-6c556166-632e-11e8-8f22-fea1e52a7ca5.PNG>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#34 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AdX5NG-NIC6huKrFLK9I77XijUGtLkSJks5t3P-ggaJpZM4SLtNs>
.
|
|
there is no limit to perfection ...) --avhw not the best way for HEVC, try avisynth decoder |
|
LoadPlugin("L-SMASH-Works\LSMASHSource.dll") |
|
is --cuda-schedule auto still needed if you use avisynth instead of --avhw?
Cuz I was already trying that of course :)
2018-05-30 9:45 GMT+02:00 drSHLEFF <notifications@github.com>:
… LoadPlugin("L-SMASH-Works\LSMASHSource.dll")
LWLibavVideoSource("La La Land.h265", format = "YUV420P8")
Crop(0, 328, -0, -328)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#34 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AdX5NJZL3MSLby17sMwnX0O9orl2PkUqks5t3k4jgaJpZM4SLtNs>
.
|
|
yes, of course |
|
Thx :)
2018-05-30 9:50 GMT+02:00 drSHLEFF <notifications@github.com>:
… yes, of course
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#34 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AdX5NIytu-PPSFTIKnUAkimr5-mDbSo3ks5t3k8_gaJpZM4SLtNs>
.
|
|
avisynth decode original more accurately, so with all this parameters you'll get more 10% file size, but 20% file quality |
|
btw for h265 there is an end to perfection :).....there are only so many
pixels with so many possible outcomes....not that I will ever see that in
my life time :)
2018-05-30 9:55 GMT+02:00 drSHLEFF <notifications@github.com>:
… avisynth decode original more accurately, so with all this parameters
you'll get more 10% file size, but 20% file quality
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#34 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AdX5NPg3naND52SAFJKBSptI_sgZzGDnks5t3lCAgaJpZM4SLtNs>
.
|
|
@drSHLEFF , I just got an e-mail from rypark today after sending your video sample via google drive to nvidia few months ago:
Do you have additional video samples with same issue?☹ |
|
NVEnc 4.69 + NVIDIA Drivers 445.75 --weightp - CODED HEVC WITHOUT ISSUE! At last!)) But... w/o --weightp: Видео the same project with --weightp: Идентификатор : 1 |
|
In my case, this problem occurs only for the .MKV container (MKVToolNix), and also freezes the first 10 seconds of the video itself, with the sound working properly, after these 10 seconds everything returns to normal. |
|
I’plan close the issue as the conversation has diverged and off-topic. |
The error always occurs on dark frames (often with fog or smoke) or during the fadein/fadeout process.
Here is the last frame after which the error occurred:
This is the last 5 seconds of the video before an error occurs (may be useful):
http://gofile.me/2bfU9/q1AVeeStc
----------------------- log ------------------------
StaxRip.ErrorAbortException: Video encoding using NVEnc 3.29 failed with exit code: 1 (0x1)
The exit code might be a system error code: STATUS_WAIT_1
The exit code might be a system error code: Неверная функция.
------------------- Video encoding using NVEnc 3.29 -------------------
C:\Temp\StaxRip\Apps\NVEnc\NVEncC64.exe --vbrhq 160000 --codec h265 --preset quality --output-depth 10 --weightp --bframes 0 --ref 5 --gop-len 12 --lookahead 32 --no-b-adapt --no-i-adapt --qp-init 1 --max-bitrate 160000 --vbr-quality 21 --aq --cuda-schedule auto --output-buf 32 --colormatrix bt2020nc --colorprim bt2020 --transfer smpte2084 --mv-precision q-pel --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll 1529,380 -i "D:\PASSENGERS_(201...temp\PASSENGERS(2016)UHD_HDR_RMX-BLUEBIRD_new.avs" -o "D:\PASSENGERS(2016)_UHD_HDR_RMX-BLUEBIRD_new.h265"
NVEncC (x64) 3.29 (r714) by rigaya, Feb 19 2018 23:18:08 (VC 1900/Win/avx2)
OS Version Windows 10 x64 (16299)
CPU Intel Core i7-3930K @ 3.20GHz 4.07GHz (6C/12T)
GPU #0: GeForce GTX 1080 (20 EU) @ 1835 MHz (390.77)
NVENC / CUDA NVENC API 8.0, CUDA 9.1, schedule mode: auto
Input Buffers CUDA, 41 frames
Input Info Avisynth+ 2.60(yv12)->p010 [AVX], 3840x1604, 24000/1001 fps
Vpp Filters copyHtoD
Output Info H.265/HEVC main10 @ Level auto
3840x1604p 1:1 23.976fps (24000/1001fps)
Encoder Preset quality
Rate Control VBRHQ
Bitrate 160000 kbps (Max: 160000 kbps)
Target Quality 21.00
Initial QP I:1 P:1 B:1
VBV buf size auto
Lookahead on, 32 frames
GOP length 12 frames
B frames 0 frames
Ref frames 5 frames, LTR: off
AQ on
CU max / min auto / auto
Others mv:Q-pel weightp
Error on nvEncLockBitstream: 8 (NVENC indicates that one or more of the parameter passed to the API call is invalid.)
Error cudaEventSynchronize: 30 (cudaErrorUnknown).
в StaxRip.Proc.Start() в D:\Projekte\VS\VB\StaxRip\General\Proc.vb:строка 338
в StaxRip.NVEnc.Encode() в D:\Projekte\VS\VB\StaxRip\Encoding\NVEnc.vb:строка 82
в StaxRip.GlobalClass.ProcessVideo() в D:\Projekte\VS\VB\StaxRip\General\GlobalClass.vb:строка 225
в System.Threading.Tasks.Parallel.<>c__DisplayClass4_0.b__0()
--- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
в StaxRip.GlobalClass.ProcessJob(String jobPath) в D:\Projekte\VS\VB\StaxRip\General\GlobalClass.vb:строка 137
The text was updated successfully, but these errors were encountered: