- Cin - Cinelerra-GG Mailing Lists

Still on hardware acceleration
by Andrea paz 05 Sep '23

05 Sep '23

@Andrew Sorry to bother you again on a subject you have already tried to explain over and over again. Reading this page: https://trac.ffmpeg.org/wiki/HWAccelIntro it is my understanding that when decoding (note: from here on I am only referring to decoding/playback!) you can use the "-hwaccel" option without any other settings. If the media file used supports hardware acceleration, then it will be used automatically without anything else to do. If it is not supported it will automatically switch to software decoding. There is no need to specify the device (because a device is automatically selected, even if it is not the preferred one), so it would be a generic feature that decides for itself when to run. Question, how can I impose "-hwaccel" when compiling CinGG? Another thing concerns decoding with Vulkan. Again, these are generic instructions and I would like to test it, however it requires device initialization, to be declared explicitly (although a generic term is fine: "vulkan=vk:0") and a few other options. See here: https://trac.ffmpeg.org/wiki/HWAccelIntro#Vulkan The question is always the same: How can I compile vulkan in CinGG to do some tests?

2 3

Monthly AppImage updates
by Phyllis Smith 05 Sep '23

05 Sep '23

April 30th AppImages are now available with the binary only updated with X264 r3106 stable mods. But, I have a problem with being able to update the GIT repository on the server due to some error I made which I am now working on. Release Notes Update below: *********************************** GIT for Cinelerra-GG has the following changes from 04/01/2023-04/30/2023 *Server Maintenance work has been done by Sam* on an ongoing basis along with the difficult task of accommodating newer requirements by Google Gmail. Changes to the Mailing List settings for compliance was very time-consuming and much appreciation goes to Sam for continuing to volunteer his time for critical needs. *X264 *has been upgraded to r3106 stable release. There appears to be no X265 stable updates. *Clang-16* related modifications in thirdparty/Makefile, libuuid-1.0.3, and mpeg2enc.c to support new termux distro have been contributed by *Andrew*. *Prores_ks *render format has had the Apple writing library added as the default with ffmpeg since that is who created this specific prores format. This should make the rendered video more compatible with other software products. Mod provided by *Andrea*.

4 9

Cingg bg render crash video scenario
by Andrew Randrianasulu 01 Sep '23

01 Sep '23

https://youtu.be/URnvDY7Zjic at least cin does this on my 32-bit-on-64-bit kernel system ... recorded by another instance of the same cin version. Note, my machine set to full 3.97 Ghz speed. Also, I have 4 frames per bg job setting

3 6

fileexr reading error handling
by Andrew Randrianasulu 01 Sep '23

01 Sep '23

Using https://openexr.com/en/latest/HelloWorld.html as example so for now I have base commit d51dc1ff2dbd920c6488af4380b8064c9b6a7b4c (origin/master, origin/HEAD) Author: Good Guy <good1.2guy(a)gmail.com> Date: Tue Aug 29 20:20:10 2023 -0600 Credit Andrew - rest of fix for Arch (and termux) which includes thirdparty/Makefile plus commit afa6a601fd3228be18aef413061b3d0165344d7c (HEAD -> master) Author: Andrew Randrianasulu <randrianasulu(a)gmail.com> Date: Wed Aug 30 07:27:57 2023 +0300 Fileext reading error handling for bg render commit cac447973db936f7d5594c83521c34f3e5a9c187 Author: Andrew Randrianasulu <randrianasulu(a)gmail.com> Date: Wed Aug 30 05:27:10 2023 +0300 Add libjpeg dep to.libtiff in thirdparty/Makefile commit 8297b38e49da0ce73e119138c158e806eb1fb45d Author: Andrew Randrianasulu <randrianasulu(a)gmail.com> Date: Wed Aug 30 02:48:47 2023 +0300 Possible fix for ffmpeg 4.4 in pluginfclient.C ==== so, ffmpeg 5.1 based cin seems to work on Slackware 15.0 i586 (with some self-build packages). Tested adding ffmpeg video filter to video track, and of course background render with on-the-fly compressor switch. aggrh, in commit message fileert instead of fileexr. I hope this is not a big problem will try my virtual machines next

3 19

OT: comments from youtube can be saved, too
by Andrew Randrianasulu 01 Sep '23

01 Sep '23

