- Cin - Cinelerra-GG Mailing Lists

New Opus audio codec
by Andrea paz 05 Mar '24

05 Mar '24

AVX2 and Machine Learning in the new release of Opus audio codec: https://opus-codec.org/

2 1

ot: intel_pstate
by Andrew Randrianasulu 03 Mar '24

03 Mar '24

My laptop was making noises under load, and sadly trayfreq was unable to set cpu frequency for some reason. I poked around /sys and found intel_pstate driver can be configured this way: echo 25 > /sys/devices/system/cpu/intel_pstate/max_perf_pct this sets max frequency to 800 mhz instead of 2.5/3.0 ghz as usual. note that 25 is percentage, and on different core iXXX processors results can be different. inxi CPU: dual core Intel Core i5-2450M (-MT MCP-) speed/min/max: 798/800/3100 MHz Kernel: 5.6.14-x64 x86_64 Up: 27d 14m Mem: 2453.5/5887.8 MiB (41.7%) Storage: 610.63 GiB (76.4% used) Procs: 227 Shell: Bash inxi: 3.3.12 I hope this might help Phyllis with her overheating intel laptop .....

3 3

Fwd: Chromakey + blur testcase from IgorV
by Andrew Randrianasulu 27 Feb '24

27 Feb '24

---------- Forwarded message --------- From: Andrew Randrianasulu <randrianasulu(a)gmail.com> Date: Thu, Feb 22, 2024 at 2:19 AM Subject: Chromakey + blur testcase from IgorV To: Phyllis Smith <phylsmith2017(a)gmail.com> oh, it weights 1.4 mb, so not for list ... I think swapping effects relative to cin-cv makes image in compositor more like it was supposed to be but still. even if I disable chromakey - blur behaves strange, like rounding unprocessed (processed as black?) transparency into image ..? ===== https://drive.google.com/file/d/1kqt4bfy53drwQqOvD5RIJ1E7UWeJNF1A/view?usp=… hopefully uploaded to gdrive for everyone to test/see ....

4 20

disable a_key in blur.C harder
by Andrew Randrianasulu 26 Feb '24

26 Feb '24

At this point I am not sure if best course of action to disable it harder or restore it ... but I hope attached patch at least visually restores strange mess we see by default now in test project.

1 0

Ghosts from the shell!
by Andrew Randrianasulu 23 Feb '24

23 Feb '24

IgorV pointed out that while our manual still describes multiple projector keyframes/boxes in compositor it doesn't (reliably?) work this way, namely I think I created second box somehow but can't reproduce :) https://cinelerra-gg.org/download/CinelerraGG_Manual/Compositor_Keyframes.h… "Move the projector slightly in the compositor window to create a keyframe. Then go forward several seconds. Move the projector a long distance to create another keyframe and emphasize motion. This creates a second projector box in the compositor, with a line joining the two boxes. The joining line is the motion path. If you create more keyframes, more boxes are created. Once all the desired keyframes are created, disable automatic keyframe mode." small video describing how it worked in cinelerra-cv 1.2.1 using old dynebolic 1.4 iso https://m.youtube.com/watch?v=08UCImr82CE I wonder how "long" must be long distance? offscreen? tried this, also with enlarged projector range .... no two boxes! I can't even see this behavior in cincv 2.3.* from 2017, but may be I am doing it wrong for all versions?

3 5

Possibly better conversion quality at 2x speed/ bitrate and 25fps/ 50 fps
by Terje J. Hanssen 20 Feb '24

20 Feb '24

Thirty years ago I tape recordered some hundreds of old genealogy photos, which I now plan to convert from SD-DV files to burn on DVD video discs. The camcordings were made with fade in/out, zoom closeups and pan effects, which fit well at 2x playback speed and with additional pause/play navigation on DVD videos. Signal/noise at 2x speed with same fps and bitrate (halph of the fps are dropped), should result in output with 1/2 playback duration and equivalent quality as normal speed. Yet I wonder if it possible in some way to achieve better quality if also 2x bitrate and fps are possible to utilize temporarily as a better quality base (downsampling), even if DVD video limits the fps and bitrate? Here are my test samples so far: du -sh dv95* 1) 2,0G dv95.dv (input source) 2) 1,1G dv95_2x_25fps.dv 3) 2,0G dv95_2x_50fps.dv 4) 218M dv95_2x_25fps.mpg 5) 218M dv95_2x_50fps.mpg 1) ffprobe -hide_banner dv95.dv (source DV, Duration: 00:09:56.48) [dv @ 0x55d65d6ca080] Estimating duration from bitrate, this may be inaccurate Input #0, dv, from 'dv95.dv': Metadata: timecode : 00:00:00:00 Duration: 00:09:56.48, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 28800 kb/s, 60k fps, 25 tbr, 60k tbn Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s ffmpeg conversions using the FFmpeg setpts filter http://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20v… 2) ffmpeg -i dv95.dv -vf "setpts=0.5*PTS" -an dv95_2x_25fps.dv ffprobe -hide_banner dv95_2x_25fps.dv [dv @ 0x5582eb685080] Estimating duration from bitrate, this may be inaccurate Input #0, dv, from 'dv95_2x_25fps.dv': Metadata: timecode : 00:00:00:00 Duration: 00:04:58.32, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 28800 kb/s, 60k fps, 25 tbr, 60k tbn 3) I wonder why the Duration is still 00:09:56.52 here ? ffmpeg -hide_banner -i dv95.dv -r 50 -vf "setpts=0.5*PTS" -an dv95_2x_50fps.dv ffprobe -hide_banner dv95_2x_50fps.dv [dv @ 0x55fe0b5bb080] Estimating duration from bitrate, this may be inaccurate Input #0, dv, from 'dv95_2x_50fps.dv': Metadata: timecode : 00:00:00:00 Duration: 00:09:56.52, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 28800 kb/s, 60k fps, 25 tbr, 60k tbn 4) ffmpeg -hide_banner -i dv95.dv -f dvd -target pal-dvd -aspect 4:3 -vf "setpts=0.5*PTS" -an dv95_2x_25fps.mpg ffprobe -hide_banner dv95_2x_25fps.mpg [mpeg @ 0x55a330208080] start time for stream 0 is not set in estimate_timings_from_pts Input #0, mpeg, from 'dv95_2x_25fps.mpg': Duration: 00:04:58.32, start: 0.540000, bitrate: 6115 kb/s Stream #0:0[0x1bf]: Data: dvd_nav_packet Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, progressive), 720x576 [SAR 16:15 DAR 4:3], 25 fps, 25 tbr, 90k tbn Side data: cpb: bitrate max/min/avg: 9000000/0/0 buffer size: 1835008 vbv_delay: N/A Unsupported codec with id 98312 for input stream 0 5) ffmpeg -hide_banner -i dv95.dv -f dvd -target pal-dvd -r 50 -vf "setpts=0.5*PTS" -an dv95_2x_50fps.mpg ffprobe -hide_banner dv95_2x_50fps.mpg [mpeg @ 0x555e13da2080] start time for stream 0 is not set in estimate_timings_from_pts Input #0, mpeg, from 'dv95_2x_50fps.mpg': Duration: 00:04:58.26, start: 0.520000, bitrate: 6118 kb/s Stream #0:0[0x1bf]: Data: dvd_nav_packet Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, progressive), 720x576 [SAR 16:15 DAR 4:3], 50 fps, 50 tbr, 90k tbn Side data: cpb: bitrate max/min/avg: 9000000/0/0 buffer size: 1835008 vbv_delay: N/A Unsupported codec with id 98312 for input stream 0

2 2

DAR, PAR and SAR, again
by Andrea paz 17 Feb '24

17 Feb '24

