- Cin - Cinelerra-GG Mailing Lists

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 03 Nov '22

03 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/cin@lists.cinelerra-gg.org/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 02 Nov '22

02 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/cin@lists.cinelerra-gg.org/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/cin@lists.cinelerra-gg.org/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 02 Nov '22

02 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

ffprobe cutter
by Andrew Randrianasulu 02 Nov '22

02 Nov '22

Sadly kfrm.sh just displayed if frame was keyframe or not, without timestamps but this forum post provided some ideas https://forum.videohelp.com/threads/359491-Just-an-idea-ffmpeg-based-key-fr… ~ $ ffprobe -hide_banner -skip_frame nokey -show_frames -select_streams v 20200101_000443A.mp4 | grep best_effort Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '20200101_000443A.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 Duration: 00:00:13.27, start: 0.000000, bitrate: 23664 kb/s Stream #0:0[0x1](eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt470bg/bt470bg/smpte170m, progressive), 3840x2160, 23087 kb/s, 30.08 fps, 30 tbr, 1k tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 2 kb/s (default) Metadata: handler_name : SoundHandler vendor_id : [0][0][0][0] best_effort_timestamp=0 best_effort_timestamp_time=0.000000 best_effort_timestamp=1433 best_effort_timestamp_time=1.433000 best_effort_timestamp=2799 best_effort_timestamp_time=2.799000 best_effort_timestamp=4166 best_effort_timestamp_time=4.166000 best_effort_timestamp=5533 best_effort_timestamp_time=5.533000 best_effort_timestamp=6899 best_effort_timestamp_time=6.899000 best_effort_timestamp=8266 best_effort_timestamp_time=8.266000 best_effort_timestamp=9633 best_effort_timestamp_time=9.633000 best_effort_timestamp=10999 best_effort_timestamp_time=10.999000 best_effort_timestamp=12366 best_effort_timestamp_time=12.366000 ~ $ so it gives you some timelist ... turning it into cut-friendly format probably was done somehow )

1 0

Fwd: divide in Natron
by Andrew Randrianasulu 01 Nov '22

01 Nov '22

for some reason divide in cingg looks exactly like divide operation in Natron .. may be it was intentional? ---------- Forwarded message --------- От: Андрей Рандрианасулу <randrik(a)mail.ru> Date: вт, 1 нояб. 2022 г., 12:46 Subject: divide in Natron To: randrianasulu <randrianasulu(a)gmail.com> -- Андрей Рандрианасулу

1 0

bld_prepare.sh and ubuntu-testing
by Andrew Randrianasulu 30 Oct '22

30 Oct '22

It was reported that additional packages needed for successful cingg compilation: "libxml-parser-perl libimath-dev liblilv-dev" src: https://www.linux.org.ru/forum/linux-hardware/16959253?cid=17015026

3 4

Fwd: cingg vs gimp 2.10 compositing mode divide
by Andrew Randrianasulu 30 Oct '22

30 Oct '22

but should we blindly follow gimp ? Again, gimp tend to have bigger mode list ) may be right thing to do is leave some of our modes intact (they might be buggy but graphics art can utilize that, too) and add gimp/svg/oldcin compatible modes ? ---------- Forwarded message --------- От: Андрей Рандрианасулу <randrik(a)mail.ru> Date: сб, 29 окт. 2022 г., 18:43 Subject: cingg vs gimp 2.10 compositing mode divide To: randrianasulu <randrianasulu(a)gmail.com> I think you see, we are making black areas where gimp was making white areas... -- Андрей Рандрианасулу

2 3

Fwd: natron compositing modes
by Andrew Randrianasulu 30 Oct '22

30 Oct '22

for some reason I am confused. (again!) There is A as ARGB and there is a as alpha! ---------- Forwarded message --------- От: Андрей Рандрианасулу <randrik(a)mail.ru> Date: вс, 30 окт. 2022 г., 14:36 Subject: natron compositing modes To: randrianasulu <randrianasulu(a)gmail.com> a lot of them .. -- Андрей Рандрианасулу

1 3