file a bug, then... from what I remember (from manual!) yuva-8 in Cinelerra actually more like yuv 4:4:4 (no subsampling, 8 bit resolution for each channel) but ffmpeg should convert it automagically... more debugging needed (
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 > 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) > > 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
