I tried to build with the 5 patches that Phyllis used. Everything is OK, no errors. Does the “0002-Make-Paralell...” patch perhaps serve to speed up compilation? It seemed faster to me, but I would need to do more testing. In ./configure, I tried adding “--with-vulkan” and, for the first time, it worked, and now CinGG sees my Vulkan decoder (even though it doesn't work with h264). Decoder h264 does not support device type vulkan. HW device init failed, using SW decode. NB: I have to use X11-OpenGL, otherwise Vulkan is not recognized. For the encoder, I have: /home/paz/cinelerra/cinelerra-5.1/thirdparty/ffmpeg-8.0/./ffmpeg -encoders | grep vulkan V....D av1_vulkan AV1 (Vulkan) (codec av1) V....D h264_vulkan H.264/AVC (Vulkan) (codec h264) V....D hevc_vulkan H.265/HEVC (Vulkan) (codec hevc) When I try to render, I don't see any presets with Vulkan. Do I have to create them myself? Finally, what tests should I run for “yuva16”?
пт, 6 февр. 2026 г., 17:42 Andrea paz via Cin <[email protected]>:
I tried to build with the 5 patches that Phyllis used. Everything is OK, no errors. Does the “0002-Make-Paralell...” patch perhaps serve to speed up compilation?
It just fixes case when make -j (something bigger than 1) install was used, by adding "bin" target before other install targets using files from bin directory. So probably no real speedup even at install time It seemed faster to me, but I would need to do more testing. In
./configure, I tried adding “--with-vulkan” and, for the first time, it worked, and now CinGG sees my Vulkan decoder (even though it doesn't work with h264).
Decoder h264 does not support device type vulkan. HW device init failed, using SW decode.
NB: I have to use X11-OpenGL, otherwise Vulkan is not recognized.
For the encoder, I have:
/home/paz/cinelerra/cinelerra-5.1/thirdparty/ffmpeg-8.0/./ffmpeg -encoders | grep vulkan V....D av1_vulkan AV1 (Vulkan) (codec av1) V....D h264_vulkan H.264/AVC (Vulkan) (codec h264) V....D hevc_vulkan H.265/HEVC (Vulkan) (codec hevc)
When I try to render, I don't see any presets with Vulkan. Do I have to create them myself?
Yes, please try. I am struggling with vulkan-based ffv1 encoder profile, it used to work and I not saved it, now all I get is [ffv1_vulkan @ 0xb400007329d7e740] format (null) not supported
Finally, what tests should I run for “yuva16”?
Try to render 10bit test image to various image/ffmpeg formats, see if all bits still there (by subtracting rendered output and original), may be use longer 10bit video to see if yuva16 offer any speed up on your machine compared to rgba-float. Try some plugins. I think unsupported plugin will just give you black frame in compositor, but not sure. _______________________________________________
Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
.
Finally, what tests should I run for “yuva16”?
Try to render 10bit test image to various image/ffmpeg formats, see if all bits still there (by subtracting rendered output and original), may be use longer 10bit video to see if yuva16 offer any speed up on your machine compared to rgba-float.
Try some plugins. I think unsupported plugin will just give you black frame in compositor, but not sure.
Did Andrew or Andrea get any bad results with yuva16? should we add this patch to the source? it is just suspicious because the lines before were commented out for some reason, which I assume is because it behaved badly.
пн, 9 февр. 2026 г., 00:34 Phyllis Smith <[email protected]>:
.
Finally, what tests should I run for “yuva16”?
Try to render 10bit test image to various image/ffmpeg formats, see if all bits still there (by subtracting rendered output and original), may be use longer 10bit video to see if yuva16 offer any speed up on your machine compared to rgba-float.
Try some plugins. I think unsupported plugin will just give you black frame in compositor, but not sure.
Did Andrew or Andrea get any bad results with yuva16? should we add this patch to the source? it is just suspicious because the lines before were commented out for some reason, which I assume is because it behaved badly.
I think they behaved badly in sense only SOME plugins supported them, and 32 bpc floating point was superior in image-processing/compositing. Thing is, most video codes even today are integer-based in their input and output, so while ffmpeg can do 10 bit yuv directly to another encoder input we go via 444 yuv with 16 bpc, THEN via twice wider fp format, then back to 16 bpc 444 yuv, then into that codec (encoder) supports. Quite a lot of conversions! I'm quite happy they were NOT removed, because now we can compare them to other formats.
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith