Checked into GIT some of Andrew's latest changes
Minor changes to the following files was checked into GIT (these were the accumulated patches BEFORE Andrew re-sent them all to make it easier for us/Andrea to test, so the numbers may vary). ffmpeg.C - for mediacodec / Termux 0002-Mediacidec-decode-to-use-with-remap_video_codec.patch window.C - for yuav16 formats with env. variable 0002-Allow-16bpc-only-with-ALLOW_OLD_16BPC-env.-var.patch Makefile.am - for potential speed up "make install" 0002-Make-parallel-make-install-work.patch 0001-Do-not-use-smart-filename-expansion-in-Makefile.am.patch ffv2_vulcan.mov - came from email message so users have at least one render format if vulkan works msg/txt - just consolidated more important changes done in 2025 I did NOT add in 0001-Experimental-vulkan-encode.patch because I have questions about the use of "type", although it did compile ffmpeg.C without errors. Also, did not have time to look at Ladspa change.
вт, 10 февр. 2026 г., 03:27 Phyllis Smith via Cin < [email protected]>:
Minor changes to the following files was checked into GIT (these were the accumulated patches BEFORE Andrew re-sent them all to make it easier for us/Andrea to test, so the numbers may vary). ffmpeg.C - for mediacodec / Termux 0002-Mediacidec-decode-to-use-with-remap_video_codec.patch window.C - for yuav16 formats with env. variable 0002-Allow-16bpc-only-with-ALLOW_OLD_16BPC-env.-var.patch Makefile.am - for potential speed up "make install" 0002-Make-parallel-make-install-work.patch 0001-Do-not-use-smart-filename-expansion-in-Makefile.am.patch ffv2_vulcan.mov - came from email message so users have at least one render format if vulkan works msg/txt - just consolidated more important changes done in 2025
I did NOT add in 0001-Experimental-vulkan-encode.patch because I have questions about the use of "type", although it did compile ffmpeg.C without errors.
I changed initialization of hw encoder type only for case without (previously added by me) envr. variable to select /dev/dri device to use - because I am still not sure how to pass device selection to other types. Strangely, vaapi type worked for mediacodec, nvenc, qsv - but not Vulkan, notably. We use it slightly different comparing to official way ffmpeg does - but so far my attempts at bridging hw codec and hw filter on ingest were not successful, so I stick to working path where possible. Also, did not have time to look at Ladspa change.
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
Now applying the patches has worked. I simply had a double patch with two different numbers in the title. Once I removed one of them, it worked without any problems. Now, however, I'm having problems with ./configure; I get this result: ./configure --prefix=/usr --with-single-user --with-config-dir=/home/paz/.bcast6 --enable-libsvtav1 --with-vulkan [...] configure: error: Please install autoconf-archive package and re-run autoreconf After installing autoconf-archive, ./configure worked normally. What is autoconf-archive used for? The “YUVA-16 Bit” color model applies without errors and playback works, but none of the native filters in the “Color Correction” section work. The error message is: VFrame::to_texture: unsupported color model 16. (Note: Using the compositor's videoscope works fine; using the videoscope filter on the timeline does not work.) Regarding rendering presets with Vulkan: When I use your preset (ffv1_vulkan.mov, with pix_fmt=nv12), I get this error: cant find codec ffv1_vulkan:/home/paz/test_vulkan.mov Render::render_single: Session finished. If I use one of my presets (e.g., hevc_vulkan.mov). I get: Specified pixel format nv12 is not supported by the hevc_vulkan encoder. Even if I change the value nv12 --> vulkan, rendering fails with the same error I've always had and can't resolve: A hardware frames reference is required to associate the encoding device. I have never been able to understand my problems with Vulkan, which are beyond my capabilities, so there is no point in continuing to try. Sorry.
On Tue, Feb 10, 2026 at 8:56 PM Andrea paz <[email protected]> wrote:
Now applying the patches has worked. I simply had a double patch with two different numbers in the title. Once I removed one of them, it worked without any problems. Now, however, I'm having problems with ./configure; I get this result:
./configure --prefix=/usr --with-single-user --with-config-dir=/home/paz/.bcast6 --enable-libsvtav1 --with-vulkan [...] configure: error: Please install autoconf-archive package and re-run autoreconf
After installing autoconf-archive, ./configure worked normally. What is autoconf-archive used for?
For fancy macro to check if compiler can shut up -Woverloaded-virtual (some compilers just stop if you give them wrong disable switch) Local thing on my Termux due to clang there and fact it was NOT working right last time Phyllis tried it on her machine with Fedora ...
The “YUVA-16 Bit” color model applies without errors and playback works, but none of the native filters in the “Color Correction” section work. The error message is:
VFrame::to_texture: unsupported color model 16.
Ah, was it with X11-OpenGL? I only tested lightly on X11 without "Use direct" checked ... Thanks anyway, more pieces to enable even for testing ...
(Note: Using the compositor's videoscope works fine; using the videoscope filter on the timeline does not work.)
Regarding rendering presets with Vulkan:
When I use your preset (ffv1_vulkan.mov, with pix_fmt=nv12), I get this error:
cant find codec ffv1_vulkan:/home/paz/test_vulkan.mov Render::render_single: Session finished.
You probably should compile with enabled libplacebo, too? It will drag in shaderc compiler, used for ffv1 encoder.
If I use one of my presets (e.g., hevc_vulkan.mov). I get:
Specified pixel format nv12 is not supported by the hevc_vulkan encoder.
Even if I change the value nv12 --> vulkan, rendering fails with the same error I've always had and can't resolve:
A hardware frames reference is required to associate the encoding device.
I think you still can try just set cin_pix_fmt to nv12, form preset and not from GUI (there is some problem with Vulkan specificailly so encoder must be opened early, earlier than all other hw encoders so far)
I have never been able to understand my problems with Vulkan, which are beyond my capabilities, so there is no point in continuing to try. Sorry.
Well, this is still new, cutting edge technology.Do not feel completely discouraged. But do not push yourself too hard in testing that ...
On Tue, Feb 10, 2026 at 10:21 PM Andrea paz <[email protected]> wrote:
Ah, was it with X11-OpenGL? I only tested lightly on X11 without "Use direct" checked ...
When activing the X11 drivers (and yuva-16 bit), every time I try to add an effect (i.e. Color 3 Way), I get a crash. I append the dump.
BC_Signals::dump_stack /home/paz/cinelerra/cinelerra-5.1/bin/cin(_ZN10BC_Signals10dump_stackEP8_IO_FILE+0x31) [0x5569d30dcd21] /home/paz/cinelerra/cinelerra-5.1/bin/cin(+0x136961f) [0x5569d30dd61f] /usr/lib/libc.so.6(+0x3e4d0) [0x7fdad84564d0] /home/paz/cinelerra/cinelerra-5.1/bin/cin(_ZN10DirectUnit12yuva16161616Ev+0x82f0) [0x5569d25db930] /home/paz/cinelerra/cinelerra-5.1/bin/cin(_ZN10LoadClient3runEv+0xc3) [0x5569d2872213] /home/paz/cinelerra/cinelerra-5.1/bin/cin(_ZN6Thread10entrypointEPv+0x43) [0x5569d310e1b3] /usr/lib/libc.so.6(+0x9698b) [0x7fdad84ae98b] /usr/lib/libc.so.6(+0x11aa0c) [0x7fdad8532a0c] Probably some under- or over-read by those sampling routines .. I'll look into it, but I guess we better to keep it off main repo then, I'll play with it more on desktop, and may be fix crashes.
When activing the X11 drivers (and yuva-16 bit), every time I try to add an effect (i.e. Color 3 Way), I get a crash. I append the dump.
Probably some under- or over-read by those sampling routines ..
I'll look into it, but I guess we better to keep it off main repo then, I'll play with it more on desktop, and may be fix crashes.
Do I understand correctly that I should remove the mwindow.C changes which re-enabled the yuva16 and environment variable?
Or is that just the patch, 0013-Re_add-16-bpc-to-bccolors-scopewindow.patch, which has not been checked in? On Tue, Feb 10, 2026 at 3:44 PM Phyllis Smith <[email protected]> wrote:
When activing the X11 drivers (and yuva-16 bit), every time I try to add an effect (i.e. Color 3 Way), I get a crash. I append the dump.
Probably some under- or over-read by those sampling routines ..
I'll look into it, but I guess we better to keep it off main repo then, I'll play with it more on desktop, and may be fix crashes.
Do I understand correctly that I should remove the mwindow.C changes which re-enabled the yuva16 and environment variable?
On Wed, Feb 11, 2026 at 1:46 AM Phyllis Smith <[email protected]> wrote:
Or is that just the patch, 0013-Re_add-16-bpc-to-bccolors-scopewindow.patch, which has not been checked in?
I think for now it best to re-comment lines in mwindow.C I uncommented. 0013 patch sadly was not as helpful as I hoped it to be, so whole thing need more work from my side.
On Tue, Feb 10, 2026 at 3:44 PM Phyllis Smith <[email protected]> wrote:
When activing the X11 drivers (and yuva-16 bit), every time I try to add an effect (i.e. Color 3 Way), I get a crash. I append the dump.
Probably some under- or over-read by those sampling routines ..
I'll look into it, but I guess we better to keep it off main repo then, I'll play with it more on desktop, and may be fix crashes.
Do I understand correctly that I should remove the mwindow.C changes which re-enabled the yuva16 and environment variable?
On Wed, Feb 11, 2026 at 2:31 AM Andrew Randrianasulu <[email protected]> wrote:
On Wed, Feb 11, 2026 at 1:46 AM Phyllis Smith <[email protected]> wrote:
Or is that just the patch, 0013-Re_add-16-bpc-to-bccolors-scopewindow.patch, which has not been checked in?
I think for now it best to re-comment lines in mwindow.C I uncommented.
0013 patch sadly was not as helpful as I hoped it to be, so whole thing need more work from my side.
Strangely enough, it works on i586 Slackware ? I mean, it does not crash
On Tue, Feb 10, 2026 at 3:44 PM Phyllis Smith <[email protected]> wrote:
When activing the X11 drivers (and yuva-16 bit), every time I try to add an effect (i.e. Color 3 Way), I get a crash. I append the dump.
Probably some under- or over-read by those sampling routines ..
I'll look into it, but I guess we better to keep it off main repo then, I'll play with it more on desktop, and may be fix crashes.
Do I understand correctly that I should remove the mwindow.C changes which re-enabled the yuva16 and environment variable?
On Wed, Feb 11, 2026 at 6:00 AM Andrew Randrianasulu <[email protected]> wrote:
On Wed, Feb 11, 2026 at 2:31 AM Andrew Randrianasulu <[email protected]> wrote:
On Wed, Feb 11, 2026 at 1:46 AM Phyllis Smith <[email protected]> wrote:
Or is that just the patch, 0013-Re_add-16-bpc-to-bccolors-scopewindow.patch, which has not been checked in?
I think for now it best to re-comment lines in mwindow.C I uncommented.
0013 patch sadly was not as helpful as I hoped it to be, so whole thing need more work from my side.
Strangely enough, it works on i586 Slackware ?
I mean, it does not crash
Ah, I think I get crash but only if I use "Use direct" in x11 output! Without it things work, with expected speedup 2x (9 vs 18 fps) in case of 1 track h264 1080P decoded by vulkan and piped to compositor with fader set to some 80% (so we get some heavy pixel processing)
On Tue, Feb 10, 2026 at 3:44 PM Phyllis Smith <[email protected]> wrote:
When activing the X11 drivers (and yuva-16 bit), every time I try to add an effect (i.e. Color 3 Way), I get a crash. I append the dump.
Probably some under- or over-read by those sampling routines ..
I'll look into it, but I guess we better to keep it off main repo then, I'll play with it more on desktop, and may be fix crashes.
Do I understand correctly that I should remove the mwindow.C changes which re-enabled the yuva16 and environment variable?
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith