- Cin - Cinelerra-GG Mailing Lists

small patch for termux_dyn.bld
by Andrew Randrianasulu 06 Nov '22

06 Nov '22

adds --with-clang there too, so dyn build also less noisy

2 2

cineformHD encoding profile
by Andrew Randrianasulu 06 Nov '22

06 Nov '22

Because Olive offers it, should be in ffmpeg since 4.4

2 1

Re: [Cin] Cingg'divide mode, very divisive!
by Andrew Randrianasulu 06 Nov '22

06 Nov '22

вс, 6 нояб. 2022 г., 00:52 Igor Vladimirsky <sitelve(a)gmail.com>: > > > ср, 2 нояб. 2022 г. в 12:53, Andrew Randrianasulu <randrianasulu(a)gmail.com > >: > >> So, as Igor noticed CinGG's divide and subtract modes do not behave like >> they behaved in Cin HV/CV/CVE I digged into matter a bit and found few >> confusing (for me, amateur) things...... >> > But moreover, according to documentation CinGG composites tracks a bit >> backward comparing to photo editors: >> >> > I found this in my archive. > Very cool, thanks! So, for your specific preferences does inverting S and D in overlayframe.h for subtract and divide return familiar behavior, especially with huge use of reroute/inversion? I do not think making it new default unconditionally will be good, because some modes compositing this way and some - that way add too much confusion, but a) you can use personal patch and hopefully b) I'll find some way to make this behavior configurable .... In 2016, I asked GoodGuy about the Divide blend mode. > I showed him a quote from from Changelog 2.1 > https://github.com/cinelerra-cv-team/cinelerra-cv/blob/master/cinelerra/CHA… > Quote:*" For overlaying, divide behavior is the same as the Gimp.* > New overlaying algorithm: Max takes the maximum r, g, and b values." > > *GG's answer:* > *------------------------------------* > > > > > > > > > > > > > *"This is the math form Gimp currently uses:STD_BLEND + (Sa == 0.0 || Dc / > Sc > Da / Sa ? Sa * Da : Dc * Sa * Sa / Sc)HV 4.6.1 (and CV) actually > uses:(Sc > 0 ? Dc / Sc : 1)Cin5 actually uses:(Dc > 0 ? Sc / Dc : 0)So, > none of these look like Gimp. But Divide is a bit squirrelly. It can fail > on a per pixel basis because of divide by zero. I prefer src (top track) / > dst (btm track) with divide by zero as black (not white). I think this is > the way most would like to see it work, since it is a stack of operations, > and it easier to work up from zero, than down from 1."* > *---------------------------------------* > > ---------------------------------------- > > This is from CGG'code > Cinelerra-GG > // DIVIDE [Sa + Da - Sa*Da, Sc*(1 - Da) + Dc*(1 - Sa) + Sc / Dc] > // SUBTRACT [(Sa - Da), (Sc - Dc)] > > > But in HV and CV*, the Subtract and Divide blend modes work the same way > as GIMP, Photoshop, Adobe Premiere Pro, EDIUS > > *GIMP* > Divide mode multiplies each pixel value in the lower layer by 256 and then > divides that by the corresponding pixel value of the upper layer plus one. > Subtract mode subtracts the pixel values of the upper layer from the pixel > values of the lower layer. > > *Photoshop* > https://photoblogstop.com/photoshop/photoshop-blend-modes-explained > Divide > Background layer ÷ Active layer = Quotient > Subtract > B minus A > > *Adobe Premiere Pro* > https://helpx.adobe.com/premiere-pro/using/blending-modes.html > Divide > Divides underlying color by source color. If the source color is white, > the result color is the underlying color. Result color values can be > greater than 1.0 in 32-bpc projects. > Subtract > Subtracts the source file from the underlying color. If the source color > is black, the result color is the underlying color. Result color values can > be less than 0 in 32-bpc project > > *EDIUS *(quote from its manual) > Subtract > Subtracts the overlay color values from the background. >

1 0

Overlay (effect) section need some work too?
by Andrew Randrianasulu 05 Nov '22

05 Nov '22

