View Full Version : BD Rebuilder Beta - Bug Reports Only
jdobbs
24th June 2020, 23:07
Sorry, the last Apache update made the webserver case sensitive (again :mad: ) ... Since the link points to Avisynth_260.exe but the file is named AviSynth_260.exe you got a 404 :(
I just renamed the file, link should be working now.Wow. When was that posted... I must have missed it completely.
[Edit] Ok, I see. It was part of the "3 frigg'n MONTHS behind" post. I guess I just missed that part.
jdobbs
26th June 2020, 14:02
Does anyone out there have some suggestions for a command line (for NVEncC.exe) that will create an .hevc file that is compatible with UHD blu-ray? I can create one that will compile and play (in UHD and HDR), but any attempts to fast forward/rewind or chapter skip will result in a blank screen (sound only). I've been beating my head against the wall for a couple days now -- and any help would be appreciated.
Thanks.
Mike-uk
26th June 2020, 16:08
Does anyone out there have some suggestions for a command line (for NVEncC.exe) that will create an .hevc file that is compatible with UHD blu-ray? I can create one that will compile and play (in UHD and HDR), but any attempts to fast forward/rewind or chapter skip will result in a blank screen (sound only). I've been beating my head against the wall for a couple days now -- and any help would be appreciated.
Thanks.
mayby post the question on his blog ??
https://rigaya34589.blog.fc2.com/
jdobbs
26th June 2020, 16:35
mayby post the question on his blog ??
https://rigaya34589.blog.fc2.com/Can you post in English in a thread that is in Japanese and has to be interpreted by Google translate?
I was under the impression that people have actually done UHD-BD encodes with this encoder. I'm hoping they can provide me with something that points out what I'm missing.
With this specific behavior I thought that maybe it wasn't creating I frames at the right distances/places, but I brought the resulting HEVC stream up with an HEVC browser and it looks like they are at the right places. I'm thinking now that maybe it's missing some of the supplementary information, but I'm not really sure? I guess I can do some comparisons to X265 output and see. But even if that is it -- I'd still need some way to add it.
Sharc
26th June 2020, 20:08
Can you post in English in a thread that is in Japanese and has to be interpreted by Google translate?
You may want to report it as an issue here (in English):
https://github.com/rigaya/NVEnc/issues
gonca
27th June 2020, 17:42
Does anyone out there have some suggestions for a command line (for NVEncC.exe) that will create an .hevc file that is compatible with UHD blu-ray? I can create one that will compile and play (in UHD and HDR), but any attempts to fast forward/rewind or chapter skip will result in a blank screen (sound only). I've been beating my head against the wall for a couple days now -- and any help would be appreciated.
Thanks.
I tried a barebones command line and I get the same symptoms. Plays fine start to finish, HDR and UHD recognized but ff, rw or chapter select I get black screen
cartman0208
27th June 2020, 22:25
Does anyone out there have some suggestions for a command line (for NVEncC.exe) that will create an .hevc file that is compatible with UHD blu-ray? I can create one that will compile and play (in UHD and HDR), but any attempts to fast forward/rewind or chapter skip will result in a blank screen (sound only). I've been beating my head against the wall for a couple days now -- and any help would be appreciated.
Thanks.
Maybe it's something with the CU-Size ... I noticed that some months ago when I did some 4K testing with nvenc ...
Mediainfo doesn't show it (to me) ... can only be seen in VLC Player:
Video Resolution: 3840x2160
Buffer dimensions: 3840x2176
With CU Size set to 32 and 2160 isn't divisible by 32, result is set to 2176 which could end up in UHD incompatibility ...
In the original mt2s the values are identical.
So .. 2 possibilities ... setting CU size to 16x16 (if possible) or crop away 16 pix vertically and hope its still compatible :D
Just an idea ...
jdobbs
27th June 2020, 22:25
I tried a barebones command line and I get the same symptoms. Plays fine start to finish, HDR and UHD recognized but ff, rw or chapter select I get black screenThanks for confirming it. My guess is there is some supplementary header information missing in the i-frame since that is what is used for FF/REW & CHAP jumps. I'm looking to see if I can find anything and possibly fix it myself. I can't find anything in the command line options that might change it significantly. Of course BD-RB fixing it would mean that after an encode I'd have to scan and rewrite the .hevc file (which can add some time to the process). I posted and error report on the site Sharc listed, hopefully someone will actually see it and respond -- but it looks like there are quite a bit of other reports there as well.
jdobbs
28th June 2020, 01:15
Maybe it's something with the CU-Size ... I noticed that some months ago when I did some 4K testing with nvenc ...
Mediainfo doesn't show it (to me) ... can only be seen in VLC Player:
Video Resolution: 3840x2160
Buffer dimensions: 3840x2176
With CU Size set to 32 and 2160 isn't divisible by 32, result is set to 2176 which could end up in UHD incompatibility ...
In the original mt2s the values are identical.
So .. 2 possibilities ... setting CU size to 16x16 (if possible) or crop away 16 pix vertically and hope its still compatible :D
Just an idea ...Interesting. If I look at the Sequence Parameter Set (NAL_SPS) it also tells me 3840x2176 for the picture height/width in luma samples, while in X265 it correctly says 3840x2160. But it plays when I insert the disc -- which makes me wonder what the significance of it is. You'd think an incorrect resolution would cause it to fail.
There's a discussion on this topic at this link. (https://forums.developer.nvidia.com/t/nvenc-hevc-encoding-of-3840x2160-results-in-coded-size-of-3840x2176/60107) I'm not sure if there is a solution in the works...
[Edit]@cartman0208
The encoder allows me to set the CU to 16 (--cu-max 16) - but it seems to have no affect on the SPS value (as it still says 3840x2176 with a bottom offset of 8). The Blu-Ray spec specifically states that these values aren't allowed -- but my guess is that the player's hardware allows it (per the H.265 standard), and that's why the video is playing back. For right now I'm going to pretend this isn't the issue -- but I'll investigate further.
MrVideo
28th June 2020, 04:01
There's a discussion on this topic at this link. (https://forums.developer.nvidia.com/t/nvenc-hevc-encoding-of-3840x2160-results-in-coded-size-of-3840x2176/60107) I'm not sure if there is a solution in the works...
From what I read in the discussion is that nVidia is telling all the decoder manufactures that do not display 2176 as 2160 (by cropping bottom 16) to get with the spec and go screw yourself.
cartman0208
28th June 2020, 11:25
[Edit]@cartman0208
The encoder allows me to set the CU to 16 (--cu-max 16) - but it seems to have no affect on the SPS value (as it still says 3840x2176 with a bottom offset of 8). The Blu-Ray spec specifically states that these values aren't allowed -- but my guess is that the player's hardware allows it (per the H.265 standard), and that's why the video is playing back. For right now I'm going to pretend this isn't the issue -- but I'll investigate further.
Yep, tried that too with the same result.
What I didn't try was my second suggestion ... initially crop away 16 pixel to a height of 2144, which is divisibly by 32...
Too small should be less of a problem then too big... or does the BluRay standard say EXACTLY 2160px in height?
I'm still wild guessing here, but maybe the screen can't display the oversize and stays blank ...
gonca
28th June 2020, 13:35
I cropped 280 top and bottom, script for a mkv file, and it behaved exactly the same
I know that is an illegal res for BD but the player didn't mind it.
Sharc
28th June 2020, 13:41
Interesting. If I look at the Sequence Parameter Set (NAL_SPS) it also tells me 3840x2176 for the picture height/width in luma samples, while in X265 it correctly says 3840x2160. But it plays when I insert the disc -- which makes me wonder what the significance of it is. You'd think an incorrect resolution would cause it to fail.
There's a discussion on this topic at this link. (https://forums.developer.nvidia.com/t/nvenc-hevc-encoding-of-3840x2160-results-in-coded-size-of-3840x2176/60107) I'm not sure if there is a solution in the works...
[Edit]@cartman0208
The encoder allows me to set the CU to 16 (--cu-max 16) - but it seems to have no affect on the SPS value (as it still says 3840x2176 with a bottom offset of 8). The Blu-Ray spec specifically states that these values aren't allowed -- but my guess is that the player's hardware allows it (per the H.265 standard), and that's why the video is playing back. For right now I'm going to pretend this isn't the issue -- but I'll investigate further.
Isn't this much the same as with x264 AVC: The coded size has always been 1920x1088 while the display size is 1920x1080?
MrVideo
28th June 2020, 17:01
Isn't this much the same as with x264 AVC: The coded size has always been 1920x1088 while the display size is 1920x1080?
Yep, that be the case.
jdobbs
28th June 2020, 22:07
Looking at the output from NVENCC, I'm guessing (but only guessing) that this may be the issue:
According to "White Paper Blu-ray Disc Read-Only Format Coding constraints on HEVC video streams for BD-ROM Version 3.0", page 6, each GOP (Group of Pictures) of the HEVC stream must start with an IDR (of course) -- and will contain one SPS (Sequence Parameter Set), one VPS (Video Parameter Set), and at least one PPS (Picture Parameter Set), and no more than 30 PPSs.
In dumping out the HEVC stream I'm finding that only the first GOP (the first IDR frame and following P/B frames in the file) meets this requirement. All the others IDR frames (start of GOP) I've looked at only have an AUD (Access Unit Delimeter) and a couple SEI's (Supplemental Enhancement Information) preceding the IDR slice.
I'll have to do some finagling with the stream to find out if this is truly the issue -- but it could make sense and explain why the stream can start playing from the beginning (the IDR that has the required information) but can't step into any of the others (FF/REW and CHAPTER SKIPS).
You never know, this may not be the problem at all... but I guess I'm going to have to find out somehow. In X265 you create a stream that contains the SPS/VPS/PPS in every GOP by using the --repeat-headers command line option. I'm hoping the same thing can be done in NVENCC.
I've added this information to my Issue Report at GITHUB. Hopefully someone with a little more HEVC/UHD-BD knowledge than me can confirm or deny this as the cause of the issue I'm seeing.
[Edit] In the meantime, I'm going to see how hard it would be for me to to scan and insert the headers via a software routine -- or if it is even possible. Unfortunately that would require me to read through the entire HEVC file and write a new one -- which requires significant processing time. In the end I may find out it isn't even the problem! :scared:
jdobbs
29th June 2020, 01:54
Looking at the output from NVENCC, I'm guessing (but only guessing) that this may be the issue:
According to "White Paper Blu-ray Disc Read-Only Format Coding constraints on HEVC video streams for BD-ROM Version 3.0", page 6, each GOP (Group of Pictures) of the HEVC stream must start with an IDR (of course) -- and will contain one SPS (Sequence Parameter Set), one VPS (Video Parameter Set), and at least one PPS (Picture Parameter Set), and no more than 30 PPSs.
In dumping out the HEVC stream I'm finding that only the first GOP (the first IDR frame and following P/B frames in the file) meets this requirement. All the others IDR frames (start of GOP) I've looked at only have an AUD (Access Unit Delimeter) and a couple SEI's (Supplemental Enhancement Information) preceding the IDR slice.
I'll have to do some finagling with the stream to find out if this is truly the issue -- but it could make sense and explain why the stream can start playing from the beginning (the IDR that has the required information) but can't step into any of the others (FF/REW and CHAPTER SKIPS).
You never know, this may not be the problem at all... but I guess I'm going to have to find out somehow. In X265 you create a stream that contains the SPS/VPS/PPS in every GOP by using the --repeat-headers command line option. I'm hoping the same thing can be done in NVENCC.
I've added this information to my Issue Report at GITHUB. Hopefully someone with a little more HEVC/UHD-BD knowledge than me can confirm or deny this as the cause of the issue I'm seeing.
[Edit] In the meantime, I'm going to see how hard it would be for me to to scan and insert the headers via a software routine -- or if it is even possible. Unfortunately that would require me to read through the entire HEVC file and write a new one -- which requires significant processing time. In the end I may find out it isn't even the problem! :scared:Well... even a broken clock is right twice a day.
That was it. I wrote some code to insert the SPS/VPS/PPS headers into the IDR of each GOP and... it fixed the issue. Fast Forward, Rewind and Chapter jumps now work.
I'll add code into BD-RB to correct the HEVC stream after encoding. It looks like it will add about 15 minutes or so to a job. But that's not bad considering how much time is saved using the NVENCC encoder. I just ran a complete job on a 2 hour and 22 minute UHD/HDR movie and it finished the encoding portion in less than 30 minutes (using the fastest setting).
I have to add supporting code for several subroutines before BD-RB is ready for a testing release -- expect it in the next week or so.
I will also update my issue information on GITHUB and hopefully all the will have to do is add a "--repeat-headers" command line function and make my workaround unneeded.
Sharc
29th June 2020, 09:13
I will also update my issue information on GITHUB and hopefully all the will have to do is add a "--repeat-headers" command line function and make my workaround unneeded.
Now let's hope that rigaya takes action :cool:
Ch3vr0n
29th June 2020, 09:30
2h22m compared to what for you @jdobbs? 16hrs? ^^
Mike-uk
29th June 2020, 12:06
i guess this blank issue is only present on a bluray player, was playing the file on a pc ok ??
jdobbs
29th June 2020, 12:51
i guess this blank issue is only present on a bluray player, was playing the file on a pc ok ??Yes. It was only an issue when authored into BD format and played on a Blu-Ray player. On a PC it had worked fine. I didn't test it, but I would assume an MKV or MP4 would probably have played even on the BD unit. The issue (needing the headers in each GOP) is related to the container type used in an authored BD.
jdobbs
29th June 2020, 12:57
2h22m compared to what for you @jdobbs? 16hrs? ^^2h22m was the length of the movie. The actual job only about 45 minutes start-to-finish (before correcting the HEVC stream). And, yes, using X265 it would have probably taken somewhere in the neighborhood of 16 hours.
cartman0208
29th June 2020, 14:21
Can't wait to do some alpha tesing ;)
Ch3vr0n
29th June 2020, 14:59
I don't suppose this will be of benefit for 3D encoding would it. Last time i tried hw acc FRIM it resulted in severe artifacts for software based players.
jdobbs
29th June 2020, 18:01
I don't suppose this will be of benefit for 3D encoding would it. Last time i tried hw acc FRIM it resulted in severe artifacts for software based players.Sorry, no.
I haven't looked at FRIM or 3D in a while, but I seem to remember that problem as being related to drivers.
Ch3vr0n
29th June 2020, 18:02
I believe a while back someone said there was an updated FRIM build that supposedly fixed that problem. I just have no idea where to get it.
Sent from my Pixel 3 XL using Tapatalk
musiclover
29th June 2020, 19:24
I believe a while back someone said there was an updated FRIM build that supposedly fixed that problem. I just have no idea where to get it.
Sent from my Pixel 3 XL using Tapatalk
https://www.videohelp.com/software/FRIM and https://forum.doom9.org/showthread.php?t=169651
Ch3vr0n
29th June 2020, 21:27
Which one would i need for BDRB, the 32bit version? My cpu is a 9900K
gonca
29th June 2020, 21:32
32 bit
Mike-uk
29th June 2020, 22:56
bdrebuilder uses frim 1.25, there has been 5 updates and now 1.31
jdobbs
30th June 2020, 01:46
Anybody else experiencing this?
I can start NVENCC with a fixed command line.
When I start the job it seems to be slower than I'd expected -- about 125fps. So I stop the job and restart it. Suddenly I'm getting 420fps... with the exact same command line. Try it again... and it's random. I might get either of the two speeds. Weird.
Now THAT's confusing.
MrVideo
30th June 2020, 03:44
Well... even a broken clock is right twice a day.
Not if it is a digital clock and the display goes dark/blank. :eek:
Sharc
30th June 2020, 07:45
Anybody else experiencing this?
I can start NVENCC with a fixed command line.
When I start the job it seems to be slower than I'd expected -- about 125fps. So I stop the job and restart it. Suddenly I'm getting 420fps... with the exact same command line. Try it again... and it's random. I might get either of the two speeds. Weird.
Now THAT's confusing.
Strange. Did you check the GPU load and temperature (e.g. using GPU-Z)? Is the speed limited by the GPU or by the bus transfers/memory access? Are you using HDD or SSD? Virus scanner interference, or some other background process interfering?
What I noticed here (NVEncC x264 1050Ti) is an initial speed increase during the first few (say 10) seconds which then settles to a steady value.
Emulgator
30th June 2020, 10:17
When I start the job it seems to be slower than I'd expected -- about 125fps. So I stop the job and restart it. Suddenly I'm getting 420fps... with the exact same command line. Try it again... and it's random. I might get either of the two speeds. Weird.
Now THAT's confusing.
An app being quicker on second run is no mystery, happens with sore more SW.
Its just that these date are still kept in RAM.
Like with tsMuxeR, muxing time went from 9..10 min first run
down to 1,5 minutes for the same 10GB test stream on second and third run.
(Magnetic platter HDDs used, with SSD maybe unnoticeable)
I just extensively tested for one particular stream losing packets at the end.
(solved since the 2020-06-27 build for me, BTW)
Would fit the available 32GB RAM. (Did not run RAMMap though to confirm)
Why it would be slower on third run, I cannot comment.
But if I close the app and allow the RAM to be flushed, then it may take the full first running time again.
cartman0208
30th June 2020, 11:56
Anybody else experiencing this?
I can start NVENCC with a fixed command line.
When I start the job it seems to be slower than I'd expected -- about 125fps. So I stop the job and restart it. Suddenly I'm getting 420fps... with the exact same command line. Try it again... and it's random. I might get either of the two speeds. Weird.
Now THAT's confusing.
Can you post that commandline?
Mike-uk
30th June 2020, 12:44
ohhh looks like nvencc has fixed/added the repeat issue :)
Mike-uk
30th June 2020, 13:23
Anybody else experiencing this?
I can start NVENCC with a fixed command line.
When I start the job it seems to be slower than I'd expected -- about 125fps. So I stop the job and restart it. Suddenly I'm getting 420fps... with the exact same command line. Try it again... and it's random. I might get either of the two speeds. Weird.
Now THAT's confusing.
hmm im only get 66 FPS regardless how many time i restart, just a note 400 fps sounds too quick, gpu encoding doesnt give same quality as cpu, so id be happy for gpu to be spitting out the best quality it can do "--preset quality" even if that means less fps, im sure gpu at max quality will be a lot quicker than cpu, will be nice to have the option of HW excelearion, will you be including 264 hw exceleration also ?
in using a RTX 2070 Super
NVEncC (x64) 5.06 (r1569) by rigaya, Jun 16 2020 13:25:14 (VC 1916/Win/avx2)
[NVENC API v9.1, CUDA 10.1]
reader: raw, y4m, avi, avs, vpy, avsw, avhw [H.264/AVC, H.265/HEVC, MPEG2, VP8, VP9, VC-1, MPEG1, MPEG4]
Environment Info
OS : Windows 10 x64 (19041)
CPU: Intel Core i7-8700K @ 3.70GHz [TB: 4.30GHz] (6C/12T)
RAM: Used 7414 MB, Total 16311 MB
#0: GeForce RTX 2070 SUPER (2560 cores, 1800 MHz)[PCIe3x16][451.48]
NVEnc features
Codec: H.264/AVC
Max Bframes 4
B Ref Mode yes
RC Modes 63
Field Encoding no
MonoChrome no
FMO no
Quater-Pel MV yes
B Direct Mode yes
CABAC yes
Adaptive Transform yes
Max Temporal Layers 0
Hierarchial P Frames no
Hierarchial B Frames no
Max Level 62
Min Level 10
4:4:4 yes
Min Width 145
Max Width 4096
Min Height 49
Max Height 4096
Multiple Refs yes
Max LTR Frames 8
Dynamic Resolution Change yes
Dynamic Bitrate Change yes
Forced constant QP yes
Dynamic RC Mode Change no
Subframe Readback yes
Constrained Encoding yes
Intra Refresh yes
Custom VBV Bufsize yes
Dynamic Slice Mode yes
Ref Pic Invalidiation yes
PreProcess no
Async Encoding yes
Max MBs 65536
Lossless yes
SAO no
Me Only Mode yes
Lookahead yes
AQ (temporal) yes
Weighted Prediction yes
10bit depth no
Codec: H.265/HEVC
Max Bframes 5
B Ref Mode yes
RC Modes 63
Field Encoding no
MonoChrome no
Quater-Pel MV yes
B Direct Mode no
Max Temporal Layers 0
Hierarchial P Frames no
Hierarchial B Frames no
Max Level 186
Min Level 30
4:4:4 yes
Min Width 129
Max Width 8192
Min Height 33
Max Height 8192
Multiple Refs yes
Max LTR Frames 7
Dynamic Resolution Change yes
Dynamic Bitrate Change yes
Forced constant QP yes
Dynamic RC Mode Change no
Subframe Readback yes
Constrained Encoding yes
Intra Refresh yes
Custom VBV Bufsize yes
Dynamic Slice Mode yes
Ref Pic Invalidiation yes
PreProcess no
Async Encoding yes
Max MBs 262144
Lossless yes
SAO yes
Me Only Mode yes
Lookahead yes
AQ (temporal) yes
Weighted Prediction yes
10bit depth yes
NVDec features
H.264/AVC: nv12, yv12
H.265/HEVC: nv12, yv12, yv12(9bit), yv12(10bit), yv12(12bit), yuv444, yuv444(9bit), yuv444(10bit), yuv444(12bit)
MPEG1: nv12, yv12
MPEG2: nv12, yv12
MPEG4: nv12, yv12
VP8: nv12, yv12
VP9: nv12, yv12, yv12(9bit), yv12(10bit), yv12(12bit)
VC-1: nv12, yv12
Ch3vr0n
30th June 2020, 17:23
i'll experiment with the updated version. I'll have to go into the bios to enable the iGPU. That's a job for upcoming weekend.
jdobbs
30th June 2020, 17:27
Can you post that commandline?I've deleted it. Right now I'm in the middle of system backups, but I'll post an example later.
Thanks.
jdobbs
30th June 2020, 17:32
ohhh looks like nvencc has fixed/added the repeat issue :)Wow. That's are really quick response! I just downloaded it and will do some testing after my backups finish. I added code to BD-RB yesterday to scan/add the headers -- but I'm very happy to remove it! I'd much rather have the encoder do it!
MrVideo
30th June 2020, 20:18
[...] will be nice to have the option of HW excelearion, will you be including 264 hw exceleration also?
I think you mean acceleration. Also, when posting long lists like that, please CODE wrap them.
Mike-uk
30th June 2020, 21:06
I think you mean acceleration. Also, when posting long lists like that, please CODE wrap them.
:p yes acceleration, code wrap done
jdobbs
30th June 2020, 23:10
Can you post that commandline?"D:\BD_Rebuilder\tools\nvenc\nvencc.exe" --avhw -i "N:\BD\SOURCE\BDMV\STREAM\00500.m2ts" --codec h264 --preset quality --bluray --qp-min 0 --vbr 22429 --keyfile "D:\WORKING4\WORKFILES\VID_00500.CHP" --sar 1:1 --aud --pic-struct --vbv-bufsize 30000 --max-bitrate 35000 --gop-len 24 -o "D:\WORKING4\WORKFILES\VID_00500.AVS.264"
hmm im only get 66 FPS regardless how many time i restart, just a note 400 fps sounds too quick, gpu encoding doesnt give same quality as cpu, so id be happy for gpu to be spitting out the best quality it can do "--preset quality" even if that means less fps, im sure gpu at max quality will be a lot quicker than cpu, will be nice to have the option of HW excelearion, will you be including 264 hw exceleration also ?I'm guessing you are talking about a 2160p source. The one in which I was getting the goofy numbers was a h264 stream at 1080p.
Mike-uk
30th June 2020, 23:46
"
I'm guessing you are talking about a 2160p source. The one in which I was getting the goofy numbers was a h264 stream at 1080p.
yes was 2160p
jdobbs
1st July 2020, 13:16
Just a head's up. I tested the new version of NVENCC yesterday, and the new option to include headers results an encoding failure with a "Cannot allocate memory" message. Removing the new option from the command line makes the encoding error goes away. But, then, of course you're back to having the FF/REW/CHAP issues. I posted an issue report on GITHUB. It appears that the new option creates a memory leak (as can be observed by watching the process under the Windows 10 task manager). On the 32 bit version of NCENCC it hits the memory limitation pretty quickly (you have to use the 32 bit version to remain compatible with AVISYNTH 2.60 -- which must be used under certain circumstances).
So the options right now are to wait and see if it gets another quick fix, or to go ahead and implement the code that adds the headers within BD-RB. I'd prefer the first option, as that's a cleaner way to go. So I'm going to wait for a bit and see what happens.
Mike-uk
1st July 2020, 14:39
Id wait a while and see if it gets fixed, i can also conform its eating memory, at frame 69522 it consumed 1.6 gig of memory and then errored, im running 16 gig but according to task manager i was only at 50% mem ussage ?
gonca
1st July 2020, 16:16
I think the wait is over
5.08 is out
Mike-uk
1st July 2020, 16:40
I think the wait is over
5.08 is out
unfortunatly not :( not good news :(
Please try with x64 build of NVEnc 5.08, it should not require nppc64_10.dll now.
It might be a memory leak but it's difficult to fix, as "--repeat-headers" only sets a parameter provided by NVENC SDK, there is little I can do here.
gonca
1st July 2020, 16:54
Yes, but issue 246 seemed to develop with 5.07 has been resolved
Running a quick test, to see if it finishes
gonca
1st July 2020, 17:23
Update 1
80000 frames out of 188855
RAM usage is steady 582.5 MB
x265 is using 6.7 GB
Update 2
110000 frames
Completed fine
[2020-07-01][12:02:46] Simple x264 Launcher (Build #1208), built 2020-06-25
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] Job started at 2020-07-01, 12:02:46.
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] Source file : I:\PACIFIC RIM.vpy
[2020-07-01][12:02:46] Output file : T:\\PACIFIC RIM.hevc
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] --- SYSTEMINFO ---
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] Binary Path : C:\Users\LUIS\Desktop\x264_launcher.2020-06-25
[2020-07-01][12:02:46] Avisynth : Yes
[2020-07-01][12:02:46] VapourSynth : Yes
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] --- SETTINGS ---
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] Encoder : NVEncC, 64-Bit (x64), HEVC
[2020-07-01][12:02:46] Source : VapourSynth (vpy)
[2020-07-01][12:02:46] RC Mode : CQP
[2020-07-01][12:02:46] Preset : performance
[2020-07-01][12:02:46] Tuning : <None>
[2020-07-01][12:02:46] Profile : main10
[2020-07-01][12:02:46] Custom :
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)"
--max-cll "2465,823" --frames 188855 --chromaloc 2 --colormatrix bt2020nc --colorprim bt2020
--transfer smpte2084 --repeat-headers
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] --- CHECK VERSION ---
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] Detect video encoder version:
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] Creating process:
[2020-07-01][12:02:46] C:\Users\LUIS\Desktop\x264_launcher.2020-06-25\toolset\x64\nvencc\nvencc64.exe --version
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] NVEncC (x64) 5.08 (r1585) by rigaya, Jul 1 2020 15:17:08 (VC 1916/Win/avx2)
[2020-07-01][12:02:46] [NVENC API v9.1, CUDA 10.1]
[2020-07-01][12:02:46] reader: raw, y4m, avi, avs, vpy, avsw, avhw [H.264/AVC, H.265/HEVC, MPEG2, VP8, VP9, VC-1, MPEG1, MPEG4]
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] WARNING: Your version of NVEncC is newer than the latest tested version, take care!
[2020-07-01][12:02:46] This application works best with NVEncC version 5.6. Newer versions may work or not.
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] Detect video source version:
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] Creating process:
[2020-07-01][12:02:46] "C:\Program Files\VapourSynth\core\vspipe.exe" --version
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] VapourSynth Video Processing Library
[2020-07-01][12:02:46] Copyright (c) 2012-2020 Fredrik Mellbin
[2020-07-01][12:02:46] Core R50
[2020-07-01][12:02:46] API R3.6
[2020-07-01][12:02:46] Options: -
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] > NVEncC version: 5.80 [rev #1585]
[2020-07-01][12:02:46] > VapourSynth version: r50 (API r3)
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] --- GET SOURCE INFO ---
[2020-07-01][12:02:46]
[2020-07-01][12:02:46] Creating process:
[2020-07-01][12:02:46] "C:\Program Files\VapourSynth\core\vspipe.exe" --info "I:\\pacific rim.vpy" -
[2020-07-01][12:02:46]
[2020-07-01][12:02:47] Width: 3840
[2020-07-01][12:02:47] Height: 2160
[2020-07-01][12:02:47] Frames: 188855
[2020-07-01][12:02:47] FPS: 24000/1001 (23.976 fps)
[2020-07-01][12:02:47] Format Name: YUV420P10
[2020-07-01][12:02:47] Color Family: YUV
[2020-07-01][12:02:47] Alpha: No
[2020-07-01][12:02:47] Sample Type: Integer
[2020-07-01][12:02:47] Bits: 10
[2020-07-01][12:02:47] SubSampling W: 1
[2020-07-01][12:02:47] SubSampling H: 1
[2020-07-01][12:02:47]
[2020-07-01][12:02:47] Resolution: 3840 x 2160
[2020-07-01][12:02:47] Frame Rate: 24000/1001
[2020-07-01][12:02:47] No. Frames: 188855
[2020-07-01][12:02:47]
[2020-07-01][12:02:47] --- ENCODING VIDEO ---
[2020-07-01][12:02:47]
[2020-07-01][12:02:47] Creating input process:
[2020-07-01][12:02:47] "C:\Program Files\VapourSynth\core\vspipe.exe" --y4m "I:\\pacific rim.vpy" -
[2020-07-01][12:02:47]
[2020-07-01][12:02:47] WARNING: Custom parameter "--frames" will be ignored in Pipe'd mode!
[2020-07-01][12:02:47]
[2020-07-01][12:02:47] Creating encoder process:
[2020-07-01][12:02:47] C:\Users\LUIS\Desktop\x264_launcher.2020-06-25\toolset\x64\nvencc\nvencc64.exe
--codec hevc --preset performance --cqp 30 --profile main10
--master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)
--max-cll 2465,823
--chromaloc 2 --colormatrix bt2020nc --colorprim bt2020 --transfer smpte2084 --repeat-headers
--output "T:\\PACIFIC RIM.hevc" --y4m --input -
[2020-07-01][12:02:47]
[2020-07-01][12:02:50] --------------------------------------------------------------------------------
[2020-07-01][12:02:50] T:\\PACIFIC RIM.hevc
[2020-07-01][12:02:50] --------------------------------------------------------------------------------
[2020-07-01][12:02:50] Max B frames are 0 frames.
[2020-07-01][12:02:50] NVEncC (x64) 5.08 (r1585) by rigaya, Jul 1 2020 15:17:08 (VC 1916/Win/avx2)
[2020-07-01][12:02:50] OS Version Windows 10 x64 (14393)
[2020-07-01][12:02:50] CPU Intel Core i7-6900K @ 3.20GHz [TB: 3.50GHz] (8C/16T)
[2020-07-01][12:02:50] GPU #0: GeForce GTX 1080 Ti (3584 cores, 1670 MHz)[PCIe3x16][445.87]
[2020-07-01][12:02:50] NVENC / CUDA NVENC API 9.1, CUDA 11.0, schedule mode: auto
[2020-07-01][12:02:50] Input Buffers CUDA, 13 frames
[2020-07-01][12:02:50] Input Info y4m(yv12(10bit))->p010 [AVX2], 3840x2160, 24000/1001 fps
[2020-07-01][12:02:50] Vpp Filters copyHtoD
[2020-07-01][12:02:50] Output Info H.265/HEVC main10 @ Level auto
[2020-07-01][12:02:50] 3840x2160p 1:1 23.976fps (24000/1001fps)
[2020-07-01][12:02:50] Encoder Preset performance
[2020-07-01][12:02:50] Rate Control CQP I:30 P:30 B:30
[2020-07-01][12:02:50] Lookahead off
[2020-07-01][12:02:50] GOP length 240 frames
[2020-07-01][12:02:50] B frames 0 frames [ref mode: disabled]
[2020-07-01][12:02:50] Ref frames 3 frames
[2020-07-01][12:02:50] AQ off
[2020-07-01][12:02:50] CU max / min auto / auto
[2020-07-01][12:02:50] VUI matrix:bt2020nc,colorprim:bt2020,transfer:smpte2084,chromaloc:topleft
[2020-07-01][12:02:50] MasteringDisp G(0.265000 0.690000) B(0.150000 0.060000) R(0.680000 0.320000)
[2020-07-01][12:02:50] WP(0.312700 0.329000) L(4000.000000 0.005000)
[2020-07-01][12:02:50] MaxCLL/MaxFALL 2465/823
[2020-07-01][12:02:50] Others mv:auto repeat-headers
[2020-07-01][12:48:45] encoded 188855 frames, 68.51 fps, 4745.73 kbps, 4456.20 MB
[2020-07-01][12:48:45] encode time 0:45:56, CPU: 8.4, GPU: 35.4, VE: 32.4, VD: 39.3, GPUClock: 1936MHz, VEClock: 1645MHz
[2020-07-01][12:48:45] frame type IDR 787
[2020-07-01][12:48:45] frame type I 787, total size 40.78 MB
[2020-07-01][12:48:45] frame type P 188068, total size 4415.41 MB
[2020-07-01][12:48:45] vpyp [info]: Output 188855 frames in 2757.37 seconds (68.49 fps)
[2020-07-01][12:48:45] Final file size is 4.35 GB bytes.
[2020-07-01][12:48:45]
[2020-07-01][12:48:45] --- COMPLETED ---
[2020-07-01][12:48:45]
[2020-07-01][12:48:45] Job finished at 2020-07-01, 12:48:45. Process took 45 minutes, 59 seconds.
gonca
1st July 2020, 18:04
Finished a remux and it seems to work
FF, REW and CHP skips
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.