- Cin - Cinelerra-GG Mailing Lists

Cinelerra-GG on Ubuntu 20 LTS
by Phyllis Smith 26 Apr '20

26 Apr '20

Uploaded version 20 of Ubuntu and built Cinelerra on it without any problems that we could see right away. A static tar is available at: https://cinelerra-gg.org/download/testing/cinelerra-5.1-ub20-x86_64.static.… If anyone has time to test and finds a problem, please let us know. To compile Cinelerra, we first had to install Python as it was not included with the install.

1 0

Today's checkin and planned work yet ...
by Phyllis Smith 26 Apr '20

26 Apr '20

Performance improvements for drawing video and audio on the timeline are in this latest GIT checkin. Depending on what you do and how big your media is, you should see speed up when refreshing the draw on the timeline. Please notify of any anomalies. If anyone who does not do their own builds wants to use this new version early, we will gladly create a test static tar. Even if you do not see a speed up because you only use small media, it helps us if you test to shake out any bugs. Also, thanks to Andrea, an improved IQ graticule for the Videoscope, VectorWheel overlay is improved. We thought that the shortcut "k" for next keyframe is fixed and it works for us but feedback from Andrea is inconclusive so if anyone else can test this, it would be appreciated (BT #414). Plans for the next few days (which will probably change or we run out of time). A little more work on Videoscopes to fix the layout and think about if/how to add "realtime" option (BT #71). And more work on Effects Stack as in BT #84.

2 5

Can't get Cin installed
by Douglas Pollard 25 Apr '20

25 Apr '20

Hello Phyllis, I had been running Mint and had cin Installed. Switched to Ubuntu Studio douglas@douglas-HP-Pavilion-Gaming-Desktop-690-00xx:~$ Sudo https://cinelerra-gg.org/download/pkgs/mint19 bionic main Command 'Sudo' not found, did you mean: command 'ludo' from snap ludo (0.11.0) command 'udo' from deb udo (6.4.1-4) command 'sudo' from deb sudo (1.8.27-1ubuntu4.1) command 'sudo' from deb sudo-ldap (1.8.27-1ubuntu4.1) See 'snap info <snapname>' for additional versions. douglas@douglas-HP-Pavilion-Gaming-Desktop-690-00xx:~$ sudo deb [trusted=yes] https://cinelerra-gg.org/download/pkgs/mint19 bionic main [sudo] password for douglas: sudo: deb: command not found douglas@douglas-HP-Pavilion-Gaming-Desktop-690-00xx:~$ deb [trusted=yes] https://cinelerra-gg.org/download/pkgs/mint19 bionic main Command 'deb' not found, did you mean: command 'dub' from snap dub (1.19.0) command 'den' from snap den (1.2.0-0) command 'dep' from deb go-dep (0.5.4-2) command 'dex' from deb dex (0.8.0-2) command 'debi' from deb devscripts (2.19.6ubuntu1) command 'dab' from deb bsdgames (2.17-28) command 'debc' from deb devscripts (2.19.6ubuntu1) command 'deb3' from deb quilt (0.65-3) command 'edb' from deb edb-debugger (1.0.0-1build2) command 'dub' from deb dub (1.16.0-1build1) command 'derb' from deb icu-devtools (63.2-2ubuntu0.1) command 'xdeb' from deb xdeb (0.6.7) See 'snap info <snapname>' for additional versions. douglas@douglas-HP-Pavilion-Gaming-Desktop-690-00xx:~$ https://cinelerra-gg.org/download/pkgs/mint19 bionic main bash: https://cinelerra-gg.org/download/pkgs/mint19: No such file or directory douglas@douglas-HP-Pavilion-Gaming-Desktop-690-00xx:~$ apt update Reading package lists... Done E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) E: Unable to lock directory /var/lib/apt/lists/ W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied) W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied) douglas@douglas-HP-Pavilion-Gaming-Desktop-690-00xx:~$ apt install cin E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root? douglas@douglas-HP-Pavilion-Gaming-Desktop-690-00xx:~$ sudo apt install cin Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package cin douglas@douglas-HP-Pavilion-Gaming-Desktop-690-00xx:~$ I have had a struggle getting Cinelerra GG installed before. I guess I just don't understand this process . Thanks for any help that will help me get cin installed, Douglas

3 2

No Able to build by Git 20200423 for Ubuntu 16.04
by Igor BEGHETTO 25 Apr '20

25 Apr '20

I am not able to make a build by git "Thu, 23 Apr 2020 03:51:12 +0200 (19:51 -0600)" Build by git "Tue, 21 Apr 2020 03:00:51 +0200 (19:00 -0600)" works fine. Where I wrong? I added log file. Thanks! IgorBeg (OS: UbuntuStudio_16.04_16bit_LTS)

2 2

Timeline performance
by david 24 Apr '20

24 Apr '20

Hi all. I have been trying some video editing with Cinelerra. It seems a very powerfull program but I am surprised of the clunkyness of timeline when I move video pieces, or select them for moving. My tests are very humble. Only two pieces of video of no more than 20 seconds. It is very frustrating to be precise enough when moving parts. Is it normal? Perhaps some bug with my media or configuration? Video composition in previewer is fast and very good, but not commented simple operations. Comparing other options, like Olive editor, in which working with parts is very fast and precise I ask myself if there is space for Cinelerra optimizations in this matter. Thank you very much for your work :) Greets. -- David