https://cinelerra-gg.org/download/CinelerraGG_Manual/Overlay_Video.html#121… right now we have here === The overlay plugin enables the use of this Overlayer device in the middle of any plugin stack, opening endless filtering and processing possibilities. It is only useful as a shared plugin (i.e. a multitrack plugin). To use the overlay plugin: 1. Add the effect to Track A. 2. Choose attach effect from the context menu of another track (Track B). 3. Choose Track A: Overlay as a shared plugin. 4. Manipulate the plugin parameters in Track A. ==== but in pdf doc I see this paragraph: In the Overlay Plugin’s parameter window you can choose the overlay order, i.e. which track plays the role of the "bottom layer" and which plays the role of the "top layer". For some overlay modes, this can make quite a difference, e.g. the top layer is subtracted from the bottom layer for "Subtractive" mode. Further on, you can choose on which of the tracks to overlay the combined output. (Hint: in most cases, you will want to mute the other track and only retain this combined output). +++++ /storage/emulated/0/Download/cinelerracvmanualen.683533262.pdf downloaded from https://usermanual.wiki/Document/cinelerracvmanualen.683533262/view while manual claims to be same 1.63 en version I do not see this paragraph in wiki? Because some illustrations there from cin 1.x era may be this tail was lost during editing?

2 1

Fwd: cingg manual update on overlay plugin
by Andrew Randrianasulu 05 Nov '22

05 Nov '22

I hope I not messed up (file builds locally into pdf) I put "bottom layer" in quotes because it in fact configurable. Text copied from cin-cv manual (I was looking under wrong section, overlay ( audio ) plugin, not overlay (video) plugin) ---------- Forwarded message --------- От: Андрей Рандрианасулу <randrik(a)mail.ru> Date: пт, 4 нояб. 2022 г., 18:56 Subject: cingg manual update on overlay plugin To: randrianasulu <randrianasulu(a)gmail.com> -- Андрей Рандрианасулу

2 1

HW accel seems broken to me on AMD laptop
by Андрей Спицын 04 Nov '22

04 Nov '22

HI, I try to set up hw accel decoding for AMD laptop, but if I enable vaapi or vdpau I see a 'file not found' error. Hw accel works OK for the rest of the software. I unpacked appimage and removed boundled libvdpau.so, this results in working hwaccel via vdpau. The same with if I start cinelerra with the LD_PRELOAD environment variable. Maybe this library should be excluded from the appimage bundle? Best regards, Andrey

3 5

Re: [Cin] Cinelerra CV direct copy feature demo
by Terje J. Hanssen 04 Nov '22

04 Nov '22

On Fri Oct 28 02:35:53 CEST 2022, Andrew Randrianasulu wrote: > > Recorded with Cin-GG :-) > > https://youtu.be/7pXG5cnjckQ > 5min or so .... I put in an extract of section 20.5 of the CinCV manual here: http://cinelerra-cv.wikidot.com/cincv-manual-en:rendering-files Most of the time you will want to bring in the rendered output and fine tune the timing on the timeline. Also some file formats like MPEG can not be direct copied. Because of this, the jobs are left in individual files. You can load these by creating a new track and specifying concatenate to existing tracks in the load dialog. Files which support direct copy can be concatenated into a single file by rendering to the same file format with renderfarm disabled. Also to get direct copy, the track dimensions, output dimensions, and asset dimensions must be equal. MPEG files or files which do not support direct copy have to be concatenated with a command line utility. MPEG files can be concatenated with cat. By reading the parallell email thread "[Cin] fileexr/fileppm direct copy support", I wonder if this isn't equivalent to some other NLE's "Smart Rendering" or "by-pass re-encode/compression when possible"? If so it would be fine to get this dealed with in the CinGG manual ....? https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=157600 https://www.kevinmonahan.net/?p=88 And maybe also another CinGG theme "HDV on a Blu-ray without re-encode" as discussed earlier, is related and needs some manual update? https://cinelerra-gg.org/download/CinelerraGG_Manual/HDV_on_Blu_ray_Disc_Wi… https://www.mail-archive.com/[email protected]/msg03520.html

3 6

HDV manual section need some work
by Andrew Randrianasulu 03 Nov '22

03 Nov '22

I think we can add some clarification --- HDV on a Blu-ray Disc Without Re-encoding An MTS file is a video file saved in the high-definition (HD) MPEG Transport Stream video format, commonly called AVCHD. It contains HD video compatible with Blu-ray disc format and is based on the MPEG-2 transport stream. MTS files are often used by Sony, Panasonic, Canon and other HD camcorders. Legal input for Video – MPEG1VIDEO, MPEG2VIDEO, H264; Audio – MP1, MP2, AC3, AC3PLUS, DTS, TRUHD. Note, mp2 and mp1 audio codecs are valid for transport stream itself but not as on-disk format for Blu-Rays. In this case you still can save original video by using ffmpeg's switches -c:v copy -c:a ac3 , while outputting into another temporal ts container. {waiting for Terje's results on pcm_bluray case} --- I think all m2ts files you used for testing were h264/aac (or ac3), not from-camcoder HDVs with mpeg2 video/mp2 audio. you can try HDV-in-mov from this folder as ffmpeg test file, I think http://samples.mplayerhq.hu/mov/FCP/ ---- For creating a blu-ray disc, if you have HDV MPEG-2 media that is in blu-ray format, you can save the original quality of your work, rather than rendering it to another format. {I hope Terje will let us know if bdwrite still works with bluray pcm audio as produced by ffmpeg 5.1+}

