Hello, I've not done many renders since I'm learning. Well I made a project. It was slow. Really slow. My media: from OBS, 60fps, yuv, bt.709, 15 seconds long, 1440p. I've told cin to use yuv444p with the presets so colors match up. project is using format YUVA-8 Bit. it takes me 3 minutes to render and I've only pasted the clip and said render and use the h264/nvenc preset. so to be clear I'm just re-rendering a video, no edits nothing! I've tried many of the other presets. My computer is an i5 skylake with 16 gig of ram, ubuntu 21.04 using 6053512f2d26fbc13432632eeaa52017 cin_for_newer_distros.AppImage for comparisons sake, the same video in shotcut renders in 3 seconds with nvenc. Any thoughts? Thank you for any help you can provide.
On Thursday, July 15, 2021, gorge rankin via Cin <[email protected]> wrote:
Hello,
I've not done many renders since I'm learning.
Well I made a project. It was slow. Really slow.
My media:
from OBS, 60fps, yuv, bt.709, 15 seconds long, 1440p.
I've told cin to use yuv444p with the presets so colors match up. project is using format YUVA-8 Bit.
it takes me 3 minutes to render and I've only pasted the clip and said render and use the h264/nvenc preset.
so to be clear I'm just re-rendering a video, no edits nothing!
I've tried many of the other presets.
My computer is an i5 skylake with 16 gig of ram, ubuntu 21.04 using
6053512f2d26fbc13432632eeaa52017 cin_for_newer_distros.AppImage
can you post complete terminal output from lauching cin from console? I suspect hw encoding (or decoding, or both) failed to initialize for some reason...
for comparisons sake, the same video in shotcut renders in 3 seconds with nvenc.
Any thoughts? Thank you for any help you can provide.
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). 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
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. 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. There are no errors at all printed to the console if I launch cin from the terminal. 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. 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. 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. 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). 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
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
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
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
On Friday, July 16, 2021, gorge rankin <[email protected]> wrote:
ok, built it, but same issue, very slow.
{ can you look into and confirm thirdparty/ffmpeg-4.3/ffmpeg actually can use nvenc acceleration?
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
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
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
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 >
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 >> >
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 >> >
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 >>> >>
Gorge,
I tested the render speed vs others and was happy.
You probably originally tested with default setups which generally are fast because they are simple. I've tried the render farm idea as well. Sometimes tho, I get an empty
file. Don't know why.
You should get the best results using the render farm -- I would work on getting this going so you can always use it because as far as I can tell, the I5 Skylake is 4 cpus (?). Which isn't really that many these days but it is certainly better than using only 1 which is what you would be using with just software rendering. clang: warning: Unknown CUDA version.
Cuda message is just a warning and not needed here and would not help. 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.
Tomorrow, I will try testing on another computer here that has an Nvdia graphics board with the nvenc mp4 format. It is AMD instead of Intel but should be about the same. On Fri, Jul 16, 2021 at 11:45 AM gorge rankin via Cin < [email protected]> wrote:
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
There are no errors at all printed to the console if I launch cin from the terminal.
Just FYI, on a non-Nvidia laptop, you will get the following errors on the terminal where there is no Nvidia graphics card: [h264_nvenc @ 0x7f0780085a40] Cannot load libcuda.so.1 FFMPEG::open_encoder err: Operation not permitted int FFMPEG::open_encoder(const char*, const char*): open failed h264_nvenc:/tmp/testnvenc.mp4 So, it sure looks like "nvenc" is working in Gorge's case.
Also in the nvidia control panel, and I can see this:
But the percentage will hit up to 30-50% many times.
Hello, just some feedback on my investigation. I've discovered that if I use mpeg color range instead of YUV, my speed to render out to yuv420p/nvenc are same as shotcut (for reference purposes). Near realtime (10 sec video renders in 10 seconds with no edits). Colors of output video seem to be same as input. I've been using kcolorchooser and I cant find a diff. I see in the manual, that 'mpeg' offers less color range than jpeg, but my outputs look just like my input videos. If there is a difference, I certainly cannot see it. However, the speed only holds if I use 60fps video or less. Making color changes, brightness, zoom all seem to be reasonable and on par to what I'm used to seeing in shotcut. However, if my source material is over 60 FPS , the speed of encoding significantly drops off for something as simple as "trim". Going forward, I can convert my sources in ffmpeg, no biggie. I'll have to keep my sources tho for future 'just in case'. Attached is a photo of my settings that I'm using for OBS and cin with nvenc for going forward. [image: my-cin-setup-for-obs-videos.png] On Sat, Jul 17, 2021 at 12:22 AM Phyllis Smith via Cin < [email protected]> wrote:
There are no errors at all printed to the console if I launch cin from the
terminal.
Just FYI, on a non-Nvidia laptop, you will get the following errors on the terminal where there is no Nvidia graphics card:
[h264_nvenc @ 0x7f0780085a40] Cannot load libcuda.so.1 FFMPEG::open_encoder err: Operation not permitted int FFMPEG::open_encoder(const char*, const char*): open failed h264_nvenc:/tmp/testnvenc.mp4
So, it sure looks like "nvenc" is working in Gorge's case.
Also in the nvidia control panel, and I can see this:
But the percentage will hit up to 30-50% many times.
--
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Sunday, July 18, 2021, gorge rankin via Cin <[email protected]> wrote:
Hello, just some feedback on my investigation.
thanks for digging & repirting back!
I've discovered that if I use mpeg color range instead of YUV, my speed to render out to yuv420p/nvenc are same as shotcut (for reference purposes). Near realtime (10 sec video renders in 10 seconds with no edits). Colors of output video seem to be same as input. I've been using kcolorchooser and I cant find a diff.
I see in the manual, that 'mpeg' offers less color range than jpeg, but my outputs look just like my input videos. If there is a difference, I certainly cannot see it.
i think mpeg4/h264 use same limited (mpeg) color range, so nothing to loose from default already compressed in h264 input...
However, the speed only holds if I use 60fps video or less. Making color changes, brightness, zoom all seem to be reasonable and on par to what I'm used to seeing in shotcut.
However, if my source material is over 60 FPS , the speed of encoding significantly drops off for something as simple as "trim".
does plain ffmpeg/shotcut encode such files better (faster) with same nvenc?
Going forward, I can convert my sources in ffmpeg, no biggie. I'll have to keep my sources tho for future 'just in case'.
Attached is a photo of my settings that I'm using for OBS and cin with nvenc for going forward.
thanks, it seems current nvenc might have some not-so-obvious limitations, might be worth mentioning in manual (with hw description and driver version)
[image: my-cin-setup-for-obs-videos.png]
On Sat, Jul 17, 2021 at 12:22 AM Phyllis Smith via Cin < [email protected]> wrote:
There are no errors at all printed to the console if I launch cin from
the terminal.
Just FYI, on a non-Nvidia laptop, you will get the following errors on the terminal where there is no Nvidia graphics card:
[h264_nvenc @ 0x7f0780085a40] Cannot load libcuda.so.1 FFMPEG::open_encoder err: Operation not permitted int FFMPEG::open_encoder(const char*, const char*): open failed h264_nvenc:/tmp/testnvenc.mp4
So, it sure looks like "nvenc" is working in Gorge's case.
Also in the nvidia control panel, and I can see this:
But the percentage will hit up to 30-50% many times.
--
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Sunday, July 18, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Sunday, July 18, 2021, gorge rankin via Cin <[email protected]> wrote:
Hello, just some feedback on my investigation.
thanks for digging & repirting back!
I've discovered that if I use mpeg color range instead of YUV, my speed to render out to yuv420p/nvenc are same as shotcut (for reference purposes). Near realtime (10 sec video renders in 10 seconds with no edits). Colors of output video seem to be same as input. I've been using kcolorchooser and I cant find a diff.
I see in the manual, that 'mpeg' offers less color range than jpeg, but my outputs look just like my input videos. If there is a difference, I certainly cannot see it.
i think mpeg4/h264 use same limited (mpeg) color range, so nothing to loose from default already compressed in h264 input...
I searched a bit more.. it seems nvenc can accept full range, but in general for this you might want to use yet another format switch (dropdown menu) in encoding param window.. also see nvenc-specific options described here.. https://superuser.com/questions/1296374/best-settings-for-ffmpeg-with-nvenc https://forums.developer.nvidia.com/t/nvenc-hevc-with-full-range-colors/4445... current nvenc part of ffmpeg uses vui->videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ420P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ422P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ444P); https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c so try to play with those parameters too..?
However, the speed only holds if I use 60fps video or less. Making color changes, brightness, zoom all seem to be reasonable and on par to what I'm used to seeing in shotcut.
However, if my source material is over 60 FPS , the speed of encoding significantly drops off for something as simple as "trim".
does plain ffmpeg/shotcut encode such files better (faster) with same nvenc?
Going forward, I can convert my sources in ffmpeg, no biggie. I'll have to keep my sources tho for future 'just in case'.
Attached is a photo of my settings that I'm using for OBS and cin with nvenc for going forward.
thanks, it seems current nvenc might have some not-so-obvious limitations, might be worth mentioning in manual (with hw description and driver version)
[image: my-cin-setup-for-obs-videos.png]
On Sat, Jul 17, 2021 at 12:22 AM Phyllis Smith via Cin < [email protected]> wrote:
There are no errors at all printed to the console if I launch cin from
the terminal.
Just FYI, on a non-Nvidia laptop, you will get the following errors on the terminal where there is no Nvidia graphics card:
[h264_nvenc @ 0x7f0780085a40] Cannot load libcuda.so.1 FFMPEG::open_encoder err: Operation not permitted int FFMPEG::open_encoder(const char*, const char*): open failed h264_nvenc:/tmp/testnvenc.mp4
So, it sure looks like "nvenc" is working in Gorge's case.
Also in the nvidia control panel, and I can see this:
But the percentage will hit up to 30-50% many times.
--
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
gorge rankin -
Phyllis Smith