2 7

Best practice to copy & paste track with changed speed
by deim31 24 Apr '20

24 Apr '20

Hi, I made small tutorial from mobile screen record. I changed speed and when I realized I wanted blur some region I tried this: try #1: 1) copy region from video to new video track 2) set mask for region 3) add blur effect But it doesn't work - what I copied is not what I pasted try #2: 1) copy whole track to new video track 2) and 3) is identical to #1 But speed didn't copy => argh... try #3: 1) copy whole track to new video track before speed modification 2) gang edits and edit speed (copied to second track) This worked well. But there may be a bigger project where I realize I need to copy track with modified speed so my question is how to do it when I didn't planned edits well and need to copy region from track with changed speed. Thanks ;-) deim

3 4

Re: [Cin] wildest dreams: stream-copy and/or skipping avoidable pixel format conversions
by Simeon Völkel 24 Apr '20

24 Apr '20

Hi Einar, Hi Phyllis, as your highly appreciated responses are faster getting in than I can respond adequately in individual mails, I'll try to respond to them collectively below. Am 24.04.20 um 14:53 schrieb Einar Rünkaru: > Hi. > > On 4/23/20 11:54 PM, Simeon Völkel wrote: >> Hi Andrew, >> >> this was way quicker than I expected to get a response :D Please see below >> for my interleaved comments. >> >> Am 23.04.20 um 16:45 schrieb Andrew Randrianasulu: >>> В сообщении от Thursday 23 April 2020 13:36:30 Simeon Vc3b6lkel написал(а): >>>> Hi all, >>>> >>>> coming back to cinelerra after a whole decade, I was really surprised >>>> finding now even hardware accelerated decoding and encoding implemented... >>>> Even though the landscape of cinelerra-forks seems to become increasingly >>>> confusing, THANK YOU, to all who contributed in the last years and of >>>> course especially to Adam, Einar and William for their tireless >>>> commitment! > > Thanks. > >>> I think this was done in old Cinelerra for some DV variants and mjpeg >>> (in mov and avi) >>> >>> In old CinelerraCV it was removed in commits >>> >>> https://github.com/cinelerra-gg/cinelerra-cv/commit/8364fc6af3eb9b105ecf085… >>> >>> https://github.com/cinelerra-gg/cinelerra-cv/commit/0ff51f4c53e17ff33701e8c… >>> >>> >>> I remember this because I tested this (mis)feature, and found it working >>> for >>> mjpeg avi (so i was not convinced by this reasoning and just keep my >>> copy at commit before this :E) >>> >>> https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerr… >>> >>> >>> enum BC_CModel { >>> 27 BC_TRANSPARENCY = 0, >>> 28 BC_COMPRESSED = 1, >>> >>> [..] >>> >>> I think this 'colormodel' define was used for this. >> >> >> >> This is a very interesting finding, and something I was not aware at all. >> So thanks for bringing this piece of history to my attention! >> >> I'm wondering, too, whether the noticeable differences are really rounding >> problems or rather mismatch between "full swing" and "studio swing", i.e. >> using all possible (e.g. 8-bit) values or only a limited sub-range. I seem >> to remember from the 2000s that pausing and playing a DV video could (or >> would in every case?) switch between "darker black" and "brighter black", >> reminding of a "MPEG YUV" vs "JPEG YUV" range mismatch. >> >> Maybe Einar can give additional details concerning the circumstances of the >> removal? > > Everything is said in commit messages. As I rememeber, someone asked the > reasons and I explained. Search mail archives. Thanks for the hint and sorry for me forgetting about the patch discussions on CinCV-ML. The thread https://lists.cinelerra-cv.org/pipermail/cinelerra/2017q3/006525.html has been brought to my attention, where the pro and cons were indeed discussed in detail. > > As Cinelerra-gg contains this feature try to use it. If you do not succeed, > it is quite useless feature. While I fully agree that supporting this feature only for formats popular two decades ago makes it an extreme niche product, I for myself wouldn't call it outright useless. But I have to admit, that my personal bias might be unusually strong in this regard as my video-editing self literally grew up in parallel with DV. :D Towards the end of the thread linked above, Andrew reported on several of his experiments for verifying the speedup offered by direct copy of DV: https://lists.cinelerra-cv.org/pipermail/cinelerra/2017q3/006546.html https://lists.cinelerra-cv.org/pipermail/cinelerra/2017q3/006569.html So at least back then it wasn't broken per se and the commands he posted should help if anyone wants to verify it again right now. > > There is a good explanation why the requested feature could not be > implemented in > https://lists.cinelerra-gg.org/pipermail/cin/2020-April/001880.html > > I agree with it. I hope that especially my initial "wildest dreams" mail wasn't misconceived as a "plz implement this, thx!!1eleven!" mail! I simply wanted to bring up this topic in the context of cinelerra, as I have found quite some (rather "techy") people working with video regularly completely unaware of the feasibility (and benefits) of stream copying (under certain circumstances) and didn't stumble upon cinelerra's direct copy capability (for DV) right away either. I understand that the quoted cost-benefit calculation from Phyllis and/or William makes stream copying sound like a poor investment of (developer) time. With the current limitation on number of tracks and supported codecs as a prerequisite, I even agree on that point. But I would like to challenge the estimated figure of only 2% of Cinelerra's userbase benefiting of stream-copying as soon as nowadays popular codecs were supported. Cinelerra would have to be able to identify (even in the case of multiple tracks) all frames for which only a single track is relevant for the final output AND containing a clip not affected by any effect in the wider sense of the desired output format (with stream-copying-compatible settings of course). These are quite some prerequisites. But given that several people involved with (or at least familiar with) cinelerra have already thought about this, I could imagine that finding an exhaustive list of conditions is absolutely feasible. Given this identification ability (and support of nowadays relevant intra-frame-only codecs), I would phrase the benefiting cases not as "trivial edits" anymore but rather e.g. "in between fades if no effect is applied either". Of course there can be projects where the number of frames not being color-graded, scaled or overlaid by lower thirds can be counted on the fingers of one hand. But I would be surprised if these were the overwhelming majority ;) Regarding the nowadays most popular codecs, I have to disagree with Johannes's statement in https://lists.cinelerra-cv.org/pipermail/cinelerra/2017q3/006539.html that "It can certainly not be extended to formats that have inter-frame compression.", as ffmpeg's -c:v copy and the concat demuxer working perfectly for me simply proves this statement to be technically wrong. I do not want to say that it would be easy to achieve. And as detailed in my first mail, I'm not even sure about the general applicability when thinking about possible restrictions on the GOP-length and -structure. In addition I'm afraid that Phyllis estimation for the amount of developer hours required for "full" stream-copying support in cinelerra might be not too far off. However I'm wondering how involved a hybrid approach would be. I imagine that giving the user feedback in the GUI on the current frame type (I, B, P, etc. similar to ffmpeg's showinfo filter) will be very beneficial for a first mock-up. Together with an "only-single-unmodified-clip-relevant" identification ability mentioned above, I think that at least a ffmpeg concat demuxer export or even a direct forwarding from the demuxer to muxer within cinelerra as discussed by Andrew should be feasible to hack, at least for not-too-involved cases... Again, please don't take this as an immediate feature request, but rather a venturous proposal seeking futher in-depth discussion. Still, in case anyone willing to fearlessly fight with a compiler (no need to be a proven software engineer ;)) is reading this: I would definitely welcome any coding experiments in this direction. As I see quite some hard nuts to crack, I guess that additional architectural thinking should be spread on many shoulders before anyone currently involved with Cinelerra's development should be asked to go down to her codebase. > Sorry, > Einar No need to say sorry... I feel honored to be able to discuss this with Cinelerra's current experts, even if things should remain dreams! Best regards, Simeon

