[Cin] Solus is working on adding Cinelerra -- email being resent
Phyllis Smith
phylsmith2017 at gmail.com
Mon May 27 19:21:19 CEST 2019
This is important email that did not get into the mailing list -- I got
carried away and was not paying full attention as usual. The summary.
"John" (Jacek Jagosz) has been diligently working on included Cinelerra-GG
with Solus.
------------------------------------------------------------------------
Hi,
My Cinelerra-GG Solus package is almost ready, but there is a blocker.
Video effects that use vaapi don't work and in terminal I get:
PluginFVClient::process_buffer() F_denoise_vaapi
err: Operacja niedozwolona (that means "operation not allowed" in
english).
And no matter how long I tried I can't find the root cause. I included
FFmpeg, vdpau, libva, libdrm, libva-vdpau-driver and libva-intel-driver. I
looked through builds for other systems like from AUR, Fedora or Debian and
I don't miss a single dependency. Any help would be appreciated.
Second is just a suggestion. If you do make install -j# (# means number of
cores) build will fail. Which is a problem, as macro %make_install used in
Solus packaging does make install -j#. It'd be nice if Cinelerra used a
more standart syntax or at least ignored that argumant instead of failing.
And on a last note I still can't join Cinelerra's mailing list. I want to
follow the development and know if there is any major bug before I update
Cin in Solus' repos. Maybe my mail (@outlook.com) is a problem.
I'd be extremely grateful for any help.
Jacek Jagosz
------------------------------------------------------------------------
Several Responses from Phyllis:
"My Cinelerra-GG Solus package is almost ready, but there is a blocker.
Video effects that use vaapi don't work and in terminal I get:
PluginFVClient::process_buffer() F_denoise_vaapi
err: Operacja niedozwolona (that means "operation not allowed" in
english)."
I will test this on Intel/Broadwell graphics to make sure I can duplicate
the problem and if I can, then gg can diagnose it. This being a blocker
with no workaround WILL GET PRIORITY -- the other 2 problems below can be
temporarily worked around.
"Second is just a suggestion. If you do make install -j# (# means
number of cores) build will fail. Which is a problem, as macro
%make_install used in Solus packaging does make install -j#. It'd be nice
if Cinelerra used a more standart syntax or at least ignored that argumant
instead of failing."
Will have to also get GG to look at this (unfortunately he is "snowed
under" right now and I do not mean the white stuff! I always use the
following after doing a build and have no problems with -j# on a Fedora
system:
CFLAGS=-ggdb make -j28 rebuild_all
"And on a last note I still can't join Cinelerra's mailing list. I want to
follow the development and know if there is any major bug before I update
Cin in Solus' repos. Maybe my mail (@outlook.com) is a problem."
I did look at the problem with email joining but only came to the
conclusion that it must be Outlook. I know that the mailing list for CV
had problems with Yahoo or Hotmail due to restrictive policies causing
messages to not arrive, but I do not think that that is the case here.
-------------------------------------------------------
WOW, you found something we never would have caught! But there is an easy
fix for the blocker that is consistent. A file in {your
cinelerra_path}/ffmpeg/plugins.opts contains the currently being used in
Cinelerra FFmpeg 371 filters/effects. You will notice that 158 of them are
commented out because they do not work with Cin for multiple reasons -- one
of which is "Operation not permitted". I will have gg checkin a revised
plugin.opts with F_denoise_vaapi commented out so the blocker is gone.
Obviously you can test this yourself BUT be sure to delete
$HOME/.bcast5/Cinelerra_plugins first so that when you next startup
Cinelerra, it will reload the plugins (else it uses the old set).
I will still have to test the other 4 to see if they will work
F_sharpness_vaapi, F_scale_vaapi, and so on. Also, my big concern is that
what happens if you enable vaapi, load these 4 plugins so they stay, and
then turn off vaapi for the next run but your session still uses this set
of plugins. Should be interesting! BTW - we mostly use Nvidia boards so
never would have found this without your help -- thanks. Phyllis/gg
--------------------------------------------------------------------------------------------------------------------------
I forgot to technically explain as best as I can convey from GG. FFmpeg
uses "filter graphs" but Cinelerra uses a "plugin stack" instead. That is
why about 178 of the FFmpeg plugins will not work in Cinelerra. We are
sorry that you had to spend so much time trying to determine the problem
with F_denoise_vaapi, but in the end you saved other people a lot of time
and this was initially very time-consuming/difficult for gg to figure out
and workaround in the first place. Phyllis/GG
-------------------------------------------------------------------------------------------------------------------------
Unfortunately none of the 5 vaapi ffmpeg plugins will work when you
actually try to load them on the timeline so I will be commenting all 5
out. If I counted right, there are still 200 that do work -- that should
be enough. At one time GG emailed the ffmpeg group to ask for assistance
with these as more could work if they were just set up by ffmpeg with
initial values but they are so busy and Cinelerra is just another program.
(Additional comment added later):
However, the laptop I used is several years old and just because these 5
did not work for me, does not necessarily mean they do not work for other
computer hardware setup.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20190527/2ce38d60/attachment.html>
More information about the Cin
mailing list