- Cin - Cinelerra-GG Mailing Lists

New Cinelerra-GG builds are ready for May / change notes listed at bottom
by Phyllis Smith 01 Jun '19

01 Jun '19

The tars and packages for the end of the month builds are now at: https://www.cinelerra-gg.org/download/pkgs/ https://www.cinelerra-gg.org/download/tars/ The full release notes are at: https://www.cinelerra-gg.org/download/releasenotes.pdf Updated GPU hardware acceleration document because minor changes were made on usage (temporarily at): https://www.cinelerra-gg.org/download/GPU_potential_speedup.pdf CREDIT goes to a bunch of people (you know who you are!) for contributions for themes & png-s, testing, control, setup, feedback, dumps and suggestions of more good ideas. ------------------------------------------------------------------------------------------------------------------------------------------------------ Cinelerra-GG (Version Infinity) Release Notes for 05/01/2019-05/31/2019 for builds 1. *Leap 15.1* (Sam notification) and *Debian 10.0 Buster/Testing *(AJ notification) builds now available. 2. The *Canvas lock/refresh* was completely reworked with many Mutex-s being corrected to Conditions. Although much testing was completed, there is still a possibility that a deadlock could occur under some missed situation. These could occur in the Compositor or Viewer and if using either X11 or X11-OpenGL video driver. Please report problems for analysis and possible fixes. 3. The* Masks* have had several changes implemented plus additional features to include: - *OpenGL upgraded from 1.x to 4.3 *for masking only. This will affect any operating system that has not upgraded to at least 4.3 and does not have graphics driver upgrades when using Feather. Since 4.3 was released in 2012 this was kind of a surprise until GG started updating for Cinelerra masking and found out how difficult it was to do this. The user workaround is to check the box “Disable OpenGL masking” in the Mask menu if using Feather for those computers at 1.x. - added *rotate and scale* around a pivot point to include a Focus X/Y setting - now have *names for masks* instead of just the numbers 0 through 7 and they show on compositor - the function *feather *is a logical function instead of a mathematical function so should be faster and now works correctly in OpenGL without the stairstep effect and spurious blobs appearing - rework of the mask engine and lots of cleanup done to include correcting keyframe spanning for mask auto update_params; fix for mask problem of Mask Clear generating a keyframe at position 0, and other minor bug fixes - the Mode button for *multiply and subtract alpha has been replaced with Fade slider* bar with positive and negative values - a Clear button has been added to delete All Masks for convenience - Fade and Feather sliders have a sticky at 0 making it easy to get to 0 and stay there momentarily - *Gang for fade and feather *has been added. This is a symbol to the right of those slider bars and looks like 2 links in a chain entwined. As you fade/feather one of the masks, the others will fade/feather in relation up to a point - Markers checkbox added to turn on/off the points for easier viewing - Boundary checkbox added to turn on/off the boundary so as to not interfere with your view - *radio buttons added, one for each mask*, to make it easy to quickly change from one to another and in addition the ones in use are in a different color; also a tumbler so you can use the middle mouse wheel to go from one to the other 4. *Potential bit hint for Nvidia graphics* boards computer users - try to enable/disable Vsync in ... driver's control application if you use proprietary drivers. Disable "Sync to VBlank" (option for OpenGL) in NVIDIA X Server Settings... has solved the problem! Thanks to Andrew. This might help anyone with an Nvidia card using Cinelerra and having low frames/sec. 5. *Usability Improvements* A flag in Settings→Preferences, Performance, “Use HW” device with 3 choices of none, vaapi, or vdpau has been added for using GPU instead of CPU for graphics devices that are capable of doing hardware acceleration. You may have to restart Cinelerra when you set or change this initially. When decoding during a load operation, you can make use of an .opts file to allow for specifically using hardware decode or not for a specific video file. For usage of these last 2 items, temporarily refer to https://www.cinelerra-gg.org/download/GPU_potential_speedup.pdf *Encode hardware acceleration for vaapi *(Intel graphics board) + 4 opts file (h264, hevc, mjpeg, mjpeg2) has been added. Color 3 Way plugin has had “clear” buttons added by an anonymous user/programmer. Convenient! The 16 plugins which recently had the Clear feature added, have had a *modified Clear icon* added for all the themes. This was tedious work credited to another contributor and included all variations. Olaf’s *Neophyte theme has been updated.* Especially “beautiful” is the About tab in Preferences. A *new “2019 modern” theme, Cakewalk*, has been added and is now the default for users who do not have an existing $HOME/.bcast5 file or you can switch to it. Olaf credit for both themes. *German translations* in de.po have been upgraded to fix some and include a lot more – by Olaf. Language translations in f*r.po for French* have been much improved by contributions from Olivier. The Shell Cmds feature has an additional option when doing an Add “run /path/script.sh + argvs” which allows for using $1, $2, … args by replacing them with highlighted assets in the Resource window. 6. *Bugs/Issues fixed* Build tweaks for the newest Fedora version 30 and Tags tweaks were added for debugging purposes. Fix for OpenGL Finish – OpenGL was crashing and last month’s temporary workaround is now this permanent fix. Thanks to Pierre using Mint 18.3 which illustrated the bug. CIN_FINISH has been removed because it was a workaround in effect when no other resolution was available. Title plugin fixes - missing alpha slider and color change on characters now working correctly. An error message will popup when the GPU cannot process video to pass back to the CPU. A booby trap has been fixed that occurred when you did a cancel on the outline color button in Titler. In the Titler, the Stamp timecode box was taking up too much space so had to be moved. There was a SEGV observed in vgui / cgui if closed while playing that has now been fixed. Updated ffmpeg git option in the build scripts. The line numbers always change and ordinarily it is only updated when a stable and worthy release for ffmpeg is available. Added register dumps for the system of user generated dumps to help in analysis. A SEGV was occurring because for some unknown reason there was a divide by 0 for width/height on a draw refresh. If the zero divisor condition exists, it will now change it to the number 1. OpenCV has been changed to no longer provide the SIFT/SURF algorithms due to murky patents. Make_shader routine has been reworked. A SEGV destructor error for AC3 has been fixed. There was a spurious mask drag tooltip that is now gone. Several more contributions by Olivier to repair minor problems include: - corrections to the Debian control file - the language translation xlat.sh script has been fixed - lv2_blacklist.txt additions to avoid incompatible lv2 plugins that prevent Cinelerra from starting Five more ffmpeg plugins specific to vaapi usage were commented out as contributed by John/Jacek from the Solus team. It is possible, though not probable, that they would work on some hardware. Reworked Shells Cmds to refer to the CinelerraGG_manual.pdf file and no outdated references. However these will not be in effect until your $HOME/.bcast5/Cinelerra_rc is re-created or edited. Fixed OpenGL’s transform translate (again!). Slight modification to the shell command, RenderMux.sh, in order to create a logfile when used.