1 0

wildest dreams: stream-copy and/or skipping avoidable pixel format conversions
by Simeon Völkel 23 Apr '20

23 Apr '20

Hi all, coming back to cinelerra after a whole decade, I was really surprised finding now even hardware accelerated decoding and encoding implemented... Even though the landscape of cinelerra-forks seems to become increasingly confusing, THANK YOU, to all who contributed in the last years and of course especially to Adam, Einar and William for their tireless commitment! With this mail I want to put forward two ideas, or rather wildest dreams, how cinelerra could improve performance considerably in cases where little (or rather: "nothing") is to be done to the input video frames. Motivation / Introduction In the last weeks I had to deal a lot with "trivial editing" with long and/or large files: Chopping of a few seconds at the beginning or end, sometimes concatenating two or three takes, removing a constant offset between audio and video. As my videos had a constant group-of-pictures (GOP) length so I knew the position of keyframes and shifting the cuts around by half a GOP was no problem either, I could completely avoid reencoding of the video stream using the command line tool ffmpeg. FFmpeg works perfectly fine for single "trivial edits", but the command (and required filters) becomes admittedly complex as soon as multiple edits have to be made. Stream copying So in my wildest dreams I dreamed of good old cinelerra learning how to do stream-copying (read up on ffmpeg's -c:v copy and -c:a copy if you are not familiar with that concept!). As stream-copying does not require to decode the input, the achievable speed is typically bound by the disk IO -- it can be as fast as your SSD-Raid at nearly negligible CPU cost. Please note that stream-copying per definition only works if the packets from the input are not to be altered at all and the output stream has exactly the same encoding settings [1]. Only the container format would be allowed to be different, as long as it can carry the unmodified stream. Implementing this in cinelerra would definitely be a huge, nontrivial change. It would require at least detection of the input encoding settings and matching the output settings respectively, a shortcut around the whole 'decoding->camera->intermediate->projector->encoding' pipeline where no effects (in the wider sense!) are active and whole GOPs could be stream-copied and I haven't even looked up yet whether it could be feasible to adapt any of the current rendering/muxing backends to accept "already encoded" input (being forwarded through the shortcut). Nevertheless, I wanted to share this vision, just in case someone should be on the look-out for a *real* challenge! ;) Transcoding bottlenecks Coming down to earth, I tested the hardware accelerated decoding and encoding in cinelerra-gg. This apparently works. Having shifted the heavy codec work away from the CPU, new bottlenecks appear, e.g. pixel format conversions and memory operations. I profiled cinelerra-gg using operf during rendering when using an Intel UHD Graphics 630 GPU (gen9.5) for HW decoding and a Nvidia Quadro P2000 (Pascal nvenc) for encoding. The most time-consuming parts appear to be: When setting format to YUV 8bit: 17.7664 BC_Xfer::xfer_yuv888_to_yuv420p(unsigned int, unsigned int) 13.1723 BC_Xfer::xfer_yuv444p_to_yuv888(unsigned int, unsigned int) 10.7678 __memmove_avx_unaligned_erms [ in libc-2.31.so ] 10.7615 ff_hscale8to15_4_ssse3 8.5718 BC_Xfer::xfer_yuv888_to_bgr8888(unsigned int, unsigned int) 2.8518 ff_yuv2plane1_8_avx When setting format to RGB 8bit: 17.8958 yuv2rgb24_1_c 13.4321 __memmove_avx_unaligned_erms [ in libc-2.31.so ] 10.9851 lumRangeToJpeg_c 10.2374 ff_hscale8to15_4_ssse3 8.7581 ff_hscale14to15_4_ssse3 7.5900 ff_rgb24ToY_avx 7.1143 rgb24ToUV_half_c 4.8434 chrRangeToJpeg_c 4.7945 BC_Xfer::xfer_rgb888_to_bgr8888(unsigned int, unsigned int) 2.0201 ff_yuv2plane1_8_avx When setting format to RGBA 8bit: 16.3639 yuv2rgbx32_1_1_c 14.8711 __memmove_avx_unaligned_erms [ in libc-2.31.so ] 10.0083 ff_hscale8to15_4_ssse3 9.1448 lumRangeToJpeg_c 8.7119 ff_rgbaToY_avx 8.5619 ff_hscale14to15_4_ssse3 8.2640 rgb32ToUV_half_c 5.1650 BC_Xfer::xfer_rgbx8888_to_bgr8888(unsigned int, unsigned int) 5.1056 chrRangeToJpeg_c 1.9289 ff_yuv2plane1_8_avx When setting format to RGB-Float: 15.7817 BC_Xfer::xfer_rgba_float_to_rgba16161616(unsigned int, unsigned int) 15.4870 BC_Xfer::xfer_rgba8888_to_rgba_float(unsigned int, unsigned int) 12.9261 rgb64LEToY_c 7.4284 __memmove_avx_unaligned_erms [ in libc-2.31.so ] 6.6232 av_pix_fmt_desc_get 6.0252 rgb64LEToUV_half_c 3.7100 yuv2rgbx32_1_1_c 2.9902 BC_Xfer::xfer_rgbx_float_to_bgr8888(unsigned int, unsigned int) 2.1572 ff_hscale8to15_4_ssse3 2.0333 lumRangeToJpeg_c 1.8625 ff_hscale16to15_4_ssse3 During rendering, two of eight cores were at 70-85% (according to htop). As none reached 100% alone, but the sum is above 100%, I'm not really sure whether rendering is currently CPU bound or rather memory bound. If someone knows a good tool how to discriminate between these two bounds, please tell me! In case this should be CPU bound, multithreading in this part of the code might help, as I have (more than) 6 idling CPU cores left on this machine ;) With RGBA 8bit transcoding (i.e. rendering a timeline consisting of a single "unmodified" input clip) of a FullHD 25p h264 video using HW accelerated cinelerra can take now only a quarter of the playback time (in ffmpeg notation: speed=4x). Comparison to ffmpeg transcoding While this might seem impressive at first sight (this is equivalent to 4K transcoding in realtime!) this is still a fraction of the speed ffmpeg achieves for the same transcoding path (decoding on intel, encoding on nvidia): ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i INPUT.MOV -c:v h264_nvenc -preset:v slow -c:a copy OUTPUT.mkv is still nearly four times faster 375 fps (speed = 15x) (a single CPU core used, not even exceeding 50%, according to htop), using -preset:v medium 450 fps are reached (speed = 18x) and if speed is more important than compression quality, -preset:v fast allows for a whopping 500 fps (speed = 20x) (a single CPU core at 60-70% according to htop). Of course this is comparing apples to oranges, especially when comparing it to stream-copying (instead of reencoding) which can be still at least an order of magnitude (!) faster. But I hope it helps to see that there is still quite some room left for improvements in (corner?) cases, where the input video is not altered at all. Feasibility considerations Regarding the feasibility of improving cinelerra within finite time, I would imagine that skipping avoidable conversions and reducing memory operations is the lower hanging fruit compared to stream copying. However I think this would still imply a nontrivial extension of the internals, which allows decoded frames to be directly forwarded from input to output in pixel formats the rest of cinelerra (e.g. camera/projector/effects) possibly doesn't understand at all if they are not affected by any effect in the wider sense (including scaling and translation through camera/projector). Ideally, cinelerra would of course implement both: where whole GOPs can be stream-copied, do this. Where cuts do not align with GOP borders, effects affect only some frames within a GOP, or input and output do not use the same codec (+ settings): avoid at least as many pixel format conversions as possible, especially for the effectively unaltered frames. Disclaimer I'm not working on implementing any of these two ideas and I don't expect that I will ever find time to do so. So please take away the idea you like. Conclusion Using hardware acceleration in cinelerra for decoding AND encoding, pixel format conversion and memory operations appear to be the new bottleneck when effectively transcoding a video. Avoiding them wherever possible is expected to allow for up to 4-5 times faster rendering when effectively transcoding. If the output settings are exactly[1] equal to the inputs' codec settings, (selective) stream-copying could achieve two orders of magnitude faster rendering, but is expected to require a major modification of cinelerra's internals. As both of my wildest dreams imply nontrivial, possibly major changes, I could very likely be totally wrong what is easier to implement, so please don't quote me on that ;) Best regards and happy hacking, Simeon [1] the "exactly" can be weakened sometimes, but going into this in detail would take us way too far.