I am opening a new post because the previous one, for me, was becoming too confusing. I quote Terje's latest email: ============================================================== Well, I have prioritized more to understand what happends than interprete the somewhat ambiguous definitions. (the order of the factors is indifferent). https://stackoverflow.com/questions/18877243/why-ffmpeg-print-sar-instead-o… I think of SAR in the FFmpeg output as a correction factor for the recordered picture frame format resolution (Wp), to get the desired output display resolution (expanded Wd with square px) at a given DAR, (or in opposite order). I found a useful table at ffmpeg-user that contains information for practically all SD and HD video formats. Maybe something for the manual? https://www.mail-archive.com/[email protected]/msg27522.html display DAR picture PAR SAR = DAR/PAR =========== ==== =========== ==== ===== 16:9-2160: 3840 x 2160 16:9 : 3840 x 2160 16:9 : 1:1 4:3-2160: 2880 x 2160 4:3 : 2880 x 2160 4:3 : 1:1 16:9-1080: 1920 x 1080 16:9 : 1920 x 1080 16:9 : 1:1 4:3-1080: 1440 x 1080 4:3 : 1440 x 1080 4:3 : 1:1 16:9-576: 1024 x 576 16:9 : 720 x 576 5:4 : 64:45 4:3-576: 768 x 576 4:3 : 720 x 576 5:4 : 16:15 16:9-480: 853 x 480 16:9 : 720 x 480 3:2 : 32:27 4:3-480: 640 x 480 4:3 : 720 x 480 3:2 : 8:9 [...] =========================================================== My God, I feel like giving up.... The following is my opinion (indeed, my delirium!). The table is wrong (for ffmpeg!) because it uses PAR. As is also stated in the thread you cited: "> PAR (picture aspect ratio [1]) [noun]: 1, The horizontal-to-vertical > size [3] ratio (H:V, e.g. 5:4, 3:2) for pictures. get rid of this one altogether, because nothing in FFmpeg use it, and rightly, because nobody should use it." Instead of calling it PAR, it should be considered simply the aspect ratio of W x H of the input. That is, the W/H of the formula DAR=W/H x SAR (and not DAR=PAR x SAR). PAR and SAR cannot be different since they are the same thing (i.e. the shape of a single pixel, as seen from the image https://stackoverflow.com/questions/18877243/why-ffmpeg-print-sar-instead-o… that you mentioned). In practice, in my opinion, the PAR in the table is nothing more than the SAR meant as Storage aspect ratio; in fact, the author of the table defines it as a Picture aspect ratio, which is a frame aspect ratio and not a pixel aspect ratio. It seems to me that in an effort to be precise, it creates even more confusion. Instead, the SAR in the table is nothing more than the S(ample)AR ( = P(ixel)AR). If you think I am crazy to keep up with these definitions, you are right! The formula DAR = PAR x SAR was convenient and simple, however, ffmpeg decided to use "samples" instead of pixels and so PAR should no longer be used. That is why I was thinking of removing all reference to PAR. The trouble is that if one searches around one always finds PAR and never SAR meant as "sample a.r."; including many tutorials on ffmpeg. The sample concept is derived from analog video signals and is encoded in the standards BT. 601 and Digital. It refers to horizontal scan lines (in MHz) and not simply pixels. From Wikipedia: "analog video does not have pixels, but rather a raster scan, and thus has a well-defined vertical resolution (the lines of the raster), but not a well-defined horizontal resolution, since each line is an analog signal." S(ample)AR was created precisely to adapt the analog concept to the digital world. To further explore the concept of sample: https://web.archive.org/web/20140816103129/http://lipas.uwasa.fi/~f76998/vi… Your definition of SAR as a correction factor is right and I will use it in txt. Thank you for the cue. To summarize: in the digital domain we can use the concept of S(ample)AR when we are dealing with digital anamorphic formats (for example, when transcoding to a format that has different aspect ratio). But the most frequent use is in "standard-definition television or with DV, HDV and a few other formats. SAR is used via the formula DAR = SAR x (W/H), where SAR is the conversion factor between anamorphic Input and Output. Perhaps the clearest treatment is as follows: https://encodingwissen.de/hintergrund/videobild/anamorph/itu-r-bt601/ It is in German and therefore needs to be translated (the Italian translation is not very good...). They seem to me to be similar concepts to Raffaella Traniello's guide. As an additional (my) confusion, in CinGG we also have the W/H Ratio parameters, which are simple multipliers but, if set only one of them (with values of the classic aspect ratios, 4:3; 16:9, etc.) and leaving the other one at 1, they act as a real SAR even though they are not... @Andrew In CinGG/Info-->Detail is the data reported taken using ffmpeg? In other words: does CinGG use SAR like ffmpeg or does it have an even different way? PS: In my opinion, it would be better to change W/H Ratio to "W/H multiplier"