2 1

Cakewalk theme
by Andrea paz 01 Jun '19

01 Jun '19

I want to be the first to congratulate for the new Cakewalk theme. At first glance it looks beautiful and fancy; you can read very well and with precision; the colors are beautiful and restful for the view; the icons are clear and beautiful. What more can I say: thank you very much.

4 5

HEVC hw encoding on AMD Polaris cards
by Andrew Randrianasulu 31 May '19

31 May '19

Not sure if I send this bunch of links to list or only to my friend... Few days ago I compiled Cin-GG snapshot from git for my friend with AMD machine (AMD phenom x4 as cpu, and RX470 as GPU). Initially hw decoding/encoding was not working for him, but after some tries he was able to set Cin-GG to 'vdpau decode, vaapi h264 encode" and this mdoe worked, while not ultrafast. Still, I was puzzled at his vainfo: vainfo: VA-API version: 1.4 (libva 2.4.0) vainfo: Driver version: Mesa Gallium driver 18.3.6 for AMD Radeon (TM) RX 470 Graphics (POLARIS10, DRM 3.8.0, 4.9.155-nrj-desktop-1rosa-x86_64, LLVM 7.0.1) vainfo: Supported profile and entrypoints EE ../src/gallium/drivers/radeonsi/si_get.c:642 si_get_video_param UVD - No MJPEG support for the kernel version VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc No HEVC encoding, as you can see! After some digging I found possible reason - too old kernel! https://www.phoronix.com/scan.php?page=news_item&px=UVD-H265-HEVC-Encode-In… ---------------- Written by Michael Larabel in Radeon on 24 February 2018 at 03:09 PM EST. 14 Comments RADEON Earlier this month AMD developers landed VCN-powered video encode support for the HEVC main format while now this has come to the UVD engine so it will work with pre-Raven GPUs. VCN "Video Core Next" is the new unified video encode/decode block found so far just on Raven Ridge APUs. That VCN support has been getting into Mesa while AMD's James Zhu this week enabled UVD-based encode for the HEVC main profile. The patches had been floating around on the Mesa mailing list for a few weeks but have now been merged and flipped on for those interested in GPU-based HEVC/H.265 main profile encoding using the UVD block. Hardware-wise, it appears this implementation should work with Carrizo APUs. Fiji GPUs and newer. If you try it out, make sure you are also using the latest firmware files for your GPU. These Mesa changes will be present for next quarter's Mesa 18.1 release along with a whole lot more for advancing the open-source Radeon Linux graphics driver stack. ---------------- https://lists.freedesktop.org/archives/amd-gfx/2017-October/013939.html https://cgit.freedesktop.org/mesa/mesa/log/?qt=grep&q=uvd+hevc https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v… -------------- 2017-10-09 Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux int... Dave Airlie 88 -22439/+6754 2017-10-06 drm/amdgpu: add uvd enc irq James Zhu 1 -2/+38 2017-10-06 drm/amdgpu: add uvd enc ib test James Zhu 1 -0/+172 2017-10-06 drm/amdgpu: add uvd enc ring test James Zhu 1 -1/+54 2017-10-06 drm/amdgpu: add uvd enc vm functions (v2) James Zhu 1 -2/+44 2017-10-06 drm/amdgpu: add uvd enc into run queue James Zhu 1 -0/+14 2017-10-06 drm/amdgpu: add uvd enc rings James Zhu 1 -2/+52 2017-10-06 drm/amdgpu: add new uvd enc ring methods James Zhu 1 -0/+117 2017-10-06 drm/amdgpu: add uvd enc command in header James Zhu 1 -0/+10 2017-10-06 drm/amdgpu: add uvd enc registers in header ------------------- so, it seems you need kernel 4.15 + mesa 18.1+ and also probably new enough firmware.... https://www.x.org/wiki/RadeonFeature/#index8h2 ============ + some windows tests from 2016: https://forum.videohelp.com/threads/380081-AMD-Polaris-(Radeon-RX-4xx)-H265… + some ffmpeg-users correspondence from 2018: https://ffmpeg.org/pipermail/ffmpeg-user/2018-July/040681.html [FFmpeg-user] Using a AMD Radeon RX5xx with ffmpeg In theory, hevc encoder on Polaris should be faster than h264, but not very good at high bit rates (from forum link at videohelp). Some speed figures for VCE 3.4: https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-Support#video-c… https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-VCE3.4 Hardware VCE3.4 Jump to bottom Michael Fabian Dirks edited this page May 6, 2017 · 21 revisions Version 3.4 added support for H265/HEVC encoding at the cost of reduced throughput in H264/AVC and H264/SVC encoding and also losing the ability to encode B-Frames. Capabilities Acceleration: Hardware Profiles: High, Main, Baseline Maximum Level: 5.2 B-Pictures Supported: No Maximum Simultaneous Streams: 16 Input Resolution: 64x64 - 4096x2160 Formats: NV12, YUV420P, YV12, BGRA, RGBA, ARGB Memory Types: DX11, OpenCL, OpenGL, Host Interlaced Supported: No Output Resolution: 64x64 - 4096x2160 Formats: NV12 Memory Types: DX11, OpenCL, OpenGL, Host Interlaced Supported: No Limits All FPS values are to be read as "up to <x> FPS". There are no guarantees that you will achieve this value. RX 460 RX 470 RX 480 RX 460 Resolution Speed Balanced Quality 160x120 2871 FPS 2723 FPS 2356 FPS 240x160 2457 FPS 2237 FPS 1762 FPS 256x160 2431 FPS 2186 FPS 1705 FPS 320x240 1864 FPS 1605 FPS 1134 FPS 480x320 1269 FPS 1037 FPS 651 FPS 640x460 790 FPS 613 FPS 361 FPS 640x480 767 FPS 595 FPS 349 FPS 800x600 519 FPS 400 FPS 229 FPS 854x480 525 FPS 454 FPS 272 FPS 960x540 490 FPS 376 FPS 215 FPS 1024x768 342 FPS 259 FPS 146 FPS 1152x864 276 FPS 209 FPS 116 FPS 1280x720 297 FPS 224 FPS 125 FPS 1280x800 269 FPS 203 FPS 113 FPS 1280x1024 217 FPS 162 FPS 89 FPS 1366x768 261 FPS 199 FPS 111 FPS 1440x900 216 FPS 162 FPS 89 FPS 1600x1200 152 FPS 113 FPS 61 FPS 1920x1080 140 FPS 104 FPS 56 FPS 1920x1200 128 FPS 95 FPS 51 FPS 1920x1440 107 FPS 79 FPS 43 FPS 1920x1920 81 FPS 60 FPS 32 FPS 2048x1080 132 FPS 98 FPS 53 FPS 2560x1440 81 FPS 60 FPS 32 FPS 3440x1440 61 FPS 45 FPS 24 FPS 3840x2160 36 FPS 27 FPS 18 FPS 4096x2160 34 FPS 25 FPS 17 FPS and two more tables below this one