2 3

Re: [Cin] Cinelerra CV direct copy feature demo
by Andrew Randrianasulu 03 Nov '22

03 Nov '22

чт, 3 нояб. 2022 г., 01:58 Terje J. Hanssen <terjejhanssen(a)gmail.com>: > > > Den 02.11.2022 20:28, skrev Andrew Randrianasulu: > > > > ср, 2 нояб. 2022 г., 19:19 Andrew Randrianasulu <randrianasulu(a)gmail.com>: > >> >> >> ср, 2 нояб. 2022 г., 17:59 Terje J. Hanssen <terjejhanssen(a)gmail.com>: >> >>> >>> On Fri Oct 28 02:35:53 CEST 2022, Andrew Randrianasulu wrote: >>> >>> >>> Recorded with Cin-GG :-) >>> >>> https://youtu.be/7pXG5cnjckQ >>> 5min or so .... >>> >>> >>> I put in an extract of section 20.5 of the CinCV manual here: >>> http://cinelerra-cv.wikidot.com/cincv-manual-en:rendering-files >>> >>> Most of the time you will want to bring in the rendered output and fine >>> tune the timing on the timeline. Also some file formats like MPEG can not >>> be direct copied. Because of this, the jobs are left in individual files. >>> >>> You can load these by creating a new track and specifying concatenate to >>> existing tracks in the load dialog. Files which support direct copy can be >>> concatenated into a single file by rendering to the same file format with >>> renderfarm disabled. Also to get direct copy, the track dimensions, output >>> dimensions, and asset dimensions must be equal. >>> >>> MPEG files or files which do not support direct copy have to be >>> concatenated with a command line utility. MPEG files can be concatenated >>> with cat. >>> >>> By reading the parallell email thread "[Cin] fileexr/fileppm direct copy >>> support", I wonder if this isn't equivalent to some other NLE's "Smart >>> Rendering" or "by-pass re-encode/compression when possible"? >>> >> >> >> partially, but sadly not (yet) smart enough for dealing with non-i-only >> files ... >> >> there was interesting piece of code potentially decompressing anything >> ffmpeg can decode in fileyuv in CinCV, but this need some encoding >> counterpart and also more info passing between assets, edits and >> renderer.... >> >> >> >> https://github.com/cinelerra-cv-team/cinelerra-cv/commit/0ff51f4c53e17ff337… >> >> >> If so it would be fine to get this dealed with in the CinGG manual ....? >>> >> >> >> >> CinGG as for now accelerates _image sequences_ in this way, due to our >> de/muxer moved from dedicated libquicktime-based filemov.c into more >> complete but complex ffmpeg.c's libavformat de/muxer. >> >> >> so, no hdv copy in this mode yet (at least automatic) >> May be you can rig avidemux or ffprobe for noting hdv keyframes and set >> cuts in cin on those boundaries, but this is time-consuming.... >> > > > There is also another program, "VideoCut" Version 2.1.1 - MP2/MP4 Cutter > for Linux on base of mpv and ffmpeg. Cutting is lossless, the target file > will not be reencoded. > https://github.com/kanehekili/VideoCut > > > > >> https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=157600 >>> https://www.kevinmonahan.net/?p=88 >>> >> >> >> thanks for links, will look into them. >> >>> >>> >>> And maybe also another CinGG theme "HDV on a Blu-ray without re-encode" >>> as discussed earlier, is related and needs some manual update? >>> >>> https://cinelerra-gg.org/download/CinelerraGG_Manual/HDV_on_Blu_ray_Disc_Wi… >>> >> > > this one not dealing with cutting your footage, just author disk with > bdwrite :) > > > Yeah, I see that. > But as we concluded, the manual section needs update, both on the HDV > definition, and adding the procedures to transcode and remux HDV mp2 audio > into a Bluray compliant format. > since those times some progress was made in ffmpeg in bluray pcm audio. Can you try -c:a pcm_bluray in latest ffmpeg 5.1, with some-hdv-file as input ? c:v copy for video, obviously ... and tsmuxer for final mux/author.... biggest problem (for now) is lack of testing hardware, I mean picky hw players .... Also, may be Phyllis a bit lost in all those threads, so posting separate mail with your suggestions for manual section might help? full ffmpeg/mediainfo output probably not needed but some tricky options or un-intuitive switches better to be documented. In simplest case it probably will be as simple as ffmpeg -i file.mts -c:v copy -c:a pcm_bluray output.ts and then using tsmuxer template for cmd line or in gui for remuxing this ts into bd folder or directly into iso (actually udf) or try new bdwrite too (exactly like described in manual) and see if it authors disk playable on your hardware. then we hopefully can update manual text and move into lossless cutting matters ) https://www.mail-archive.com/[email protected]/msg03521.html > > > > for cutting without reencoding you probably should test some ideas > discussed in > > https://github.com/mifi/lossless-cut/pull/13 > > namely order of ffmpeg params and also > '-avoid_negative_ts', 'make_zero' params. > > So, theory of operation you scan your media with ffprobe and it produces > list of timecodes where you *can* cut files safely. Then you can probably > output your cut-only edit as edl from Cinelerra and use it as input for > ffmpeg-based script doing cuts, with some math inside considering that > portions you can copy and that need reencoding. > > https://github.com/mifi/lossless-cut/pull/13#issuecomment-279226516 > > But for this to works ffmpeg-based cutter should be accurate nearly always > ...so testing on real HDV files (often hours long) very much needed (you > can put your source files on r/o mounted fs just for avoiding bad > surprises with ffmpeg output). > > usual bad surprises include blank frames, bad/no play, sound > desynchronysing ....not something you hoped for while wishing for > -lossless- cut. > > One can ask why bothering with NLE? well, timecode display and > bidirectional framestepping .... > > >>> https://www.mail-archive.com/[email protected]/msg03520.html >>> >> > also IgorV recently rediscovered some scripts from old times, some of them > hope to produces avchd disks as readable by Sony's PS3 for example (they > used closed-source tsmuxer, but i hope opensource version works for now) > > > https://github.com/IgorVladimirsky/cinelerra-scripts-from-code.google.com/b… > > > > those scripts reencode, so not very topical for cutting but might be > interesting evening read anyway. > > > https://github.com/IgorVladimirsky/cinelerra-scripts-from-code.google.com/b… > > make_m2ts_avchd_dvd function namely > > > > >>> >> As far as I understand problem for mpeg like codecs you must re-encode >> not just frames you altered, but also frames between your cut and >> codec-defined input keyframes, and this kind of info simply not wired >> inside cinelerra .... I'll try to download ffprobe-based I-frames finder as >> prototyped by Bill long time ago and play with its output as guidance for >> cutting mpeg2 like streams >> >> >> but just for unexpected side of video decoding at some time Natron >> apparently had weird reordering problem on reading mp4 files, probably due >> to in-decoder reordering ...some fun (eh) to code for ... >> >> https://github.com/NatronGitHub/Natron/issues/555 >> >> >>> >

