- Cin - Cinelerra-GG Mailing Lists

Fossies - software archive
by Andrew Randrianasulu 29 Aug '21

29 Aug '21

I wonder if we should add CinelerraGG into it? so far only Cinelerra 7.3 actually there (but it provides some autogenerated software documentation?) https://fossies.org/search/linux/misc?q=folder_search&ml=25&q1=cinelerra&q2… https://fossies.org/dox/cinelerra-7.3-src/adeviceprefs_8C.html for example.. might be useful for more real (experienced) programmers? ps: not sure if 7.3 can be called Community edition now?

2 2

oh, I see ffmpeg 4.4 in?
by Andrew Randrianasulu 28 Aug '21

28 Aug '21

does it work finally without eating video's tail?

3 13

illustration about 'iris square' transition
by Andrew Randrianasulu 27 Aug '21

27 Aug '21

1 0

Wayland
by Andrea paz 23 Aug '21

23 Aug '21

I'm trying wayland and CinGG opens a warning window when I load a project; see image. Everything works fine and there are no messages at the terminal, but I was wondering if it does it to you too.

3 4

Test rendering whit x265
by Andrea paz 18 Aug '21

18 Aug '21

I did some tests with the new and old x265. I report some data, while the terminal output is attached in test-x265.txt. I used a 5 min video in h264 4.2.0 but good quality. Size= 471 MB. x265-10bit: CPU 50-80% (multithread) 27.5 fps file size 46 MB x265-12bit: CPU 50-80% (multi) 25.5 fps file size 45 MB x265-Hi: CPU 80-90% (multi) 10.6 fps file size 1.7 GB x265-Lo(w): CPU 40-70% (single/multi) 34 fps file size 67.5 MB HEVC-vaapi CPU 0-50% (single) 85.8 fps file size 117 MB (I could not see the GPU engagement) Only in x265-lo do I perceive a small decay in quality compared to the original. All others are comparable. For me a great news (thanks Andrew!) is the exploitation of multithread; on the terminal you can read the sentence: "Thread pool created using 16 threads" I have a CPU 8c/16t. The only thing I regret is that the new x265 drivers introduce a CinGG build delay of 15 min. Before my entire compile was 5 min, now it's 20 min.

3 36

arm/termux patches update
by Andrew Randrianasulu 17 Aug '21

17 Aug '21

contain a lot of experimental/debug stuff.. Mostly for Andrea

4 5

variable fast/slow playback speed hack
by Andrew Randrianasulu 11 Aug '21

11 Aug '21

so i wondered if changing speed for fast/slow reverse and normal playback was possible.. after few hours of hacking I made this patch. it makes fast/slow playback speed configurable in Cinelerra_rc via new stored variables: ===j LOADPREVIOUS16 /data/data/com.termux/files/home/LibRaw/RAW_CANON_G1.CRW LOADPREVIOUS17 /data/data/com.termux/files/home/av1-cpu5-crf10.mkv SLOW_SPEED 5.000000e-01 FAST_SPEED 4.000000e+00 here I set fast playback speed to 4x, while slow_playback default remain at 0.5 .... no gui yet because I am still unsure about gui elements but I had idea about putting two input boxes in Preferences for this.. but I can be wrong with my hacking....

3 12

Fwd: in/out point selected plugin attach fix?
by Phyllis Smith 11 Aug '21

11 Aug '21

For some reason, my reply only went to Andrew so am forwarding it correctly. ---------- Forwarded message --------- From: Phyllis Smith <phylsmith2017(a)gmail.com> Date: Sun, Aug 8, 2021 at 7:52 PM Subject: Re: in/out point selected plugin attach fix? To: Andrew Randrianasulu <randrianasulu(a)gmail.com> Andrew, forgot to respond to the following: again, I wonder why it was noted by Phyllis "but making it a Preference is > not > a good idea.". Just because our Preferences a bit crowded already? > In the past, we have gotten into trouble when the Preferences window got bigger on some smaller monitors. A goal has always been to have Cinelerra continue to work on lesser hardware (which is one of the reasons proxy exists). What was happening is that the Preferences menu on a small monitor was cut off at the bottom and so there was no way for the user to click OK, Apply, or Cancel ! so the user was stuck. There is a minimum size for this window and adding more Preferences in the Appearance tab causes problems if it does not fit while still "looking good". So at this time it is very important to save room in Preferences for the really necessary things.

3 6

