I'm going from top of my head, but iirc they've had a few versions of nvenc so they're keeping the older around for backware compat.
On Fri, Jul 16, 2021 at 1:39 PM Andrew Randrianasulu < [email protected]> wrote: > > > On Friday, July 16, 2021, gorge rankin <[email protected]> wrote: > >> Sorry, just saw your note asking me to confirm if ffmpeg can do >> h264/nvenc: >> >> cmd:~/cinelerra/thirdparty/ffmpeg-4.3$ ffmpeg -encoders >> > > > i think you need full_path/ffmpeg, for launching our self-compiled copy > instead if system-vide one... > > > Encoders: >> V..... = Video >> A..... = Audio >> S..... = Subtitle >> .F.... = Frame-level multithreading >> ..S... = Slice-level multithreading >> ...X.. = Codec is experimental >> ....B. = Supports draw_horiz_band >> .....D = Supports direct rendering method 1 >> >> V..... libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 >> part 10 (codec h264) >> V..... libx264rgb libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 >> part 10 RGB (codec h264) >> V..... h264_nvenc NVIDIA NVENC H.264 encoder (codec h264) >> V..... h264_omx OpenMAX IL H.264 video encoder (codec h264) >> V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 >> (Intel Quick Sync Video acceleration) (codec h264) >> V..... h264_v4l2m2m V4L2 mem2mem H.264 encoder wrapper (codec >> h264) >> V..... h264_vaapi H.264/AVC (VAAPI) (codec h264) >> V..... nvenc NVIDIA NVENC H.264 encoder (codec h264) >> V..... nvenc_h264 NVIDIA NVENC H.264 encoder (codec h264) >> > > > strange, two, even three nvenc_h264?? > > > >> So yes, it's built to handle it. Also, since I'm encoing 1440p videos in >> realtime in RGBA mode, it has to be working, myh computer is not that fast >> LOL >> >> Also in the nvidia control panel, and I can see this: >> [image: image.png] >> But the percentage will hit up to 30-50% many times. >> >> On Fri, Jul 16, 2021 at 1:19 PM gorge rankin <[email protected]> >> wrote: >> >>> oh, and I dropped down to cuda 10, that made no difference >>> >>> On Fri, Jul 16, 2021 at 1:18 PM gorge rankin <[email protected]> >>> wrote: >>> >>>> some progress, So in short, it appears changing the workspace color >>>> format to YUVA-8Bit from RGBA-8Bit is where my slow down occurs. >>>> >>>> OK, so my videos are from OBS: >>>> color format: nv12 >>>> color space 709 >>>> color range: partial >>>> h264/nvenc/mkv >>>> >>>> so that's their defaults. those are under advanced, and I would assume >>>> normal users dont change such things. >>>> >>>> mediainfo reports the files as having yuv420 with color range of BT.709 >>>> >>>> I get very fast rendering if cin has: >>>> Settings->Format RGBA-8Bit >>>> Render to yuv420 >>>> Speed is 1 to 1 for the above with nvenc. >>>> >>>> However, if I use the above, then my files have too much brightness, >>>> the contrast and colors are off. >>>> >>>> So, I need to use to have my output files with proper color/bright. >>>> This is dramatically slower. >>>> Settings->Format YUVA-8Bit >>>> Render to yuv44p >>>> >>>> The only way to get my video's to look kind of like the originals in >>>> decent time >>>> Settings->Format RBGA-8Bit >>>> Render to yuv420p >>>> Add filters to adjust bright, colors. This is way faster than using >>>> YUV, but obv slower than normal RBGA as I'm using filters now which slows >>>> things down some, but at least it's liveable. >>>> >>>> >>>> >>>> >>>> On Fri, Jul 16, 2021 at 3:24 AM gorge rankin <[email protected]> >>>> wrote: >>>> >>>>> ok, built it, but same issue, very slow. >>>>> >>>>> On Fri, Jul 16, 2021 at 2:45 AM gorge rankin <[email protected]> >>>>> wrote: >>>>> >>>>>> I'm building cin now as I type this. >>>>>> >>>>>> I just saw this when it was building ffmpeg, >>>>>> clang: warning: Unknown CUDA version. cuda.h: CUDA_VERSION=11030. >>>>>> Assuming the latest supported version 10.1 [-Wunknown-cuda-version] >>>>>> >>>>>> Maybe my CUDA is too new? >>>>>> >>>>>> On Thu, Jul 15, 2021 at 1:26 PM Andrew Randrianasulu < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thursday, July 15, 2021, gorge rankin via Cin < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I've only been using cin for about 3 months. I could have sworn I >>>>>>>> tested the render speed vs others and was happy. This is just odd. >>>>>>>> >>>>>>> >>>>>>> may be some library/driver was updated system-wide...? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I've tried the render farm idea as well. Sometimes tho, I get an >>>>>>>> empty file. Don't know why. So I'm gun shy to try it for this project >>>>>>>> where I have 3 hours estimated, it's only 15 minute video, ugh. >>>>>>>> >>>>>>> >>>>>>> yeah, emoty files for renderfarm-locally sounds like bug. I think I >>>>>>> run into some odd behavior when I was playing locally (on arm/termux) >>>>>>> with >>>>>>> renderfarm. Try to increase number of pieces for each job and timeout, >>>>>>> too? >>>>>>> in preferences... >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> There are no errors at all printed to the console if I launch cin >>>>>>>> from the terminal. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> odd... >>>>>>> >>>>>>>> >>>>>>>> The nvidia settings do show that about 5-8% load. I'm used to >>>>>>>> seeing that at 50-60% in other editors and also in OBS. >>>>>>>> >>>>>>> >>>>>>> what setting you have for "Use HW device" in >>>>>>> preferencies->performance? only affect decoding.. What video outputt >>>>>>> driver >>>>>>> setting in Cin you use? >>>>>>> >>>>>>>> >>>>>>>> I know my pc is not "new" and the "fastest" but it would be faster >>>>>>>> if I were to make the compositor borderless and record that with OBS. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> due to lack if hw encoding accel in termux (on android) I record >>>>>>> with system's recorder, so this is... workaround... >>>>>>> >>>>>>>> >>>>>>>> It's really odd, the compositor isn't dropping any frames >>>>>>>> whatsoever. All my effects look *awesome * in the compositor. The >>>>>>>> app is >>>>>>>> running awesome. I've not had a crash at all. >>>>>>>> >>>>>>> >>>>>>> good, but slow encoding still a problem.. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 15, 2021 at 8:32 AM Andrea paz via Cin < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Lately many people are experiencing performance problems in >>>>>>>>> encoding, >>>>>>>>> I am one of them. I think the cause is the lack of multithreading >>>>>>>>> in >>>>>>>>> encoding (but also decoding in timeline). >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> you can try to add printf("ff_cpus: %i, \n", ff_cpus) ; to few >>>>>>> places in cinelerra/ffmpeg.C and see if it was dropping down to 1 or 0 >>>>>>> somewhat? as crude hack you can force it to your number of threads.... >>>>>>> >>>>>>> >>>>>>> >>>>>>> $ cat cinelerra/ffmpeg.C | grep ff_cpu >>>>>>> avctx->thread_count = >>>>>>> ffmpeg->ff_cpus(); >>>>>>> ctx->thread_count = ff_cpus(); >>>>>>> int FFMPEG::ff_cpus() >>>>>>> avctx->thread_count = ff_cpus(); >>>>>>> $ >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> A rendering done with >>>>>>>>> external ffmpeg from command line is much more efficient than the >>>>>>>>> same >>>>>>>>> rendering done in CinGG (always using ffmpeg). >>>>>>>>> No fix has been found, only a workaround that makes use of the >>>>>>>>> Render Farm: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://cinelerra-gg.org/download/CinelerraGG_Manual/Render_Farm_Usage.html >>>>>>>>> >>>>>>>>> Lately the user fary54 has made available his script to automate >>>>>>>>> the >>>>>>>>> use of the render farm and external ffmpeg. Above all it is >>>>>>>>> suitable >>>>>>>>> for CPUs with many threads. You can find the script and >>>>>>>>> explanations >>>>>>>>> here: >>>>>>>>> >>>>>>>>> https://www.cinelerra-gg.org/bugtracker/view.php?id=575 >>>>>>>>> -- >>>>>>>>> Cin mailing list >>>>>>>>> [email protected] >>>>>>>>> https://lists.cinelerra-gg.org/mailman/listinfo/cin >>>>>>>>> >>>>>>>>
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
