- Cin - Cinelerra-GG Mailing Lists

July monthly builds available BUT lots of clean up still..
by Phyllis Smith 01 Aug '20

01 Aug '20

We had a lot of problems with the builds yesterday so have a lot of cleanup and documentation fixes to do yet this weekend. Some problems listed here. Tumbleweed (Leap-ish) may be eliminated next month because it is very time-consuming to upgrade this Operating System every month since it is not a distro that we use on a daily basis. It has been a problem every month; for example 2,000 packages had to be updated for it between June 29 and July 29 and then it did not work correctly. Instead we ended up doing a brand new install which also took a lot of time (about 4 hours). So unless we get feedback that it is worth the time, it will be dropped. Leap 15-02 build and Mint 20 are new builds this month but installing has not been tested or updated on the website due to time constraints. Arch, Tumbleweed, and Gentoo are OK but GG had to make some changes. ------------------------ *Release Notes *(found on website as usual) Cinelerra-GG (Version Infinity) Release Notes for 07/01/2020-07/31/2020 for builds 1. *Upgraded several thirdparty libraries* to include: *FFmpeg to 4.3* – with new plugins of asubboost (audio) and addroi, bilateral, cas, dblur, gradients, median, photosensitivity, scdet, scroll, sierpinski, thistogram, tmedian, untile, v360, yaepblur (video) plugins. You can use “i” in the Resources window and mouse on each to get short information. *+ turbo-jpeg, vorbis, x265, vpx, lv2, aom, and dav1d.* 2. Mint 20 builds are now available and Leap is updated to 15.2.2. 3. *Gang modes*, which includes Gang Channels mode for DAW-like editing, has minor improvements: - Using Shift on the gang mode toggle, switches back to the previous mode thus making it easy to see a different view temporarily in order to view the actual track lineup. - Gang Channel icon in the top line of the timeline, is yellow to help make it clear that you are in this mode. The Gang Media icon is red as a warning of this mode. The default Gang None is just in a theme related ordinary color, often white. - A slight change in the order of symbols in the Patchbay has been made for aesthetic purposes. - Wysiwig tweak for ganging set of the Master Track for channels. 4. *Align Timecodes* feature has been added based on different timecodes or timings included with the files. LTC from external generated audio has not been incorporated due to lack of proper test material. Usage description is included temporarily as a pdf file attached to BT# 448 (which prompted this incomplete feature). 5. *Tracks Swap Up/Down* added to the Tracks pulldown to provide previous capability that was in “move up”/”move down”. 6. *Usability Improvements:* In the Viewer window, you can, but no longer have to press Rewind button to start Play over again. This includes play, fast play, play reverse, and fast play reverse (Skinkie BT #463). Many FFmpeg plugins required the use of the Apply button before a parameter change would take effect. Now when you type in a parameter change and hit the Enter key, the change will take effect (Skinkie BT #464). *Auto Rotate for ffmpeg video that has “metadata” *defining the rotation in 90 degree increments has been implemented and is now the default, but you can change this in Settings→Preferences, Appearance, Flags (Ig0r forum “Rotation metadata usage in viewer/compositor”). Added a dump_stack to the generated crash dumps so that this information is always included, thus making user crash dumps more valuable for analysis and potentially fixing the bugs that are found. *Subtitles now have a choice of format* in that menu; srt for SubRip which is now the default, sub for Subviewer and udvd which was the original MicroDVD format (RafaMar BT #475). *Mix master*s menu item added under the Window pulldown → Mixers subwindow. This additional feature makes it very easy to get into the multi-camera mixer mode after tracks have already been set up and edited. When using “File by Reference” if you exit without “saving”, a reminder will popup to allow you to choose to save so that you do not lose work. Minor Spanish translation update (from Rafamar). 7. *Bugs/Issues fixed:* The “drag” checkbox for the following plugins has had a major rework done: Sketcher, CriKey, Title, Tracer, and Boxblur Change prompted by BT #482 from RafaMar which was a bug. Two additional bugs were found while working this problem and have now been fixed too. The “drag” value is no longer saved in the keyframe. Problem with resizing the textbox with the Y axis has been fixed (RafaMar BT #456, subtitle). The Mask has been tweaked to fix an edge case of 128 cpus which lead to undesirable lines. An Index bug that has been around for some time where the drawing on the timeline did not complete, has been fixed. A reference count has been added in 19 places to keep track of cache as a design implementation change to resolve occasional SEGV crashes. Fixed break created by creating a clip in OpenEDL edit mode (Fary54 BT #470). Fixed a bug in ffmpeg scan remap code. Applied a modified patch for configure.ac with a precedence problem in at least 3 different places (Ferdnyc supplied patch information in BT 473). Hang cinelerra_18388.dmp when use “s” in OpenEDL level (BT #470 Fary54 and Andrea both reproduced this bug). If Render Farm is enabled and you render a single frame, it was creating multiple output instead of just 1. This is now fixed. ResampleRT plugin to speed up and slow down the audio is now fixed (Houku BT#474). A fix for a segv that occurred while testing has been made also. Fixed affine.C and interp.h which are used in the Motion and Perspective plugins, as well as in other places, for various boundary conditions (Georgy aka sge, patch in BT #474). A mod has been added to fix usage of Paste in the Resources window when preview media is enabled (RafaMar BT # 476). PatchB for ffmpeg is a temporary patch until a new release that includes this ssse3 patch is available. It fixes a padding issue of 16 as 4 was insufficient. A fix for another vicon thread lock problem has been added through rework (Armandux BT #481) + fixed a discovered problem of vicon interruption during a render operation. Tweaked Closed Caption text fonts (for personal use). Fixed sync EDL for plugin gui flip out and tweaked plugin gui id’s. Changed vrender reconfigure to fix a problem. Added listbox selection index range tests to prevent issues. Modification made to the build procedure to allow for Cuda version 11. A fix to also change the length in OpenEDL of the audio has been added (Fary54 BT#430).