4 18

Re: [Cin] Unreproductable crash dump
by Phyllis Smith 31 May '19

31 May '19

Andrew, I was able to prove to GG that the below is indeed odd, so now he can either fix it (or convince me that it does not need fixing!). gg/Phyllis > > Still I found some oddity. > If I just open Cin-GG, I can switch on/off itles for tracks (default 1 > video + 2 ch audio) and their content by using > first two checkboxes in window "View" . > > But if I load video file (1 video track, 2 audio channel) > AND add effect to video track - I only can effectively switch on/off > content/titltlebars for audio tracks! > Video track remain always with its content and titlebars. They sort of > 'blocked' by effect track from > this change, even if I remove effect itself! > >

1 0

Re: [Cin] Unreproductable crash dump
by Phyllis Smith 30 May '19

30 May '19

GG has looked at the dump but was unable to determine the exact problem and could not reproduce it either. >From the dump it looks like the program was "updating the Mask gui at the same time the playback engine rendering is finishing". I will save the dump in case a similar case arises -- bugs never go away until they are fixed so this one will most likely be back. > > Still I found some oddity. > If I just open Cin-GG, I can switch on/off itles for tracks (default 1 > video + 2 ch audio) and their content by using > first two checkboxes in window "View" . > > But if I load video file (1 video track, 2 audio channel) > AND add effect to video track - I only can effectively switch on/off > content/titltlebars for audio tracks! > Video track remain always with its content and titlebars. They sort of > 'blocked' by effect track from > this change, even if I remove effect itself! > > I have to reproduce this oddity for him and see what he has to say about that yet. gg/phyllis