3 4

Official CinGG channel on Youtube
by Andrea paz 23 Apr '20

23 Apr '20

A proposal to organize the channel in playlist. Instead of making collections according to the language or according to the author, I propose to collect the videos according to the topics. For example: "installation" "GUI" "subtitles" "Editing" "Effects" ... On the front page you will always see the latest entries in chronological order (and as a video presentation I would put Sam's), but if you go to the Playlist section you can choose the topic you are interested in. Author and language can be put in the title and description. See how well organized the Lightworks videotutorials section is: https://www.lwks.com/index.php?option=com_content&view=article&id=162&Itemi… Another question, is how to contact and be contacted by users who want to put their videos on the channel. You can write a post in the forum and maybe even a note on the website. What else?

4 15

ffmpeg.git changes for mpegts muxer
by Andrew Randrianasulu 23 Apr '20

23 Apr '20

Hi all! Currently I have some fun (bug) with mesa git drivers and Blender 2.79b (and related items like LuxRender) so I mostly read Cin list without saying much. Still, there are some changes, possibly breaking ffmpeg.git patchset: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/422f0a61367f068fb8b1b9ab8cc… avformat/mpegtsenc: use standard pids for m2ts and few others after that one https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/bcc19933af903cda7a824ee654b… avformat/mpegtsenc: only allow one program in m2ts mode https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/3958244c918e3cee921ace43896… avformat/mpegtsenc: factorize determining stream_type https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/7f2649bb46e3dde691edfb03aeb… avformat/mpegtsenc: use the correct stream_types and write HDMV descriptors for m2ts Fixes ticket #2622. Last one adds this line to Changelog: +- Support for muxing pcm and pgs in m2ts

1 0