4 5

July upgrade on openSUSE Leap 15.2
by Terje J. Hanssen 01 Aug '20

01 Aug '20

Hi, I had some issues following the normal upgrade procedure on Leap 15.2: # zypper up cinelerra Repository 'cingg' is invalid. [cingg|https://cinelerra-gg.org/download/pkgs/leap15/] Repository type can't be determined. Please check if the URIs defined for this repository are pointing to a valid repository. Warning: Skipping repository 'cingg' because of the above error. Some of the repositories have not been refreshed because of an error. Loading repository data... Reading installed packages... 'cinelerra' is already installed. Package 'cinelerra' is not available in your repositories. Cannot reinstall, upgrade, or downgrade. Resolving package dependencies... Nothing to do. Then I changed the repo uri to [cingg|https://cinelerra-gg.org/download/pkgs/leap15.2/ and got Cinerelerra upgraded to the quite new July version. However the 10-bit version is not yet available: # zypper up cinelerra10bit Loading repository data... Reading installed packages... 'cinelerra10bit' is already installed. Package 'cinelerra10bit' is not available in your repositories. Cannot reinstall, upgrade, or downgrade. Resolving package dependencies... Nothing to do. So currently I have the following July and June 10-bit versions installed: # zypper se -is cinelerra Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+----------------+---------+--------------+--------+----------- i+ | cinelerra | package | 5.1-20200630 | x86_64 | cingg i+ | cinelerra10bit | package | 5.1-20200630 | x86_64 | cingg I hope the previous common /Leap uri and 10-bit version will be available next? Rgds, Terje J. Hanssen

2 2

Linux mint 20 Ulyana
by Gerd + Beatrix Elgert 01 Aug '20

01 Aug '20

Hello mint! Need the package /mint20 ulyana main Thks Gerd

2 2

July upgrade on openSUSE Leap 15.2
by Terje J. Hanssen 01 Aug '20

