e to read a comment
> immediately after that it has been posted. I have to wait at least 12
> hours before I can read it. I don't know if it is the same for you.
> IgorBeg
>
> Il 01/10/2024 19:55, Phyllis Smith via Cin ha scritto:
> >
> https://www.cinelerra-gg.org/forum/hel
https://www.cinelerra-gg.org/forum/help-video/multi-camera-audio-sync-move-button-does-nothing/#post-2928
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
New AppImages are now available at:
https://cinelerra-gg.org/download/images/
but the special Red Hat older version which is Fedora Core 29 is not
available because the build went into an infinite loop and I have not
analyzed the problem yet
(CinGG-20240930-x86_64-older-distros-multibit.AppImage
In reviewing this thread of 32 notes, I was looking for anything that could
be included in the manual to help in building a custom version. However, I
think that the current statements of:
> 1) Getting a build to work in a custom environment is not easy.
> 2) With persistence, you can get results
Andrew, much better. Thank you. I have a lot more testing to do so this
update will not be included in Monday's release.
On Thu, Sep 26, 2024 at 1:43 PM Andrew Randrianasulu <
randrianas...@gmail.com> wrote:
>
>
> чт, 26 сент. 2024 г., 20:37 Phyllis Smith :
>
>> Un
Checked into GIT now. And includes the other small things:
- updated makeappimage tools for newer distros (Andrew fixes found when
analyzing Terje make app image)
- correct esound linking (resolved Termux error, but I did only 1 test with
this, but looks good)
- improve av1_svt render format (as T
Unfortunately, it has a problem. I started testing a couple of days ago
because I am still going through cinelerra-5.1/thirdparty/downloads.txt to
see which packages can be updated. Here is some of the output but I have
not diagnosed anything.
x265 [info]: HEVC encoder *version 4.0*+1-6318f22
>
Tested on 1 O/S and 1 file without any problem. Will checkin to GIT soon.
On Mon, Sep 23, 2024 at 8:16 PM Andrew Randrianasulu via Cin <
cin@lists.cinelerra-gg.org> wrote:
> was playing with esound (enlightenment sound daemon) on termux, found
> linking error if esound was enabled.
>
> Can anyon
Andrew, I am going to see if I can muddle through this tomorrow and
reproduce or get some understanding.
On Mon, Sep 23, 2024 at 3:53 PM Andrew Randrianasulu via Cin <
cin@lists.cinelerra-gg.org> wrote:
> I tried to trivially add qsv/mediacodec decode to cinelerra-gg, but
> discovered that I can'
9.2024 20:45, skrev Phyllis Smith:
>
>
> Terje, to fix the below plugin errors, you will have to modify
> cinelerra-5.1/ffmpeg/plugin.opts for your specific ffmpeg version since it
> will be different from everyone else when using your O/S version. Since
> you have successfully c
Terje, to fix the below plugin errors, you will have to modify
cinelerra-5.1/ffmpeg/plugin.opts for your specific ffmpeg version since it
will be different from everyone else when using your O/S version. Since
you have successfully completed the build, you can just modify
cinelerra-5.1/bin/ffmpeg/
Andrew, question about the 2 patches for tools/makeappimagetool. I applied
them here locally and reviewed the changes and it looks good. And you
tested these yourself, BUT I have not because I use my own custom script
based on MatN's work from when he initially created this for us. Question
: "s
As Terje suggested below ("Therefore I suggest that the Cingg preset make
use of the same SVT-AV1 defaults, to avoid confusing."), I modified and
tested the render format av1_svt.webm to be as follows.
*File contents of cinelerra-5.1/ffmpeg/video/av1_svt.webm*
webm libsvtav1
# If you do not want 1
X264 was at release r3106 of January 2023 and now is at r3191 of May 2024.
Expect Andrey's packages soon with updates at:
https://github.com/einhander/cin-gg-packages/releases
Andrea, if you have time could you rebuild just to get a little use out of
it before the end of the month build?
--
Ci
After testing with at least 10 different files, I found no problems so
checked into GIT.
This additional "detail" is helpful for ffmpeg files that have
transfer/primaries color attributes like bt709/bt601/bt2020.
On Wed, Sep 11, 2024 at 4:03 AM Andrew Randrianasulu via Cin <
cin@lists.cinelerra-gg
Thank you Andrew for spotting this typo. I have checked the correction
into the Manual GIT.
On Sat, Sep 14, 2024 at 2:47 PM Andrew Randrianasulu via Cin <
cin@lists.cinelerra-gg.org> wrote:
> https://cinelerra-gg.org/download/CinelerraGG_Manual/YUVShift.html
>
> ===
>
> This effect is used for Y
On Fri, Sep 13, 2024 at 12:10 PM Andrew Randrianasulu via Cin <
cin@lists.cinelerra-gg.org> wrote:
> Digital video and HD (2012)
>
>
> https://wangwei1237.github.io/shares/Digital_Video_and_HD_Algorithms_and_Interfaces_2nd_ed.pdf
> ...
> not sure if I'll learn enough for stopping confusing color s
Testing now. So far primaries and transfer characteristics are "unknown"
so I have to find better test material.
On Wed, Sep 11, 2024 at 4:03 AM Andrew Randrianasulu via Cin <
cin@lists.cinelerra-gg.org> wrote:
> please test
> --
> Cin mailing list
> Cin@lists.cinelerra-gg.org
> https://lists.ci
Andrea asked the question in another thread:
> I would like to ask how long moderation lasts for a new user. It
> is now more than a week (with 7 posts) that Tarantas has been
> registered...
>
It looks like it lasts forever until I uncheck the "Mod" box in the mailing
list for that user. I thin
This is a test to check Moderation.
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
went away and Cinelerra started up with hardware encoding enabled.
>
> I'm so sorry to waste you and the other subscriber's time.
>
> On Mon, Sep 9, 2024 at 6:48 PM Phyllis Smith
> wrote:
>
>> The error messages in error_log are the blacklisted ffmpeg filters th
The error messages in error_log are the blacklisted ffmpeg filters that do
not work and which should NOT even load.
The file in cinelerra-5.1/ffmpeg/plugin.opts contains the non-working
filters, preceded by a # sign (for example, aap or acrossfade, etc). That
file is copied to cinelerra-5.1/bin/ff
Checked into GIT:
Openjpeg upgrade from 2.5.0 to 2.5.2.
Tiff upgrade from 4.6.0 to 4.6.0t - this just puts back things deleted in
4.6.0 due to security.
Fixed Giflib 5.2.2 patch2 that Andrew found had a bug that Termux spotted
whereas Fedora and Ubuntu did not care.
--
Cin mailing list
Cin@lists.
Andrew,
Could you test the Termux build with the attached patch2? I found a
mistake in what I had checked into GIT that I thought I had fixed. I do
not get a failure on fedora or ubuntu 16 so can not test.
Mistake was corrected in the following + line in patch2 (QSort was
mistakenly typed as qsor
Patch 2 was added in February 2019 with the GIT commit "gif rework"
9afc3844e37c6db23435d5d0c33129dcc81061e4 and per the Release Notes:
Gif native capability has been completely upgraded to allow for reading and
> writing the gif format
> in singles, sequences or lists. As a side effect of this ef
On Wed, Sep 4, 2024 at 11:38 AM Andrew Randrianasulu <
randrianas...@gmail.com> wrote:
> due to giflib-5.2.2.patch2
>
> I removed patch and build is ok. Not sure where this patch was needed,
> may be on older distros?
>
> Maybe I did not correctly carry over patch2 when I upgraded giflib from
5.2
I will see if I can find any history of giflib-5.2.2.patch2.
Does the multibit compile work for you on Termux? Tarantas added to our
bug report of:
https://www.cinelerra-gg.org/bugtracker/view.php?id=650#c5694giflib-5.2.2.patch2
which I tried to track but failed.
On Wed, Sep 4, 2024 at 11:38 AM
On Tue, Sep 3, 2024 at 3:41 PM Andrew Randrianasulu via Cin <
cin@lists.cinelerra-gg.org> wrote:
> found via ffmpeg bugtracker referencing our bugtracker ;)
>
> https://trac.ffmpeg.org/ticket/6793
>
> Interesting. So the problem is with the Sony XAVC format (used by at least
FDR-AX100)? And since
Tarantas, thank you very much for working through a solution for this issue
and providing the "real world" example. Andrea, thank you for the Latex
version for the manual which has been checked into GIT and will appear in
the September 30th manual. As usual, I changed a few trivial things; for
e
>
> By the way^2 - I just notice the cinelerra manual is the first result
> for googling "mpeg color range". Cool!
>
Actually I find this a little "scary". One time I was writing up CinGG
Porter-Duff information for the manual and it was the first google search
and I was not even sure it was 100%
Terje,
>From the url: https://wiki.x266.mov/blog/svt-av1-second-deep-dive
"Preset 7: v2.0.0 vs v2.1.0
Again, there is no preset 7. Actually, it's preset 6 that disappeared but
I'm not remaking the graphs just for fun. If you select preset 6, you will
be granted the following message: *Svt[warn]: Pr
*Terje,*
Not sure why it reports it as SVT-AV1 Encoder Lib v2.2.0 because I
downloaded what is reported as v2.2.1 here:
https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases
and the downloaded tar file was shown as: SVT-AV1-v2.2.1.tar
Maybe whoever added the mods to create v2.2.1 forgot to updat
Andrew,
strange, web git interface thinks that
>
> cinelerra-5.1/thirdparty/src/libsvtav1-v2.2.1.tar.xz [moved from
> cinelerra-5.1/thirdparty/src/ffmpeg-6.1.tar.xz with 55% similarity] diff
> | blob | history
>
> I think it should be just new file?
>
> Yes, I did not like this either but was not
, 2024 at 3:38 AM Terje J. Hanssen
wrote:
>
> On 24.08.2024 20:13, Phyllis Smith via Cin wrote:
>
> The SVT-AV1 library was at version 1.8.0 and finally I got it upgraded and
> checked into GIT. At first I had to figure out what I was doing wrong in
> upgrading to 2.1.2, but by
Listed at a quarter of a million dollars in 1981! First time I have ever
watched an entire 1 hour video because it was interestingly and well done.
First half -- WHY?!? I would have given up on the hardware when 9 out 38
spinning disks failed.
And WHY did he not wear some kind of static guard whe
The SVT-AV1 library was at version 1.8.0 and finally I got it upgraded and
checked into GIT. At first I had to figure out what I was doing wrong in
upgrading to 2.1.2, but by the time I figured that out, they released a new
version on Aug. 24 (2.2.1). Encoding seems to be somewhat faster.
Previo
Stefan, I have never seen this. From what I have read on the internet, it
must be a vulnerability in the code that is probably fixable by an expert.
At least I can document it in the manual for other users.
It does seem that Google will reference stuff in the Manual and the Bug
Tracker as I have s
>From reading Lynne's note, it seems like the ffmpeg team will be merging
Vulcan into ffmpeg eventually. But if I remember correctly, it was Vulcan
that was delaying release of version 6.0 so it may be awhile. Would it not
make more sense to develop a patchset from Lynne's work rather than pull
ff
> If there isn't other reasons against it, I will suggest to rename the
> current preset av1.webm to av1_aom.webm
>
Good suggestion and no one has noted any reason not to. It is done in GIT
along with adding the 2 lines that make the rendered file seekable.
>
> And possibly upgrade to svt-av1 v.2
It looks like SVT automatically sets gop (Group of Pictures) and inserts
Keyframes in looking at Terje's output line:
"Svt[info]: SVT [config]: gop size / mini-gop size / key-frame type
: 161 / 16 / key frame"
and I get the same type of results that he did.
But I also get a warning, whi
H? for me it did lower the cpu load by about 20%, but not nearly as
much as disabling "Play track".
On Wed, Aug 7, 2024 at 1:27 PM Andrew Randrianasulu via Cin <
cin@lists.cinelerra-gg.org> wrote:
>
> I checked and no, "muting" video track does not lower its cpu load on
> muted portion.
>
d.
Still have to test av1_svt... next.
On Wed, Aug 7, 2024 at 2:52 PM Terje J. Hanssen
wrote:
>
>
> Den 07.08.2024 21:38, skrev Phyllis Smith via Cin:
>
> g=30
>> keyint_min=30
>>
> Seems to work for av1.webm format -- still testing. I want to test
> Andre
>
> g=30
> keyint_min=30
>
Seems to work for av1.webm format -- still testing. I want to test
Andrew's suggestions next.
On Wed, Aug 7, 2024 at 1:18 PM Andrew Randrianasulu
wrote:
> On Wed, Aug 7, 2024 at 9:13 PM Phyllis Smith via Cin
> wrote:
> >
> > Summa
*Summary* is that the error message is due to lack of keyframes and the
workaround is to use Transcode.
BUT hopefully a better solution with the Render format parameters can be
found. The render fix for h264/h265 formats is the addition of the lines
below (which obviously is not pertinent to av1).
> Might it be enough to write in the Manual on the ChromaKey (Avid) Video
> Effect, inside its footnotes, the sentence: "Avid is a trademark by Avid
> Technology, Inc."?
>
> Thanks for the notice and suggestion -- I have added the trademark notice
in the footnote.
--
Cin mailing list
Cin@lists.cin
>
> I was wondering,... can We use the word "Avid" in a plugin or other part
> of the software?
> Avid is a trademark.
>
> It probably could have been named ChromakeySpectramatte which is too
long. But naming it ChromakeyAvid as one word should be OK? I do not know
for sure. Alternatively, we ca
There are new AppImages at: https://cinelerra-gg.org/download/images/
All of the important changes are incorporated for fc38, suse15,
debian11/12, and ubuntu22 at:
https://github.com/einhander/cin-gg-packages/releases/tag/20240718
*Andrey*.could you check 20240728 / 20240729 for the ubuntu22
Stefan,
Using Color3Way plugin as another test and the command "top", I am still
getting considerably less CPU usage when I disable the plugin from when it
is enabled. I have tested with my driver set to X11-OpenGL and X11 with
"use Direct" checked and in both cases, it is better. Not sure why tha
Stefan, in looking at the performance improvements you outlined below, this
one is really a HUGE improvement:
- modifying the "stacked video" (opacity 100%) to disable "Play track" in
the patchbay for the tracks that you do not need to see is the winner. I
will add that to the Performance Tips s
appropriately addressed before official. That is just my wild guess.
On Tue, Jul 23, 2024 at 3:39 AM Terje J. Hanssen
wrote:
>
>
> Den 23.07.2024 00:17, skrev Phyllis Smith via Cin:
>
> Thanks to Andrey also. I have added a News update which is maybe just
> confusing at:
>
> http
Thanks to Andrey also. I have added a News update which is maybe just
confusing at:
https://www.cinelerra-gg.org/news-updates/appimage-note-for-some-really-new-operating-system-distros-or-pre-releases/
Hopefully the distros and AppImage will include a less confusing resolution
with an official r
Thanks Mat for the below statement as I would not have suspected that and
am working on adding a News item to the website.
Confirmed on Mint 21.3. It seems that if fuse2 is available, the
> appimage-extract-and-run will not work, instead it starts up normally.
>
>
--
Cin mailing list
Cin@lists.ci
Andrea,
No problem, I misunderstood. I am just going to update the website News to
advise users of a potential problem in new future O/S distros and some
workarounds.
On Mon, Jul 22, 2024 at 2:12 PM Andrea paz
wrote:
> @Phyllis
> I think for Arch there is no problem with the appimage. As I told
It looks like the possible workarounds include the 3 listed below.
Quote from MatN:
> Fuse is not needed by CinGG itself, it is used only by AppImage to expand
> the compressed image and start it. (So there is no way to add something in
> CinGG to avoid the issue).
> - an ugly workaround is to sta
No, I was planning on leaving both formats for now (unless Andrew-R
suggests otherwise) and just remove the profile line from h264-10bit.mp4.
On Sun, Jul 21, 2024 at 5:47 PM Terje J. Hanssen
wrote:
>
>
> On 22.07.2024 01:23, Phyllis Smith wrote:
>
> When I read ffmepg Profile sec
will
eliminate the "profile=high10" from the h264-10bit.mp4 format and then it
will work.
On Sun, Jul 21, 2024 at 3:58 PM Terje J. Hanssen
wrote:
>
> On Sun, Jul 21, 2024 at 1:03 PM Terje J. Hanssen
>> wrote:
>>
>>>
>>> On 18.07.2024 23:45, Phyllis
Stefan,
Not sure how useful the Cuda option for HW acceleration is unless you want
to use its plugins.
An authoritative statement about the Cuda HW option from the manual says:
> Cuda does not accelerate decoding with Nvidia, but it does allow some
> plugins to run that are not available otherwis
tps://trac.ffmpeg.org/wiki/Encode/H.264
On Sun, Jul 21, 2024 at 2:10 PM Andrew Randrianasulu <
randrianas...@gmail.com> wrote:
>
>
> вс, 21 июл. 2024 г., 22:04 Terje J. Hanssen via Cin <
> cin@lists.cinelerra-gg.org>:
>
>>
>> On 18.07.2024 23:45, Phyllis
onfirm.
On Sun, Jul 21, 2024 at 2:54 PM Phyllis Smith
wrote:
> Terje, there is a conflict between ALL of the parameters. If I am not
> mistaken, you can get the results you want by choosing h264-10bit.mp4,
> change the down arrow of pixels to yuvp42210le AND most importantly in the
with them). Let us know if this does or does not work correctly.
On Sun, Jul 21, 2024 at 1:03 PM Terje J. Hanssen
wrote:
>
> On 18.07.2024 23:45, Phyllis Smith wrote:
>
>
> ALL appimages will now be multibit just as if we had checked these patches
> into GIT originally. None
t 11:37 AM Phyllis Smith
wrote:
> With AppImage being probably the most prevalent method of executing CinGG,
> a major problem on Debian Trixie (not yet officially released) has cropped
> up preventing its usage. Supposedly due to appimage stuff depending on old
> outdated Fuse2 libraries.
Andrea, sorry for the confusion. See below.
2- Maybe I didn't understand correctly. Do you intend to rename all
> the 2023/24 appimages, removing the word multibit, and deleting the
> 8-bit ones? Will only the "older-distros" be left untouched? And the
> "i386" versions are all 8-bit? I will cha
Andrea, a few answers below. This just seems confusing, but we should have
done this initially when Andrew-R supplied the patch.
1- how to do if you want to compile the 8-bit version?
>
I would change the section "Multibit build for x265-8/10/12-bit" to note
how to compile the 8-bit only version.
slowed things down.
On Tue, Jul 16, 2024 at 2:06 PM Phyllis Smith
wrote:
> I believe that compiling x265 with the 3 patches just makes it possible to
> encode 8-bit as usual, as well as the additional encode possibilities of
> 10-bit and 12-bit. *That is all that is affected *with what we
With AppImage being probably the most prevalent method of executing CinGG,
a major problem on Debian Trixie (not yet officially released) has cropped
up preventing its usage. Supposedly due to appimage stuff depending on old
outdated Fuse2 libraries. Is this my fault for using an older version of
I believe that compiling x265 with the 3 patches just makes it possible to
encode 8-bit as usual, as well as the additional encode possibilities of
10-bit and 12-bit. *That is all that is affected *with what we have just
been calling "multibit", i.e.:
1. encode ONLY
2. x265 ONLY
3. 8-bit basi
Andrea has convinced me that the x265 addition of 10 and 12 bit should be
the default (i.e. the compile_multibit_X265.patch automatically in
effect). I have now run tests on an older operating system, ubuntu 16, and
an older 32-bit 9.1debian system, with no problems. The compile time may
be longe
The below 2 items are now fixed with today's GIT checkin. IgorBeg provided
the Chromakeyavid and Color Swatch picons visible in the Resources Window
under Video Effects and SGE has updated Context_Manual.pl so that
ChromakeyAvid alt-h correctly references that in the manual.
> I forgot to (1) cre
They look great! Thank you to IgorBeg. I will check them into GIT soon.
On Fri, Jul 12, 2024 at 1:33 AM Igor BEGHETTO via Cin <
cin@lists.cinelerra-gg.org> wrote:
> Phyllis wrote:
> "June 2024 release:
> Unfortunately, because of additional stuff requiring my attention, I
> made little progre
Catching up on this thread with some trivial commentary on my part.
I looked into which pixel formats current ffmpeg-7 encoders in question do
> support as follows: "QUOTE from Terje"
>
The "pixel formats" that CinGG supports with whatever ffmpeg version is
currently being used, is shown in the R
>
>
>> Will it be possible to add the version info here?
>>
>
>
> well, it was working in the past with configure switches enabling
> x264/x265 multibit versions compilation. Now x264 should be always multibit
> and x265 patched manually ... I'll think about something but not sure if
> there easy w
Corrections and better explanation have been checked into the GIT
repository for the manual and will be updated in the online Manual at time
of the next release. Thanks to both Bulhwi Cha and Andrea.
On Sat, Jul 6, 2024 at 9:03 AM Bulhwi Cha via Cin <
cin@lists.cinelerra-gg.org> wrote:
> 2.6. Ot
June 2024 release is ready with the AppImages. Users who have the
automatic package update for some of the recent Operating Systems using:
https://github.com/einhander/cin-gg-packages/releases
will already have the latest updates. See copy of June release notes below
the ***.
Unfortunate
Bulhwi, thank you very much for the work you have done to not only find
these errors, but to write down what they are and how to fix them. I have
fixed most of them and the corrections will be in tomorrow's next release
Manual update.
2.5. Resources Window
>
> 2.5.3. Modify Folder: sorting the
Andrew,
So, with this and your second email "cingg on Window 10 not quite work", am
I right in assuming that with the patch that probably was necessitated due
to updated cygwin is not working? I suppose I could drag out the old
Windows 10 computer here and see what is on it. Most likely it will s
Not sure yet as I have to remember how to use this. Maybe Andrea or
IgorBeg are better able to address this.
On Fri, Jun 21, 2024 at 11:48 AM Bulhwi Cha via Cin <
cin@lists.cinelerra-gg.org> wrote:
> In the Modify folder window, the following list of two filters doesn't
> exclude files modified
>
>
> My setting was already X11. I played around with some other options, but
> did not find the problem. I can obviously provide some source material
> to test with.
>
> Wow, that is really strange. Did I understand correctly that when you
render it is aligned right?
If you have time and a small
If rendering is correct while playback is not, it could be the OpenGL
driver used in playback. Rendering ALWAYS uses software and is not subject
to the vagrancies of OpenGL. With the test I did, I could not detect a
playback error when using OpenGL. Stefan, you can test this theory by
changing S
So, when you have gone as far as you can, would it be worthwhile to tar up
all of these patches and put it on the website in case anyone else wants to
try it?
I tried to workaround raw data embedding using this stackoverflow answer:
>
>
> https://stackoverflow.com/questions/34641373/how-do-i-embe
Bulwhi, thanks again. It is now corrected along with 2 other figure
numbers and will be in the next release.
On Fri, Jun 14, 2024 at 10:18 AM Bulhwi Cha via Cin <
cin@lists.cinelerra-gg.org> wrote:
> In section 2.5 'Resources Window' of the HTML User Manual (31 May 2024),
> a figure number is mi
Thank you very much for reporting mistakes in the manual. I have checked
this into the Manual source and the next time there is a release, it will
be fixed. Please report any other obvious errors if you notice them and
have time.
On Thu, Jun 13, 2024 at 10:18 AM Bulhwi Cha via Cin <
cin@lists.ci
There are now builds for users to test:
https://cinelerra-gg.org/download/testing/cin-x86_64_chromakeyavid.AppImage
(works on ubuntu 16 + newer O/S)
https://github.com/einhander/cin-gg-packages/releases (packages for
specific newer O/S)
Included in the above builds is the newest ContextManual.
What an interesting project! good luck, it sounds like a big challenge!
On Mon, Jun 10, 2024 at 8:56 AM Andrew Randrianasulu <
randrianas...@gmail.com> wrote:
> You guess it - I tried to convince cingg to build on macos 10.12.6
>
> bchash.C:184:13: error: use of undeclared identifier 'open_memstr
That is the BIG advantage of AppImage -- it will work on most other Linux
operating systems and on most other same or any newer version levels. And
that is why ubuntu 16 will most likely be the version where the alternative
shortcuts will be created for several years yet! Thank you IgorB for
test
Unfortunately, Dav1d uses meson instead of cmake. The current old version
included with CinGG was converted from meson to cmake. It would take
someone who knows both meson and cmake intricacies to do the same
conversion for an updated version of Dav1d.
On Fri, May 31, 2024 at 12:35 PM Andrea pa
*New release *of May 2024 appimages now available at:
https://cinelerra-gg.org/download/images/
These executables contain the same updates as the latest packages for newer
operating systems at:
https://github.com/einhander/cin-gg-packages/releases/tag/20240522
-- This means that if you
html is now cin-index.html (mods were made earlier on the website
to use different index name)
On Sun, Apr 14, 2024 at 12:39 PM Phyllis Smith
wrote:
> I fixed it - no reason not to since it was discovered by Georgy and since
> Andrey pointed it as a potential problem on
> fat32 on Win
Thanks to the user and Andrea for good suggestions and implementation which
I have reviewed and checked into GIT. I also opened up a Bug Tracker #660
for the user's discovery of a long time error for the Render menu, Render
Range of Selection or In/Out points, starting at the beginning of the
time
Terje, thanks for letting us know. I have downloaded it and will test in
June to use with CinGG.
On Wed, May 29, 2024 at 9:47 AM Terje J. Hanssen via Cin <
cin@lists.cinelerra-gg.org> wrote:
> According to Phoronix the Alliance of Open Media project quietly released
> (the Intel based) SVT-AV1 v
Reminder for those with recent versions of the Operating Systems, you can
install the packages from Andrey's website:
https://github.com/einhander/cin-gg-packages/releases/tag/20240522
Quote from website is below (I do not currently see suse15 there):
> Storage for Cinelerra-gg nightly packages f
Very entertaining, but I did not watch all 22+ minutes. It is amazing how
some of the 20+ year old software was really pretty good and still works
under the right circumstances. I still use "xv" daily which was written in
the 1990's!
On Thu, May 23, 2024 at 9:04 AM Andrew Randrianasulu via Cin <
FFmpeg 7.0 checked into GIT (previous version 6.1) thanks to Andrew
updating numerous patches in ffmpeg plus another bunch in the cinelerra
subdirectory (5 or so). And thanks to Andrea and others for all of the
testing and problem reporting. If Andrew and Andrea can verify I did not
make any mist
Thanks again to Andrea. I had to make a single change as my Latex got an
error on: ($#ff00$). I had to remove the 2 $ to solve it.
> To add the explanation of the new keys and equalize the presentation
> to what was done for ChromaKey-HSV, I updated the manual for the
> ChromaKey plugin. Yo
About CinGG in wayland as stated below. I think the error message is from
the graphics library (gl_...) and is probably one of the startup screens
that has gl commands that may be different now than before. Just a guess!
On Tue, May 21, 2024 at 2:16 PM Andrea paz
wrote:
> I tried to start CinG
This is consistent behavior with other plugins. For example Sharpen,
Linear Blur, Wave, Radial Blur.
> Instead, an important thing that I had noticed even before trying
> wayland, but forgot to report in the previous email is that the
> “Default” button returns the threshold to 10, as required. I
Chromakey plugin has had its menu improved by anonymous contribution and it
has been checked into GIT. (Andrea, can you test it too? and check the
manual to make sure still matches and make new image?)
Improvements include:
- added Default button
- default values for Threshold and Slope changed f
is updated
but still working on it.
So, unless Andrew-R thinks it is still too soon, I was planning on checking
in FFmpeg 7.0 and patches this week and making new AppImages on May 31.
On Mon, May 20, 2024 at 1:42 PM Phyllis Smith
wrote:
> Also, it was suggested that we (cinelerra-gg) can cre
>
> Also, it was suggested that we (cinelerra-gg) can create different git
> branch < named, say, "testing" > for "potentially unstable" patches, like
> current ffmpeg 7.0 patchset and then merge back to main/stable when feature
> is deemed ready.
>
+2 for testing branch. (wink, wink).
Actually
Thank you. The new image of chromakeyhsv menu has been checked into GIT.
On Thu, May 16, 2024 at 12:43 PM Andrea paz via Cin <
cin@lists.cinelerra-gg.org> wrote:
> With the new, beautiful, configuration window, we need to change the
> image in the manual.
> --
> Cin mailing list
> Cin@lists.cine
That is probably OK as long as it just keeps working. I did notice that we
are at 0.7.4 and there is an 0.8.0 available but "if it isn't broke, don't
fix it".
Probably in another 20 years, Cinelerra will be replaced with a totally
revolutionary alternative. But it won't be Olive.
On Tue, May 14
1 - 100 of 1515 matches
Mail list logo