1 0

Re: [Cin] Cingg'divide mode, very divisive!
by Andrew Randrianasulu 03 Nov '22

03 Nov '22

ср, 2 нояб. 2022 г., 22:06 Einar Rünkaru <einarrunkaru(a)gmail.com>: > > > On 02/11/2022 14:53, Andrew Randrianasulu wrote: > > So, as Igor noticed CinGG's divide and subtract modes do not behave like > > they behaved in Cin HV/CV/CVE I digged into matter a bit and found few > > confusing (for me, amateur) things. > > I replaced the original Overlayer with new version created by Monty in > CVE and CVO. May be GG did not replace. This explains the differences. > well, as far as I understand in cingg part of overlayer logic was pushed into python script generating C files .... but thankfully equations for pixel processing remained in .h file. python thing: https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerr… I guess it was a bit boring to write all those new functions by hand ..... but again, I suspect we have not just single bug but at least few related changes in how compositing performed. (for example simple grey template with some pure black squares composites in CinCV with itself just fine, I mean if you have just one track with this file set to divide mode. Yet CinGG shows black output. I guess it was intentional, because others non-photo compositors behave like this (I got plenty of black output playing with Final Cut Pro 2.0 compositing modes - they had subtract but not divide, and I got similar {but not identical} results by flipping order of tracks in cingg, using same input media files) ) if you can provide Igor with some ideas how to turn equation I linked into pixel-processing macro insertable into cingg - I think he will be very happy even if we here not yet decided what really broken and how to fix this. I used to run my kernel with patch deemed too unsafe for official kernel, but it was working acceptably for me. So, having patch or two fixing unwanted upstream behavior is not crime, just that maintaining growing list of such patches become task in itself over time .... > Einar > >

1 0