1 0

CinGG manual to Latex
by Andrea paz 30 May '19

30 May '19

Hi, einhander I installed TexStudio to test it and see if I can learn anything. For the CinGG manual, I'll follow your instructions: should I use Overleaf or do it locally? In any case I would like to ask you for the file with your settings, so you have the same structure on which to work and do the tests. I saw that in Texstudio, in the menu "idefix", there is the entry "convert to Latex"; does it serve to convert a document (of libreoffice for example) in latex? Or is it better to rewrite everything from scratch? Can I make a copy paste of the sentences from Libreoffice into TexStudio or Overleaf, or do I have to use a plain text? I apologize for all these annoying beginner questions. @Phyllis I'd need the last revision of chapter 4 to try and create it in Latex. The .odt file, I mean. Is that possible?

4 37

LV2_blacklist.txt & Debian packaging improvements contributions
by Olivier Humbert 29 May '19

29 May '19

Hi GG, Phylis, Sam and all Now that things as settled around, and now that I'm good with the website French translation, I'm taking back the packaging of Cin-GG for my audio-linux debian-based distribution (and maybe later, a potential inclusion into Debian mainstream, but... one step after another). I've been doing a build with the last cin_5.1.20190430 and it seems to be successful so far. Doing that, I found a bunch of LV2 plugins which are avoided Cin to be launched and then, which needs to be added to the LV2_blacklist.txt file (after I did that locally, Cin is launching fine). Those following lines are the culprits: file:///usr/lib/lv2/MonoEffect.ingen/MonoEffect.ttl file:///usr/lib/lv2/MonoInstrument.ingen/MonoInstrument.ttl file:///usr/lib/lv2/StereoEffect.ingen/StereoEffect.ttl file:///usr/lib/lv2/StereoInstrument.ingen/StereoInstrument.ttl http://example.org/raffo http://www.wodgod.com/newtonator/1.0 https://sami.boukortt.com/plugins/intersect#Intersect https://sami.boukortt.com/plugins/intersect#SymmetricDifference https://sami.boukortt.com/plugins/intersect#Upmix Also, please, find attached an improved version for the ./blds/debian/control file which contains those improvements/changes: - I added a bit of description (then it looks better with the packages managers) - I improved the Maintainer field (changed the name from "mailing list" to "Cinelerra-GG devs") - I moved the Standard-version and the Homepage fields downer (standard good practice for Debian packaging) - Build-depends : -- 1 item per line (standard good practice for Debian packaging even if it doesn't change anything computer-side, it is easier to human-read) -- alphabetically ordered (standard good practice for Debian packaging too, easier for human-reading) -- removing of duplicates : libxft-dev, libxinerama-dev, and libxv-dev -- adding libusb-1.0-0-dev (the compilation failed here without it) I've got a few questions about the debian/control file which I'd like to have your dev's point of view here (I left those as-is for now waiting for your answers in case I'm missing something): - Build-depends field: -- why is inkscape needed for building ? It sounds like a mistake at a first glance. -- why is e2fsprogs needed ? For information, it contains those binaries : https://packages.debian.org/stretch-backports/amd64/e2fsprogs/filelist -- same for linux-firmware, why is that needed for building ? It doesn't even look to be in the Debian repository anymore - The "Standards-Version" number is currently defined to "5.1.20190430". It is not supposed to be the program version number (which is defined in the debian/changelog file), but a number matching a Debian standard. If you're OK with that, I would set it up to 3.9.8 which is the standard for Debian Stretch (current stable - Debian 9) and which will work as well for the next stable (Buster - Debian 10). I hope that helps. Thanks for your continuous work on cin-gg ! Cheers, Olivier PS: last but not least, I've send it to the mailing list as I did a few months ago back in the cin-cv times, but feel free to let me know if you would better like me to use the Mantis bug-tracker or any other way to contribute. I'm planning to send you other improvements/contributions on a next step. -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK

2 5

When changing colors, the titles disappear
by preobraz＠gmail.com 29 May '19

29 May '19

Hi! When changing colors, the captions of Cinelerra version of April 30 disappear. Please see screencast: https://www.datafilehost.com/d/c5ab7baa -- Ugin.

3 2

French translation update
by Olivier Humbert 29 May '19

29 May '19

Hi people and everyone. Please, find attached an update for the French translation of Cin. It is based on the cin_5.1.20190430-src.tgz version. This updates contains : - translates most of the new translations - fixes most of the "fuzzy" translations - a few improvements/fixes/corrections I would be glad if this update could get in for the next monthly release (to happen in few following days I guess), and then after that, I could start to do a whole review of the French translation (which is in need of that). ------ Note that to do this (attached) translation, I did those steps: 1. extracted the tarball 2. edited po/xlat.sh and added "--from-code utf-8" to the xgettext line (see [1] below) 3. ran: po/xlat.sh > po/cin.po (my understanding is that this command updated the general "cin.po" catalog) 4. ran: msgmerge -U po/fr.po po/cin.po (my understanding is that this command updated the French "fr.po" translation file from the general "cin.po" catalog) 5. translates the po/fr.po It would be great if the knowledgeable people (ping the usual suspects here: Phyllis & GG!) could tell me if this workflow is fine. I hope that helps. Cheers, Olivier [1] without this edit, the step n°3 was throwing an error at me. It might be useful to add this change in the source I guess. -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK

2 6

Solus is working on adding Cinelerra -- email being resent
by Phyllis Smith 29 May '19

29 May '19

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.

1 1