5 49

binary repo for cin-hv
by Andrew Randrianasulu 16 Feb '24

16 Feb '24

https://github.com/heroineworshiper/hvirtual_bin supposedly we have some bugs in chromakeyer (or more accurately not all functionality was implemented correctly) so it might be interesting to see how it was supposed to work also, previews in file loading dialog! reported to work on ubuntu 18.04/x86_64 via https://www.linux.org.ru/forum/multimedia/17521951

2 3

Re: [Cin] Another attempt at patching cin-hv sources so they build on my system
by Andrew Randrianasulu 16 Feb '24

16 Feb '24

On Fri, Feb 16, 2024 at 1:25 PM Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > On Fri, Feb 16, 2024 at 12:58 PM Andrew Randrianasulu > <randrianasulu(a)gmail.com> wrote: > > > > On Fri, Feb 16, 2024 at 11:37 AM Andrew Randrianasulu > > <randrianasulu(a)gmail.com> wrote: > > > > > > On Fri, Feb 16, 2024 at 9:53 AM Andrew Randrianasulu > > > <randrianasulu(a)gmail.com> wrote: > > > > > > > > On Fri, Feb 16, 2024 at 10:00 AM Adam williams <broadcast(a)earthling.net> wrote: > > > > > > > > > > Haven't had enough time to finish & integrate your work. Please submit a working build log on ubuntu 16-22 & explain why you're trying to build without filefork support. > > > > > > > > It was function linker was unable to find (for some reason) > > > > > > > > right now after those steps in hvirtual root (on chrooted Rosa 2016 > > > > system - gcc 5.5.0) > > > > > > > > make clean twice > > > > > > > > git clean -fdx {removes all untracked files} > > > > > > > > git reset --hard > > > > HEAD is now at 400dcf62 Greater less typo > > > > > > > > configure fails at sndfile step > > > > > > ah, probably just artefact of running configure > log > 2>&1 > > > > > > just running configure is fine. but pulseaudio still barf > > > > > > > > > so, with just 4 new patches (attached) I see this linking failure: > > > > g++ -o ../bin/cinelerra `cat x86_64/objs` > > ../thirdparty/libsndfile-1.0.28/src/.libs/libsndfile.a(libsndfile_la-flac.o): > > In function `flac_close': > > /root/src/hvirtual/thirdparty/libsndfile-1.0.28/src/flac.c:736: > > undefined reference to `FLAC__metadata_object_delete' > > ../thirdparty/libsndfile-1.0.28/src/.libs/libsndfile.a(libsndfile_la-flac.o): > > In function `flac_write_strings': > > /root/src/hvirtual/thirdparty/libsndfile-1.0.28/src/flac.c:627: > > undefined reference to > > `FLAC__metadata_object_vorbiscomment_entry_from_name_value_pair' > > /root/src/hvirtual/thirdparty/libsndfile-1.0.28/src/flac.c:628: > > undefined reference to > > `FLAC__metadata_object_vorbiscomment_append_comment' > > /root/src/hvirtual/thirdparty/libsndfile-1.0.28/src/flac.c:582: > > undefined reference to `FLAC__metadata_object_new' > > ../thirdparty/libsndfile-1.0.28/src/.libs/libsndfile.a(libsndfile_la-flac.o): > > In function `sf_flac_meta_get_vorbiscomments': > > /root/src/hvirtual/thirdparty/libsndfile-1.0.28/src/flac.c:414: > > undefined reference to > > `FLAC__metadata_object_vorbiscomment_find_entry_from' > > ../thirdparty/libsndfile-1.0.28/src/.libs/libsndfile.a(libsndfile_la-ogg_vorbis.o): > > In function `ogg_vorbis_open': > > /root/src/hvirtual/thirdparty/libsndfile-1.0.28/src/ogg_vorbis.c:506: > > undefined reference to `vorbis_version_string' > > collect2: error: ld returned 1 exit status > > make[2]: *** [Makefile:545: ../bin/cinelerra] Error 1 > > > > hm, may be disable flac support in libsndfile if possible? > > > > disabling external programs in libsndfile helps but now I meet failure > at loading mpg media: > > bin/cinelerra > Cinelerra 8 (C)2022 Adam Williams > > Cinelerra is free software, covered by the GNU General Public License, > and you are welcome to change it and/or distribute copies of it under > certain conditions. There is absolutely no warranty for Cinelerra. > BC_DisplayInfo::test_window 158: No window manager > EditPanel::create_objects: meter_panel == 0 > libancil_get_fd 88 recvmsg failed <==== here we hang > ^Csignal_entry: got SIGINT my pid=18201 execution table size=0: > signal_entry: got SIGINT my pid=18262 execution table size=0: > signal_entry: got SIGINT my pid=18203 execution table size=0: > signal_entry: got SIGINT my pid=18232 execution table size=0: > kill_subs 276: process=18203 > SigHandler::signal_handler total files=0 > SigHandler::signal_handler total files=0 > SigHandler::signal_handler total files=0 > Aborted > [root@slax hvirtual]# grep libancil_get_fd -r . > Binary file ./cinelerra/x86_64/forkwrapper.o matches > Binary file ./cinelerra/x86_64/cfunctions.o matches > ./cinelerra/cfunctions.c:int libancil_get_fd(int parent_fd) > ./cinelerra/cfunctions.c: printf("libancil_get_fd %d recvmsg > failed\n", __LINE__); > ./cinelerra/forkwrapper.C: return libancil_get_fd(parent_fd); > ./cinelerra/cfunctions.h:int libancil_get_fd(int parent_fd); > Binary file ./bin/cinelerra matches > > current set of patches to get to that point attached. so, I do not know how to debug this filefork (?) hang but disabling it still makes cin-hv works (at least media loading/playback) for me new set attached > > > > > > > > > > > > > > > > > > > > > > log attached > > > > > > > > > > > > > > Sent: Thursday, February 15, 2024 at 4:53 PM > > > > > From: "Andrew Randrianasulu" <randrianasulu(a)gmail.com> > > > > > To: broadcast(a)earthling.net, "Cinelerra.GG" <cin(a)lists.cinelerra-gg.org>, "Phyllis Smith" <phylsmith2017(a)gmail.com>, "igor_ubuntu" <sitelve(a)gmail.com> > > > > > Subject: Another attempt at patching cin-hv sources so they build on my system > > > > > a bit of mess because I was not sure if lack of .version or > > > > > .tarball-version in thirdparty/pulseaudio-13 dir was responsible for > > > > > rebuild failure. Probably .tarball-version, because just .version > > > > > already in git ... > > > > > > > > > > I was surprised my git add was not working, but it was simply due to > > > > > file being already in git, so you probably can ignore patch 0005 > > > > >

1 0

Another attempt at patching cin-hv sources so they build on my system
by Andrew Randrianasulu 16 Feb '24

16 Feb '24

a bit of mess because I was not sure if lack of .version or .tarball-version in thirdparty/pulseaudio-13 dir was responsible for rebuild failure. Probably .tarball-version, because just .version already in git ... I was surprised my git add was not working, but it was simply due to file being already in git, so you probably can ignore patch 0005

1 0