I stumbled upon video with 6K comments and opening them all one by one was too much work, so I looked if there was way to automate it Apparently yes! ytdlp_nest_comments.py -i file.info.json -o output.html and json produced by yt-dlp --write-comments https://gist.github.com/pukkandan/ee737fec64822f2552caf3ca4cbf5db7/raw/5ace… after this you can search in there .... I also noticed cinelerra-gg was typed-away as cinelerra-ng , Main complain apparently yes, lack of easy "clip" like synchro on timeline, but then with more clip-like timeline you usually need separate operation for "disconnecting" audio from video if need arise? I can only guess a/v sync problems were bigger back in analog capture days, so Broadcast2000/Cinelerra were coded with track paradigm instead of clip paradigm. This specific author comes under handle "Reluctant anarchist", not sure how serious he is about it, but for me anarchism is about, well, citizens who can do things without being bossed around, including repairs, including on software tools. But because everything is embedded in "money rule" world of today ..it really very uphill battle, from both "ghost of the past" problems like Windows dominance to very mindset of even nominally open-source programmers caught in endless update cycle. And even "unimportant video firmware issue" may lead to such oopsies as https://gitlab.freedesktop.org/mesa/mesa/-/issues/?label_name%5B%5D=VA-API https://gitlab.freedesktop.org/rdong/mesa-rdong-2021/-/commit/de95ff3a3dcb4… I mean, if video firmware was open AND there were outside developers understanding how to mod it those bitstream errors probably can be corrected on GPU side ..it all in _firmware_ exactly for greater flexibility and bug-fixability! But because h264 is patented It seems unlikely AMD will be able to open this part of their driver, let alone train libre software engineers on how to mod it .... and there is no active reverse-engineering project about this because .... video considered niche and ppl just buy bigger/newer CPU usually (even I bought new GF710 gpu because integrated Radeon3000 was hanging on object move in Blender 3.3! too big shader!) * - there was essay/opinion piece on osnews how Microsoft apparently forced PC dealers/vendors back in 1990x to NOT install anything but Windows. Today Microsoft developers work on mesa3d, but this unfortunately doesn't change world context ... https://www.osnews.com/story/136392/the-only-pc-ever-shipped-with-beos-prei…

5 35

CinGG 20230830 git code failure
by Mat 31 Aug '23

31 Aug '23

Hi, Pulled down git updates about 09 UTC today. Built from scratch on Debian 11, 32 bit, Mint21.2 64 bit, and Fedora 38 64 bit, all on real hardware (not in VM). - Debian builds fine, CinGG itself, manual, appimagetool, and the appimage itself. But any mesage box (e.g. starting .bcast dir removed) freezes CinGG, you have to kill it from the terminal. The error looks like dbg_add, dup 00000000ffffffff 11BC_Repeater 12BC_Clipboard If I avoid a message box, simply load a video as project, sound doesn't work, neither with PulseAudio (mmap error) or Alsa (protocol error) as device. Other applications work with Pulseaudio or Alsa (e.g. Audacity uses Alsa). The video doesn´t play at all. - Mint 21.2 Apart from the python problem builds and works fine for simple load-and-play HD video, did not try other actions. Have not tried building AppImage tool yet. - Fedora 38, builds CinGG proper fine, simple test is OK, although there is a load ffmpeg error saying the there is no hardware acceleration (vainfo and clinfo both show there is). Manual builds fine too. But the AppImage tool doesn't build, error about too many parameters somewhere. I try to see what's wrong with the AppImage tool on Fedora, time permitting. MatN

2 1

libtiff dependency
by Andrew Randrianasulu 31 Aug '23

31 Aug '23

sorry for mess ...

2 4

openexr error handling
by Andrew Randrianasulu 31 Aug '23

31 Aug '23

According to this page https://openexr.com/en/latest/ReadingAndWritingImageFiles.html ==== You may have noticed that in the example above, there are no explicit checks to verify that writing the file actually succeeded. If the OpenEXR library detects an error, it throws a C++ exception instead of returning a C-style error code. With exceptions, error handling tends to be easier to get right than with error return values. For instance, a program that calls our writeRgba1() function can handle all possible error conditions with a single try/catch block: 1 try 2 { 3 writeRgba1 (fileName, pixels, width, height); 4 } 5 catch (const std::exception &exc) 6 { 7 std::cerr << exc.what() << std::endl; 8 } ===== I guess this mechanism was not very refined in c++98, so it was not used in Cinelerra. Then come I and made EXR one of choices in background render (where error handling apparently matters). I hope one call per frame will not slow us down much .... and better slower than crash?

2 1

filepng additional error handling
by Andrew Randrianasulu 30 Aug '23

30 Aug '23

not sure why it was apparently working yesterday? example used: https://android.googlesource.com/platform/external/libpng/+/aa0ce810a62b165…

1 0

Oh, no, my ffmpeg 6.0 patch was failing with ffmpeg 4.4
by Andrew Randrianasulu 30 Aug '23

30 Aug '23

Now fixed hopefully tested on Slackware 15.0 i586 no-thirdparty build and termux/aarch64 rebuild with ffmpeg 6.0 Slackware line was: LDFLAGS=`pkg-config --libs x11` setarch i686 ./configure --with-single-user --without-thirdparty --without-lv2 --without-libdpx make there was: make --version GNU Make 4.3 Built for i586-slackware-linux-gnu Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. I wonder if Debian 9 have earlier make?

2 3