NVEnc
NVEnc copied to clipboard
rigaya
NVEnc_3.29: --weightp unfortunately does not work with NVIDIA drivers 390.77
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.<Invoke>b__0() --- Конец трассировка стека из предыдущего расположения, где возникло исключение --- в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() в StaxRip.GlobalClass.ProcessJob(String jobPath) в D:\Projekte\VS\VB\StaxRip\General\GlobalClass.vb:строка 137
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?
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.
http://gofile.me/2bfU9/Sq4GByBc4
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. Probably, it will be useful to you for testing and search of a problem with --weight.
Fragment 1min 20sec: http://gofile.me/2bfU9/8gLB2C1hT LOG: log.txt
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. Probably, about this issue should be reported to NVIDIA, and, probably, they will remove this stupid patch, as Microsoft did with the security update of Windows 10 which caused the operating system to malfunction.
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. With "weighted prediction" enabled, the process may crash (the error message with ffmpeg is "Failed unlocking input buffer!: generic error (20)") or be completed but in that case the video will be highly corrupted, in particular at the very beginning and just after fading in/out transitions. The issue have been reported to NVidia on the Geforce forum and on the developper one, but nobody seems to be willing to take care of it (most of the time, the answer made is to incriminate the conversion software rather than just admit the bug). As Spectre and Meltdown mitigation was only introduced with the 390.65 version of the driver, things went wrong earlier. It is a real pity as the functionality brought a significant improvement in the quality of the encoding when it has to handle a variation of luminosity.
@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 Size: 206Mb
In my case, the error looks like this:
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 ;)
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 [email protected]:
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 https://github.com/rigaya/NVEnc/issues/34#issuecomment-392595858, 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 [email protected]:
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 https://github.com/rigaya/NVEnc/issues/34#issuecomment-392597497, 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 [email protected]:
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 [email protected]:
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 https://github.com/rigaya/NVEnc/issues/34#issuecomment-392597497, 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 [email protected]:
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 [email protected]:
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 [email protected]:
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 https://github.com/rigaya/NVEnc/issues/34#issuecomment-392597497, 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 [email protected]:
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 https://github.com/rigaya/NVEnc/issues/34#issuecomment-392599605, 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.
please check these 2 files and tell me if this is extremely bad quality and can be improved massively with --aq......if so I got a LOT of work to do :)
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 [email protected]:
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 https://github.com/rigaya/NVEnc/issues/34#issuecomment-392687003, 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 NVEncC64.exe --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"
LoadPlugin("L-SMASH-Works\LSMASHSource.dll") LWLibavVideoSource("La La Land.h265", format = "YUV420P8") Crop(0, 328, -0, -328)
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 [email protected]:
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 https://github.com/rigaya/NVEnc/issues/34#issuecomment-393063364, or mute the thread https://github.com/notifications/unsubscribe-auth/AdX5NJZL3MSLby17sMwnX0O9orl2PkUqks5t3k4jgaJpZM4SLtNs .
Thx :)
2018-05-30 9:50 GMT+02:00 drSHLEFF [email protected]:
yes, of course
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rigaya/NVEnc/issues/34#issuecomment-393064687, 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 [email protected]:
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 https://github.com/rigaya/NVEnc/issues/34#issuecomment-393066079, 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:
Our engineering team did not observe issues with the video files you shared. We did see errors weighted prediction with B frames unsupported.
Could you send us compatible video files and the command you are running?
Do you have additional video samples with same issue?☹
NVEnc 4.69 + NVIDIA Drivers 445.75
--weightp - CODED HEVC WITHOUT ISSUE! At last!)) But... Now If the --weight option is used, then HDR metadata is not embedded in the video file.
w/o --weightp:
Видео Идентификатор : 1 Формат : HEVC Формат/Информация : High Efficiency Video Coding Профиль формата : Main [email protected]@High HDR_Format/String : SMPTE ST 2086, HDR10 compatible Идентификатор кодека : V_MPEGH/ISO/HEVC Продолжительность : 1 ч. 56 м. Битрейт : 42,3 Мбит/сек Ширина : 3840 пикселей Высота : 1604 пикселя Соотношение сторон : 2,40:1 Режим частоты кадров : Постоянный Частота кадров : 23,976 (24000/1001) кадра/сек Цветовое пространство : YUV Субдискретизация насыщенности : 4:2:0 (Type 2) Битовая глубина : 10 бит Бит/(Пиксели*Кадры) : 0.286 Размер потока : 34,3 Гбайт (98%) Заголовок : Passengers (NVEnc 4.69,UQ,TQ=21,aq=15) Язык : English Default : Да Forced : Нет Цветовой диапазон : Limited Основные цвета : BT.2020 Характеристики трансфера : PQ Коэффициенты матрицы : BT.2020 non-constant MasteringDisplay_ColorPrimaries : Display P3 MasteringDisplay_Luminance : min: 0.0050 cd/m2, max: 4000 cd/m2 MaxCLL : 1529 cd/m2 MaxFALL : 380 cd/m2
the same project with --weightp:
Идентификатор : 1 Формат : HEVC Формат/Информация : High Efficiency Video Coding Профиль формата : Main [email protected]@High Идентификатор кодека : V_MPEGH/ISO/HEVC Продолжительность : 1 ч. 56 м. Битрейт : 42,3 Мбит/сек Ширина : 3840 пикселей Высота : 1604 пикселя Соотношение сторон : 2,40:1 Режим частоты кадров : Постоянный Частота кадров : 23,976 (24000/1001) кадра/сек Цветовое пространство : YUV Субдискретизация насыщенности : 4:2:0 (Type 2) Битовая глубина : 10 бит Бит/(Пиксели*Кадры) : 0.287 Размер потока : 34,3 Гбайт (98%) Заголовок : Passengers (NVEnc 4.69,UQ,TQ=21,aq=15) Язык : English Default : Да Forced : Нет Цветовой диапазон : Limited Основные цвета : BT.2020 Характеристики трансфера : PQ Коэффициенты матрицы : BT.2020 non-constant
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. Using the FFmpeg container (.MKV / .MP4) or MP4Box (.MP4) everything works as it should.