01 Aug '20

Hi, I had some issues following the normal upgrade procedure on Leap 15.2: # zypper up cinelerra Repository 'cingg' is invalid. [cingg|https://cinelerra-gg.org/download/pkgs/leap15/] Repository type can't be determined. Please check if the URIs defined for this repository are pointing to a valid repository. Warning: Skipping repository 'cingg' because of the above error. Some of the repositories have not been refreshed because of an error. Loading repository data... Reading installed packages... 'cinelerra' is already installed. Package 'cinelerra' is not available in your repositories. Cannot reinstall, upgrade, or downgrade. Resolving package dependencies... Nothing to do. Then I changed the repo URI to [cingg|https://cinelerra-gg.org/download/pkgs/leap15.2/ and got Cinerelerra upgraded to the quite new July version. However the 10-bit version is not yet available: # zypper up cinelerra10bit Loading repository data... Reading installed packages... 'cinelerra10bit' is already installed. Package 'cinelerra10bit' is not available in your repositories. Cannot reinstall, upgrade, or downgrade. Resolving package dependencies... Nothing to do. So currently I have the following July and June 10-bit versions installed: # zypper se -is cinelerra Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+----------------+---------+--------------+--------+----------- i+ | cinelerra | package | 5.1-20200630 | x86_64 | cingg i+ | cinelerra10bit | package | 5.1-20200630 | x86_64 | cingg I hope the previous common /Leap uri and 10-bit version will be available next? Rgds, Terje J. Hanssen

1 1

Fwd: Error in compile
by Phyllis Smith 28 Jul '20

28 Jul '20

Am forwarding a discovery from Andrea about Cuda on Arch. Yesterday there was an update of Cuda (2GB), you can see that > something went wrong. > By default with-cuda is active; I had to put without-cuda to avoid errors. > "Val.log" I put it in BT #0000482, in case others wanted to see it too. > CinelerraGG is still at version 10 but the latest version Andrea reported on is version 11. It no longer supports compute-30 so GG has checked into GIT a mod to make it possible now to compile Cuda on Arch at the latest version.

2 1

Patch against interpolation bug in cinelerra/affine.C, interp.h
by Georgy Salnikov 20 Jul '20

20 Jul '20

Recently I accidentally found the following bug in Cinelerra-GG and created a patch to correct it. When trying to stabilize video with the 'Motion' plugin I got repeatedly a constantly accumulated clockwise rotation of the video frames (when tracking 'Previous frame same block') or twitching video (when 'Tracking single frame'). After some debugging and dumping temporary frames in PPM format I found that, for example, rotation of a frame to the angle of 0.000000 degrees actually results in its translation one pixel to the right and one pixel down. This was the reason for the Motion plugin to try constantly to rotate video about 0.25 degrees each frame. The actual location of this problem was in the Affine engine, namely in the used interpolation macros. The wrong expressions for displacements of the interpolated pixels lead to that, for example, that when the input and output points should coinside (which is the case for the 0 degree rotation), the X and Y of the pixel which are to be taken with the coefficient 1.0 become (tx-1,ty-1) instead of (tx,ty). Perhaps the bug in Affine could influence also other features in Cinelerra, but to observe such a subtle displacements in most of video editing scenarios looks not so easy. On the contrary, the accumulated rotation while motion stabilization makes it evident. In cinelerra/interp.h I corrected only the expressions for the integer coords and float displacements for the interpolated pixels. The main correction in cinelerra/affine.C (look in the patch attached) is at the lines 245-246: the processed frame block size was one pixel less both in horizontal and vertical directions. I have found only one other similar place in the code, namely in the 'Lens' plugin, and there the calculation of max x and y was correct. Additionally I'd propose to correct affine.C at the lines: 188 (perhaps an unportable method to compare a float variable with 0.0) 693 (looks like a definitely incorrect calculation of y1 for the package #0) The rest, commented out, are for debugging output only. This patch is against cin_5.1.20200430-src.tgz, I posted it to bugtracker as issue 479. Thanks for the attention Georgy _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email sge(a)nmr.nioch.nsc.ru _______________________________________________________________________________

