- Cin - Cinelerra-GG Mailing Lists

VideoMerge
by Andrea paz 04 Jul '23

04 Jul '23

Small GUI (in QT) for conveniently concatenating multiple video files with ffmpeg: https://github.com/kanehekili/VideoMerge

3 2

ffmpeg and libav
by Andrea paz 26 Jun '23

26 Jun '23

For developers only: how to use and implement the libav library of ffmpeg: https://github.com/leandromoreira/ffmpeg-libav-tutorial

3 2

Weekend fun
by Andrew Randrianasulu 25 Jun '23

25 Jun '23

https://cloud.mail.ru/public/gJ3D/JJmkHFCC6 should contain same vid as https://youtu.be/ouE6UABWXRE but less mangled (60 mb for 3 minutes) Captured with cingg on my poor integrated "GPU". (first to magicyuv to tmpfs - 4.6 Gb! then encoded to yuv444 h264. Not even sure if I set full/limited range correctly .. watch via mplayer -vo gl) Main thing I did here is manual setting of cpu cores for cingg/capture (0 and 1) and ssh (#3). You can (hopefully) see how my desktop machine render OpenGL 1.4 via wireless link from laptop under keyboard. Both systems running slightly de-synchronized Slackware i586 with 64-bit kernels. Second X server because I was too lazy for restarting my main one :)

2 1

Subtitles
by Andrea paz 24 Jun '23

24 Jun '23

In the youtube channel there is a request if it is possible to dynamically alter subtitles. I think not, but can anyone answer precisely? https://www.youtube.com/watch?v=JPhO2sscZzU&list=PLOnHGAy9DoU0dBhf7ibgsmpdd…

2 3

Clip from main view not saved in project
by Stefan de Konink 12 Jun '23

12 Jun '23

1. Create a clip from the main timeline 2. Notice that the clip is created in the resources window 3. Save the project 4. Open another project 5. Open the previous project 6. Notice that the clips are not present anymore -- Stefan

4 5

dvdcreate and filempeg patches
by Andrew Randrianasulu 12 Jun '23

12 Jun '23

I tried to add few more flags to filempeg encoder settings, not touching -I (as in Interlace, not small "l" as in level) for now I also tried to get interlace info from both session interlace mode and deinterlace checkbox ...

3 32

arm/termux series (possibly broken on x86)
by Andrew Randrianasulu 11 Jun '23

11 Jun '23

strangely enough, this patch series builds with dv-stuff correctly now.. no build/link/runtime errors.. based on git commit 9d54c23d957

6 35

x265 git update
by Andrew Randrianasulu 09 Jun '23

09 Jun '23

