вт, 8 нояб. 2022 г., 17:32 Phyllis Smith <[email protected]>:

This patch adds X11 Libs when not using 3rd party? I do not understand why this is necessary and am concerned it will affect some builds unexpectedly. What do I not know?

guess this is side effect of system ffmpeg pulling x11 libs for vdpau/vaapi. It was working for me without this line on termux, where I have no vaapi/vdpau. this is probably not necessary if you have X in /usr, I some long time ago compiled whole X tree into /usr/X11R7 this surprizes some soft to this day!

On Mon, Nov 7, 2022 at 7:10 PM Andrew Randrianasulu via Cin < [email protected]> wrote:

...

..where X11 actually located in /usr/X11R7

so this configure works

LDFLAGS=-L/usr/X11R7/lib setarch i686 ./configure --with-single-user --without-thirdparty --disable-libdpx --without-libdpx --without-lv2 --disable-static-build -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin

вт, 8 нояб. 2022 г., 19:59 Phyllis Smith <[email protected]>:

OK, so since I do not have enough of the 3rd party libraries on the system (instead of with CinGG) and can not test/verify that there is no impact, is it safe to put this line in?

well, you can observe current cin binary links to them anyway ldd bin/cin will tell you. For bdwrite this probably overkill, but bdwrite want to link to libav*, and those in turn demand some X libs in some configurations .... I do not think linking twice to same libs will cause problems (well, there are problems with link order, but they usually mainfest in missing symbols, in other words linking failure), and there usually only one set of X libs on system ....

It would be nice to have for Slackware, but just want to make sure it does not cause problems for other builds. What do you think?

May be wait for Andrea, so he will test it? )

On Tue, Nov 8, 2022 at 9:01 AM Andrew Randrianasulu < [email protected]> wrote:

...

вт, 8 нояб. 2022 г., 17:32 Phyllis Smith <[email protected]>:

...

This patch adds X11 Libs when not using 3rd party? I do not understand why this is necessary and am concerned it will affect some builds unexpectedly. What do I not know?

guess this is side effect of system ffmpeg pulling x11 libs for vdpau/vaapi. It was working for me without this line on termux, where I have no vaapi/vdpau.

this is probably not necessary if you have X in /usr, I some long time ago compiled whole X tree into /usr/X11R7 this surprizes some soft to this day!

...

On Mon, Nov 7, 2022 at 7:10 PM Andrew Randrianasulu via Cin < [email protected]> wrote:

...

..where X11 actually located in /usr/X11R7

so this configure works

LDFLAGS=-L/usr/X11R7/lib setarch i686 ./configure --with-single-user --without-thirdparty --disable-libdpx --without-libdpx --without-lv2 --disable-static-build -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin

ср, 9 нояб. 2022 г., 10:39 Andrea paz <[email protected]>:

...

May be wait for Andrea, so he will test it? ) I tried a build with the Slackware patch and found no errors. No X11R7 folder appeared and there is no trace of it within Cin5.log

yeah, because instead of earlier hacks I used pkg-config :-) Can you confirm --without-thirdparty --disable-libdpx --without-libdpx --without-lv2 --disable-static-build also still works?

ср, 9 нояб. 2022 г., 21:39 Andrea paz <[email protected]>:

...

Can you confirm --without-thirdparty --disable-libdpx --without-libdpx --without-lv2 --disable-static-build also still works?

I don't know if my test has any value, since I did it on 64-bit Arch.

this is exactly why I asked for your help - my single system may work ok, but what about unintended sideeffects? Thankfully, you found none, so may be Phyllis will give this patch another spin with few more old and new distros, and may be add to git if no issues surface. However the build with patching and disabling thirdparty, etc gave no

errors and some simple editing test showed no problems. The only errors involved loading OpenCL plugins:

I thought about this, some plugins probably need two sources for operation (as overlay), but may be simpler ones can be forced to work by setting filtering_device to opencl somehow? Ffmpeg itself provides option for setting filtering device independent from decode/encoding device: filter_hw_device option. from https://ffmpeg.org/ffmpeg.html " filter_hw_device name Pass the hardware device called name to all filters in any filter graph. This can be used to set the device to upload to with the hwupload filter, or the device to map to with the hwmap filter. Other filters may also make use of this parameter when they require a hardware device. Note that this is typically only required when the input is not already in hardware frames - when it is, filters will derive the device they require from the context of the frames they receive as input. This is a global setting, so all filters will receive the same device." ---- but this is idea for another day

build plugin index for: /home/paz/cinelerra5/cinelerra-5.1/bin/plugins PluginFFilter::new_ffilter(overlay_opencl) err: Input/output error PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(program_opencl) err: Operation not permitted PluginFFilter::new_ffilter(remap_opencl) err: Input/output error PluginFFilter::new_ffilter(xfade_opencl) err: Input/output error [openclsrc_883 @ 0x55c0871a9940] OpenCL source requires output dimensions to be specified. PluginFFilter::new_ffilter(openclsrc) err: Invalid argument build ladspa plugin index for: /home/paz/cinelerra5/cinelerra-5.1/bin/ladspa

But they do not affect the operation of CinGG. I attach the logs if they are of interest.