1 0

Fuzzy "Align Timecodes" checked into GIT
by Phyllis Smith 20 Jul '20

20 Jul '20

I ran out of time to document concerning BT 448 description, demo, and documentation. But here is a quick demo at: https://streamable.com/nwec0t The most IMPORTANT thing to know right now is that we had no "real" data to test this but only "manufactured" data. It would take video from preferably 3 cameras filming the same scene from different angles but not started at the same time AND cameras that are smart enough to supply "real" timecodes in the data. Here is the unfinished documentation: *New Feature – Align Timecode* New feature includes the following relevant parts: - Align Timecode under the Window pulldown - Clapperboard icon on the main timeline to set a timecode - Timecode option added to timebar choices (where you have hh:mm:ss, etc) - Time Code Start in the Resources window on the bottom of Info for the media (when set) - MMB on a track allows for Timecode option to display the timecode for that particular track Here are the comments from the code ; ) /* * 1) if the format context has a timecode * return fmt_ctx->timecode - 0 * 2) if the layer/channel has a timecode * return st->timecode - (start_time-nudge) * 3) find the 1st program with stream, find 1st program video stream, * if video stream has a timecode, return st->timecode - (start_time-nudge) * 4) find timecode in any stream, return st->timecode * 5) read 100 packets, save ofs=pkt.pts*st->time_base - st->nudge: * decode frame for video stream of 1st program * if frame->timecode has a timecode, return frame->timecode - ofs * if side_data has gop timecode, return gop->timecode - ofs * if side_data has smpte timecode, return smpte->timecode - ofs * 6) if the filename/url scans *date_time.ext, return date_time * 7) if stat works on the filename/url, return mtime * 8) return -1 failure */

3 2

News in Git
by Andrea paz 20 Jul '20

20 Jul '20

I answer here to all the news made in Git (great job, thanks!): ResampleRT --> OK Save on OpenEDL session --> OK Full Play paste, freeze --> OK Align timecode --> I can't test it, sorry. But I'm delighted with this addition to the Pro world. Auto Rotate --> OK

1 0

Auto Rotate checked into GIT is default preference
by Phyllis Smith 20 Jul '20

20 Jul '20

Just so no one is surprised, there is a new FLag Settings->Preferences for "Auto rotate for ffmpeg media". The default is to do this rotation so if in the past you loaded cell phone media and it was off by 90 or 180 degrees, it will now be automatically rotated in the display AND the render. If you do not want this behavior, change the Preference flag. See forum topic on "Rotation Meta Data usage in viewer/compositor". The reason this was implemented after all is to keep up with the smart phones/go pro usage (and maybe drones, but I do not know for sure).

1 0

New Appendix in Manual pdf
by Andrea paz 17 Jul '20

17 Jul '20

I wanted to ask for an opinion on a couple of new things that I have introduced in the manual (but going back is easy; that's why I ask for advice): 1. The nice pdf tutorial of fary54 I put it in a new section of the appendix, both because it is 4 pages long, but above all to give it more importance and accessibility. What do you think about it? Is it better to put it back in the body of the manual, in the corresponding section? 2. Also, in the fary54 tutorial I put links to his videos that illustrate some passages. These videos are uploaded in our Youtube channel, but they are not visible to the public. Thanks to Sam's idea, they are put as "unlisted" and can be seen only by following the link put on the manual. They're not real tutorials, they're simply the analog of the videos that we sometimes put on streamable to make new users understand how some tools work. Do you like the idea of integrating the manual with explanatory video links or is it better to keep Manual and videos separate? Note: if you want to contribute, describing the type of workflow you use in your daily editing work, it would be a valuable addition to the manual. I personally would like to know how to do audio editing (sync, audio in different tracks, sound mixing, etc), since I'm totally ignorant about it.

2 1