Builds and appear to work on aarch64/termux, still not tested on say Arch arm ... x265 [info]: HEVC encoder version 3.5+1-f0c1022b6 x265 [info]: build info [Linux][clang 16.0.5][64 bit] 8bit x265 [info]: using cpu capabilities: NEON x265 [info]: Main profile, Level-4 (Main tier) x265 [info]: Thread pool created using 8 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(17 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3 x265 [info]: Keyframe min / max / scenecut / bias : 30 / 30 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 3 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60 x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp x265 [info]: tools: b-intra strong-intra-smoothing lslices=6 deblock sao FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/20081103140154.m2t x265 [info]: frame I: 5, Avg QP:28.02 kb/s: 14141.36 x265 [info]: frame P: 25, Avg QP:28.87 kb/s: 3623.26 x265 [info]: frame B: 92, Avg QP:34.67 kb/s: 504.94 x265 [info]: Weighted P-Frames: Y:4.0% UV:0.0% encoded 122 frames in 39.10s (3.12 fps), 1702.81 kb/s, Avg QP:33.20 Render::render_single: Session finished. ** rendered 122 frames in 43.021 secs, 2.836 fps === for 1440*1080 m2ts re-encoding

2 4

psychtoolbox vs HDR
by Andrew Randrianasulu 08 Jun '23

08 Jun '23

Found this tidbit http://psychtoolbox.org/news.html in 3.0.18 beta 16 bit native (effective 12 bit) framebuffer support for Linux with AMD Polaris and later. ==== This commit switches PsychImaging() to only expose 16 bpc framebuffers on such Linux + X11 + AMD Polaris+ + amdvlk + Linux 5.14 systems, but then at much better reliability and performance than our old dead code. It allows to get up to 12 bpc per color-channel color output, ie. 4096 intensity levels for red, green, blue, grayscale/luminance and a total of 64 billion shades of color, either on suitable 12 bpc capable high-end displays, or via spatial dithering by the gpu on the more common 10 bpc capable displays or even - at a lower quality - standard 8 bpc capable displays. This makes Linux the first operating system to my knowledge to support this color precision on out of the box on commodity graphics hardware and displays, natively at full performance without any compromise in timing precision or reliability. Basic testing has been performed with a CRS ColorCal-2 on a HDR-10 10 bpc capable monitor and on a MacBookPro 2017 Retina display under Linux, with AMD RavenRidge and Polaris. ==== test apps apparently even include gstreamer-based movie player (never thought I'll find HDR player in medical software ...) http://psychtoolbox.org/docs/PsychHDR http://psychtoolbox.org/docs/PlayMoviesDemo === If the optional flag ‘hdr’ is specified as non-zero, then the demo expects the onscreen window to display on a HDR-10 capable display device and system, and tries to switch to HDR mode. If the operating system+gpu driver+gpu+display combo does not support HDR, the demo will abort with an error. Otherwise it will expect the movies to be HDR-10 encoded and try to display them appropriately. A flag of 1 does just that. A flag of 2 will manually force the assumed EOTF of movies to be of type PQ, iow. assume the movie is a HDR-10 movie in typical Perceptual Quantizer encoding. This is useful if you want to play back HDR content on a system with a [GStreamer <http://psychtoolbox.org/docs/GStreamer>](GStreamer) <http://psychtoolbox.org/docs/%28GStreamer%29> version older than 1.18.0 installed, where [GStreamer <http://psychtoolbox.org/docs/GStreamer>] (GStreamer) <http://psychtoolbox.org/docs/%28GStreamer%29> is not fully HDR capable, but this hack may get you limping along. Another restriction would be lack of returned HDR metadata, so if your HDR display expects that, you will not get the best possible quality. Upgrading to [GStreamer <http://psychtoolbox.org/docs/GStreamer>](GStreamer) <http://psychtoolbox.org/docs/%28GStreamer%29> 1.18 or later is advised for HDR playback. A flag of 3 or 4 will use an alternative HDR display method only available on Linux/X11, with 4 applying the same hack to cope with older [GStreamer <http://psychtoolbox.org/docs/GStreamer>](GStreamer) <http://psychtoolbox.org/docs/%28GStreamer%29> versions as a setting of 2. ==== happy psyching! (???)

2 2

aarch64 x265 part of build broken on Arch Arm?
by Andrew Randrianasulu 08 Jun '23

08 Jun '23

User reported build failure: https://gist.githubusercontent.com/ivabus/9945c01f08c991f27f984efa8d3a43cd/… I thought it was fallout from my aarch64-clang patching. I dived in x265 git and supposedly there was fix, partially applicable to our patched x265. Can anyone test on aarch64 gcc - I tested with termux/clang and it patches and builds .... full git clone was done this way git clone https://bitbucket.org/multicoreware/x265_git/ then I looked for specific commit git checkout -b aarch64 0b75c44c10e605fe9e9ebed58f04a46271131827 and extracted single commit git format-patch 931178347b3f73e40798fd5180209654536bbaa5 and then removed last part because this file was already changed between that we have and git at that point. Commit was found by looking at this bugreport https://github.com/markus-perl/ffmpeg-build-script/pull/180/files may be we can test recent x265 git, too ...

1 0