Fwd: variable fast/slow playback speed hack
by Phyllis Smith 10 Aug '21

10 Aug '21

---------- Forwarded message --------- From: Phyllis Smith <phylsmith2017(a)gmail.com> Date: Mon, Aug 9, 2021 at 4:41 PM Subject: Re: variable fast/slow playback speed hack To: Andrew Randrianasulu <randrianasulu(a)gmail.com> hm, I think (!) those mostly links to same slightly redefined object. But > may be I missed something too ( probably more testing needed.. but I guess > if we put this patch in git and it will break something we always can > revert? > OK. > > also, in Cinelerra_rc there is scrub_speed variable already, may be it > related to (default) shuttle scrubbing speed (can you test when you have > time? ) > > SAMPLERATE 48000 > SCRUB_SPEED 2.000000e+00 > ... > may be it was commented out because you can have variable speed with this > device anyway? > Not sure what it is BUT it is not related to the shuttle because it is in the original HV code and that code had no shuttle and I am not even sure that the shuttle existed back then. I will try to see if I can figure out what it is for but it also may be lost to the sands of time.

1 0

arm/disarm track confusion
by Andrew Randrianasulu 09 Aug '21

09 Aug '21

>From quick search I found some confusing references how this feature might behave: === Arm track determines whether the track is armed or not. Only the armed tracks are affected by editing operations. Make sure you have enough armed destination tracks when you paste or splice material or some tracks in the material will get left out. In addition to restricting editing operations, the armed tracks in combination with the active region determine where material is inserted when loading files. If the files are loaded with one of the insertion strategies which doesn't delete the existing project, the armed tracks will be used as destination tracks. Press Tab while the cursor is anywhere over a track to toggle the track arming status. Press Shift-Tab while the cursor is over a track to toggle the arming status of every other track. === from http://heroinewarrior.com/cinelerra/cinelerra.html how you can wonder if _attach effect_ is editing operation or not... https://www.cinelerra-gg.org/bugtracker/view.php?id=433 from what I read so far main worry was about _moving_ pieces of media on tracks around, not effect insert per se. I also suspect such strange/uncommon system of working with audio partially comes from broadcast2000 times (you can find image of it with two 5.1 tracks from dvd!). mono/stereo is easy and most commonly used. But 5.1 and higher exist, and obviously more complex to work with. === Make sure all the tracks are “armed” – that is, each of the “Arm track” icons next to the track are highlighted. Until a track is armed, you are mostly unable to edit that track. === from https://www.calcmaster.net/cinelerra/forgotten-guide/04-media-to-tracks/ {probably copy/paste from cv and earlier manuals..} *mostly* unable to edit this track is interesting statement.... https://cinelerra.skolelinux.narkive.com/YlRvb3Hu/cincvs-cinelerra-on-ubuntu "edit actions manipulate /all/ clips on all armed tracks" - from 2006... so it seems it was _not quite_ lock track behavior... and finally article from 2010.. I think CinGG fixed most/all of most problematic points.. === Stuff it does that I'm indifferent to So there's also some stuff that's different, that I don't love and don't hate: - "Arming" tracks. By default, all tracks are "armed". This means that the little red button next to them is highlighted and you can affect those tracks with editing decisions. If you're inserting stuff then the highest level track that's armed is where the clip ends up. If you're deleting, trimming, highlighting, adding effects, etc., then your decisions apply to ALL ARMED TRACKS. Which gets real confusing real fast when you realise you've accidentally cut three seconds out of your audio track or put an effect on a track you didn't mean too, or trimmed the wrong clip. It's VERY IMPORTANT to only arm the tracks you're using at that time. Usually just one at a time unless you're moving a clip from one track to another. There are times when this is very useful, like if I do have two adjacent clips on different tracks and want to nudge them both back or forward without losing their adjacency. Or if you want to make sure more than one track fades out at exactly the same time, or has the exact same effect (including keyframes) applied. But also it is often confusing. I often have more tracks than I can comfortably see in the size of the timeline window that I'm comfortable using. If I forget what I'm doing, I might accidentally screw up another track and then I have to go find where how and what the hell I've done after I've rendered it all screwed up. I don't hate this method. Because when I do remember what I'm doing (which is most of the time), it really does help make sure that tracks you aren't currently using are "safe" from getting screwed up. You can lock things down tight. But equally I'm not in love with it. === from https://beccatoria.dreamwidth.org/111857.html?thread=1540337&style=site Have fun!

3 7