Feature-filmmaker looking to use Cinelerra GG on major-motion-picture: Questions regarding GPU-specifics; Color grading; Cineform.

Help & Support
1

Hello, I am a feature filmmaker (remaining anonymous) working on pre-production for a movie. We plan to use an entirely open-source pipeline for capturing and editing our movie.

I was advised to look at Cinelerra GG Infinity as our editing platform.

So far, our team loves the software. The user-interface alone is a breath-of-fresh-air. Razor-sharp; reminds me a lot of the Silicon Graphics systems. Fast and robust (so far).

I have a few questions, that I would be extremely grateful for guidance on:

**Do we need to compile our own build of Cinelerra GG on our host computer to use GPU processing?

The manual suggests that if we simply use the standard appimage file on our Linux system, then it is unlikely to use the GPU? Is this still the case? I just wanted to check that the GPU-related guidance in the manual is entirely up-to-date, and we should follow that. In our case, were using a Nvidia GPU on our test system. Currently, nothing fancy; a Quadro p2000 we happened to have in a graphics-workstation – just for this initial testing phase.

Later we will equip a system with a more modern card. Is there a preferred-choice for this? Perhaps the card used on the development test systems?

Cinelerra GG does not have typical color-management; is there any reason not to grade in sRGB on color-calibrated displays?

I am aware that the film industry has an obsession with color-grading. As a director, coming from 35mm film (and color-timing), this mostly appears to me as an entire-industry that has sprung out of an attempt to fix badly-shot footage; or apply a look.

I am happy to forgo most grading and wrestling with ACES etc, and just shoot properly and grade for computer screens (our main audience). Can a colorist here, or anyone, give a perspective on Cinelerra GG in this regard? What is the best-practice here?

How is Cinelerra GG when editing the Cineform codec?

We would like to use an open-source capture, and edit, codec. Cineform is reportedly excellent in this regard. Its open-source and archival-grade quality. Has anyone on the forum used Cinelerra GG to edit footage in the Cineform codec? Does *Cinelerra GG *generally perform well with this codec?

We plan our own tests, but first we need to ensure Cinelerra GG is set up properly with regards to GPU etc. Im curious about the experiences of others here with Cineform.

Hoping to use Cinelerra GG on a major motion picture and give information and resources back to this community.

The production team here feels it is the right time to make a movie using open-source tools on Linux. Were very happy that Cinelerra GG exists, and we will share our process with the community as the project progresses.

Thanks!

2

@nostromo

Depending on timezone, you will most likely get answers from others later as many of our users are in Europe.

Should you do your own compile to take best advantage of the graphics card? That is always preferred and not difficult, however if you set the Driver in Settings->Preferences, Tab A to GL, you get the most advantage. Alternatively, at Release 20240522 · einhander/cin-gg-packages · GitHub if you have one of those Operating Systems, you should also be at an advantage. I do not know which board is the best, but probably Nvidia is the most widely used and was the one where the later mods were developed on.

The color management questions will most likely be addressed by @andreapaz . I do not know anything about Cineform codec and not sure if/how if it is compatible with CinGG. Per the internet, it is available with ffmpeg and CinGG uses that reliably and most frequently. We are currently at ffmpeg 7.0 and do try to maintain updates.

However, we do not currently have a full time programmer. Generally there is a workaround for anything and everything if a problem is encountered.

3

@phylsmith2004

Thank you for your friendly response and guidance.

Good to hear it confirmed that we should compile *Cinelerra GG *on our host system for best-performance. Incidentally, we are running a Debian-based system. Thank you for the links to packages.

The Cineform codec was recommended to us because it is high-quality and open-source. As you note, Cineform should work as it is part of the functionality. of ffmpeg However, if there is a performance issue with Cineform in Cinelerra GG, then Im open to alternatives.

I guess I may need to test this. I have the Cineform SDK and ffmpeg installed, but it remains a mystery what the precise commands are to encode Cineform and the best wrapper to use. I will keep researching, but lack of obvious documentation suggests that Cineform is considered quite esoteric?

I will await any other replies from those in other time zones. Thanks again!

4

@nostromo Welcome.

  1. The best thing is to be able to compile CinGG so that you have maximum capability to update and take action on parts of the program. I, on a Ryzen 5900X, take just over 3 minutes. Alternatively, you can request a binary for your distribution from Einhander whenever a useful patch comes out.

  2. Nvidia gives better guarantees of operability and performance than Intel/AMD (vaapi). Use vdpau/cuda in decoding, for the few codecs supported, and use Nvenc in specific presets for encoding. However, problems occasionally pop up, though rare and fixable. An alternative is to use the Render farm which works well and can involve both the various cores of a CPU and multiple CPUs distributed over LAN/WLAN. For Playback it is advisable to use either Background rendering (which can also use the Render Farm) or use an intermediate made from images sequence (OpenEXR, for example).

For GPU:

https://cinelerra-gg.org/download/CinelerraGG_Manual/Hardware_video_acceleration.html
https://cinelerra-gg.org/bugtracker/view.php?id=604

For Render Farm:

https://cinelerra-gg.org/download/CinelerraGG_Manual/Render_Farm_Usage.html

  1. Unfortunately, CinGG has no color management. The creator of Cinelerra, from which CinGG was derived, once replied to me:
    There is no color management workflow.

Everything known about how CinGG treats color can be found here, but it is incomplete and unsatisfying:
https://cinelerra-gg.org/download/CinelerraGG_Manual/Overview_on_Color_Managemen.html

In short, CinGG uses a Float engine internally and would therefore support both HDR and color information retention. However, some tools or plugins may introduce clipping during the workflow. For example, Histogram Bezier (curves) causes clipping at 1.0 while working in float. Color3Way has no clipping in the color wheel but has it in the Brightness slider.

Here is an example of a discussion that leads to no real conclusion:

If you experiment and come to conclusions, please let us know so that we can incorporate them into the manual and, if possible, we will try to make patches to the CinGG code. If you are then able to work on the code yourself, even better, given the chronic lack of developers.

  1. Under the container mov we have the preset CineformHD.mov. I used it just to test it and verify its operation and had no problems. I dont use and know the codec though so I cant give more information.
    I hope someone who uses it can elaborate on its behavior. I see the following warning:

input Width must be divisible by 16 and Height by 8.

In the codec settings you have the following pixel_formats available:
yuv422p10le
gbrp12le
gbrap12le

One can act on the quality parameter.

All possible settings are derived from ffmpeg, which CinGG uses with this codec. It is easy to vary or add more parameters or create a new preset with your preferred configuration.

Any info and experiences you can provide are welcome. The CinGG community is small but we help each other as much as possible.

5

Thank you for your guidance @phylsmith2004 and @andreapaz

Our team here will run some experiments to determine whether the Cineform codec is going to work for us. The expectation is that we can edit Cineform 4k smoothly in CinGG, but there is always the option of proxies. Will report back.

Regarding color-management: Thank you @andreapaz for pointing me in the direction of previous discussions on the topic. Again, it looks like we will have to run some tests and figure out the recipe for exporting with color we are happy with.

The team here is prepared to hack a few solutions and pass this information back to the community here.

Incidentally, did anyone ever look at introducing some kind of color-management to *CinGG? *It is not unthinkable I might look at getting something coded (some of the team have programmed software-solutions before) but I suspect this would be quite a significant addition to CinGG?

Im curious about whether there was any discussion of implementing color management and how that might broadly be done; from the perspective of the software architecture?

Brief research turned up OpenColorIO, an open-source color-management system, but I have not yet looked at precisely what they offer, or the difficulty in integrating it into *CinGG. *Interested to hear any thoughts on that.

Either way, Im sure that, for our initial project, we can work around the existing color-management system (or lack of).

Thanks again!

6

@nostromo

Unfortunately, changing the code of CinGG to give it Color Management requires expertise not only in C++ but also in OpenGL and color science. No one, so far, has been able to deal with this. Any contribution is welcome, given the importance of the subject.
Some discussions:

https://cinelerra-gg.org/bugtracker/view.php?id=238

https://cinelerra-gg.org/bugtracker/view.php?id=646

https://cinelerra-gg.org/bugtracker/view.php?id=294

As I have already reported the main developer never thought about color. When I asked another good developer (Einar) if it was possible to implement ACES he replied that it would destroy any performance in Cinelerra. The CinGG developer (who is no longer with us) said that color was not his field, but given the importance he would try to go deeper into OpenGL and color. But now that possibility has dropped. Over time there have been several requests on color management, even the simplest ones, such as just supporting ICC color profiles, but no one has ever managed to implement them.
OpenColorIO seems to me to be the most plausible way forward also because there are implementation examples available (in Natron, Olive, for example) from which one could start. But even here no one has been able to implement it.

One note: the forum is generally not frequented by the few CinGG developers; discussion on the mailing list or Bug Tracker would be more fruitful. In the meantime, Ill try to cite this discussion, hoping for more technical contributions than Im able to bring (Im not a programmer).

https://lists.cinelerra-gg.org/pipermail/cin/2024-July/008385.html

7

As an editor for television broadcasts using Cinelerra exclusively my suggestions would be:

  • Make sure you understand mastertrack and gang. If you have this feature enabled you get the experience that you want. And you can do fine tuning later. I think this method is commonly expressed as puting everything on a timeline and making dailies. This is faster than creating clips in Cinerella.

  • Enable align cursor on frame after you have tuned your audio. Otherwise all kind of funky stuff moves around.

  • I am recording in AdobeRGB. I am not editing on calibrated monitors, but I am using a primary monitor with a significant higher brightness that shows me noisy footage (4:2:0) much better than my secondary monitor with more representative colours. Cinerella allows colorgrading but you know you cant push this footage too far.

  • My main pain in Cinelerra is in multi cam, multi audio to apply synchronisation. I sync everything by hand/ear/eye. If you have the ability to record footage with timecode, I am interested in your experience as well.

  • The order of effects matter. I also wonder if you would benefit in creating intermediate renders.

  • Sub projects, and playlist may work. Keep an eye on your audio. My experience is that this sometimes does not work as expected. Test before trust.

  • Cinelerra may crash, especially when the ulimit (filedescriptors) is not unlimited. 1024 open files (especially with gpu support) is easily reached. If it crashed, you may recover your session. Just make sure you save often too :wink:

8

@nostromo

Im a simple user and have not much knowledge to contribute here. But regarding encoding Cineform with ffmpeg, I found by googling and experimenting a bit

ffmpeg -hide_banner -codecs | grep cfhdDEV.L. cfhd GoPro CineForm HDHelp with the cfhd encoder can be listed with

ffmpeg -hide_banner -h encoder=cfhdI experimented to encode a sample Cineform FHD output file from a 1080i HDV input clip using default parameters

ffmpeg -hide_banner -i hdv09_04.m2t -c:v cfhd cfhd09_04.mkvframe= 5963 fps=465 q=-0.0 Lsize= 7906905KiB time=00:03:58.77 bitrate=271272.5kbits/s speed=18.6xComparing the input and output file sizes

du -sh hdv09_04.m2t cfhd09_04.mkv745M hdv09_04.m2t7.6G cfhd09_04.mkvAt least the latter Cineform file could be playback ok using VLC

Similary someone can possibly create a more representative 4k file for testing in CinGG,

With reference to the manual, the question is if possibly a CinGG multibit version will be needed

https://cinelerra-gg.org/download/CinelerraGG_Manual/Cinx_aBita_Confusion.html

https://cinelerra-gg.org/download/CinelerraGG_Manual/Multibit_build_x265_8_10_12.html#1445

9

Thank you, @terje

Its very kind of you to provide me with a starting-point for experimentation with the Cineform codec. Thank you also for the links to relevant parts of the manual regarding multibit.

10

Thank you @andreapaz for sharing your perspective on the challenges of adding a color-management system to Cinelerra; and for citing this discussion to the developers.

Some more research suggests that OpenColorIO is a good-solution for color-management but, as you note, the challenge is in implementing this code in Cinelerra. Already OpenColorIO is present, and functioning, in some other video-editing systems. However none of these editing-systems have the gravitas that comes with Cinelerras long-history, and reputation as a robust, open, mature system.

It would be preferable for someone (or a group) with existing knowledge of the Cinelerra code to implement OpenColorIO. The challenge our movie-production-team faces, as newcomers to Cinelerra, is that rolling-our-own integration of OpenColorIO is doubly hard: Not only would we need to recruit programmers to implement OpenColorIO, but we would, first, need those programmers to familiarize themselves with the existing Cinelerra code. This latter task would be the time-consuming bit.

If it was clear where, and how, to plug OpenColorIO in to Cinelerra, then I feel we, as a movie-production team, would have a more plausible case for investing in a programming-group to implement OpenColorIO. For now, however, we are more likely to navigate around the color-management problem without programming a solution; at least at this stage.

Thanks again!

11

Thank you, @skinkie for sharing your experiences using Cinelerra in a professional television-production-editing scenario. Its great to hear that you are achieving good results while navigating around the current color-management pipeline.

Thank you also for your suggestions on some working-practices when using the Cinelerra editing-system. Its interesting to hear from someone who is using Cinelerra for broadcast-ready work.

Thanks again!

12

@nostromo

Response from Andrew-R

Interesting.I looked at color management via lcms2 but last time I checked it was CPU-only and I havent found simple way to hook it up to anything but very limited ffmpeg use. In theory lcms2 can be taught about GPU processing but currently open-source version lacks it. [question] How hard it might be to support OpenCL? · Issue #413 · mm2/Little-CMS · GitHub I am not sure how opencolorio works, it may introduce c++17 as requirement. just bunch for HDR (not really same as color management) links I still have open … GitHub - astiob/mplayer2: An archive of mplayer2 with additional patches. Not actively maintained. · GitHub uses lcms2 at playback time, mpv does the same but more complex for me to even attempt to understand GitHub - 9prady9/CLGLInterop: OpenCL-OpenGL Interop examples · GitHub opengl-opencl interoperability example, I was hoping to hook this into our existing opengl acceleration but on my nouveau-driven Kepler NVIDIA card it still does not work? GitHub - docdude/ofxRPI4WindowHDR · GitHub rpi4/linux specific HDR example? What is the secret to Final Cut Pro X’s color management? how big shots were doing it … Note, on my laptop hackintosh I do not have opencl acceleration. How to analyze an HDR video for peak brightness level for the setting of metadata? - Doom9's Forum someone wrote python tool for going over whole final vid and compute some hdr params so x265 encoder (say) can use it. GitHub - OpusGang/awsmfunc: awesome VapourSynth functions · GitHub HDR Video Part 1: What is HDR Video? — Mystery Box just overview of HDR video [ANNOUNCE] Wayland/Weston/Mesa HDR support (proof of concept) old (2017) patches and thoughts on hdr video in Wayland. Today it may work in Wayland/kde6, but I am not sure if Xwayland (what cingg realistically will use in Wayland session) can use this in any way? https://photographylife.com/how-to-calibrate-dell-wide-gamut-monitors wide-gamut monitors on Windows The openicc Archives OpenICC was supposed to be color management system for X but wayland happened … mostly looked at it for wide-gamut monitor handling in Linux. I have compiz 0.8 plugin build, but due to my edid-eating cable it does not work :slight_smile: our/mesa bug with nouveau (dri3 related) Making sure you're not a bot!

13

@nostromo

I can add that I have also tested to transcode a 10-bit Prores 422HQ FHD clip (recorded on my previous working BMD Hyperdeck shuttle 2) to Cineform (left out the Pcm audio).

As shown from the output below, my i7-12700 cpu reached here fps=255 or speed=10.2x.

Both this and the previous Cineform output file, are tested at least can be loaded in CinGG, beside OK playback with VLC and FFplay. My Linux system is openSUSE Tumbleweed Slowroll, enhanced with Packman enabled video and multimedia codecs, also regarding ffmpeg-7.

For technical details information follows selected output:

ffmpeg -hide_banner -i hd01.mov -c:v cfhd -an cfhd01.mkv[aist#0:1/pcm_s24le @ 0x55ef65252100] Guessed Channel Layout: hexadecagonalInput #0, mov,mp4,m4a,3gp,3g2,mj2, from hd01.mov:Metadata:creation_time : 2016-02-23T23:49:21.000000ZDuration: 00:01:11.28, start: 0.000000, bitrate: 200496 kb/sStream #0:00x1: Video: prores (HQ) (apch / 0x68637061), yuv422p10le(bt709, top coded first (swapped)), 1920x1080, 182130 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 2500 tbn (default)Metadata:creation_time : 2016-02-23T23:49:21.000000Zhandler_name : Apple Video Media Handlervendor_id : applencoder : Apple ProRes 422 (HQ)Stream #0:10x2: Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, hexadecagonal, s32 (24 bit), 18432 kb/s (default)Metadata:creation_time : 2016-02-23T23:49:21.000000Zhandler_name : Apple Sound Media Handlervendor_id : [0][0][0][0]File cfhd01.mkv already exists. Overwrite? [y/N] yStream mapping:Stream #0:0 → #0:0 (prores (native) → cfhd (native))Press to stop, [?] for helpOutput #0, matroska, to cfhd01.mkv:Metadata:encoder : Lavf61.1.100Stream #0:0(eng): Video: cfhd (CFHD / 0x44484643), yuv422p10le(tv, bt709, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 1k tbn (default)Metadata:creation_time : 2016-02-23T23:49:21.000000Zhandler_name : Apple Video Media Handlervendor_id : applencoder : Lavc61.3.100 cfhd[out#0/matroska @ 0x55ef652522c0] video:3421736KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.002341%frame= 1781 fps=255 q=-0.0 Lsize= 3421816KiB time=00:01:11.24 bitrate=393480.0kbits/s speed=10.2x

du -sh hd01.mov cfhd01.mkv1,7G hd01.mov3,3G cfhd01.mkv

ffprobe -hide_banner cfhd01.mkvInput #0, matroska,webm, from cfhd01.mkv:Metadata:ENCODER : Lavf61.1.100Duration: 00:01:11.24, start: 0.000000, bitrate: 393480 kb/sStream #0:0(eng): Video: cfhd (CFHD / 0x44484643), yuv422p10le(tv, bt709, top coded first (swapped)), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn (default)Metadata:HANDLER_NAME : Apple Video Media HandlerVENDOR_ID : applENCODER : Lavc61.3.100 cfhdDURATION : 00:01:11.240000000--------------------------

Basic system info:

inxi -bSSystem:Host: localhost.localdomain Kernel: 6.9.7-1-default arch: x86_64 bits: 64Console: pty pts/1 Distro: openSUSE Tumbleweed-Slowroll 20240605Machine:Type: Desktop System: Gigabyte product: Z790 AORUS ELITE AX v: N/Aserial: N/AMobo: Gigabyte model: Z790 AORUS ELITE AX v: x.x serial: N/A UEFI: AmericanMegatrends LLC. v: FF date: 08/28/2023CPU:Info: 12-core (8-mt/4-st) 12th Gen Intel Core i7-12700KF [MST AMCP]speed (MHz): avg: 1364 min/max: 800/4900:5000:3800Graphics:Device-1: Intel DG2 [Arc A750] driver: i915 v: kernelDevice-2: Microdia Camera driver: snd-usb-audio,uvcvideo type: USBDisplay: server: X.org v: 1.21.1.12 with: Xwayland v: 24.1.0 driver:gpu: i915 resolution: 2560x1440~60HzAPI: OpenGL v: 4.6 vendor: intel mesa v: 24.0.8 renderer: Mesa Intel ArcA750 Graphics (DG2)Network:Device-1: Intel Raptor Lake-S PCH CNVi WiFi driver: iwlwifiDevice-2: Realtek RTL8125 2.5GbE driver: r8169Drives:Local Storage: total: 10.2 TiB used: 6.86 TiB (67.3%)Info:Memory: total: 128 GiB available: 125.64 GiB used: 3.46 GiB (2.8%)Processes: 468 Uptime: 0h 25m Shell: Bash inxi: 3.3.35

14

Its always cool here to have people who make films and participate to cin and the community.

What I can say about cinelerra it is super efficient without any bloat. Its build to perform on editing.

Cinelerra is super universal at import and export. The maintained FFmpeg implementation is really good.

Its the most efficient performance solution I know for import, cut and export.

If your workstation can handle a certain filetype storage or CPU wise, you will be able to playback your files nearly without overhead. This is extra-ordinary performance. If youre using a 15 years old computer you of course wont be able to playback your 6K files or whatever your plan is. IMHO if youre a professional you neednt worry about that.

You can prepare intermediate formats like cineform or dnxhr with FFmpeg before import to cin, but you dont have to if you use proxy.

At export you choose from a variety of formats which are best suited for your workflow for archive or for re-import somewhere else. This is a FFmpeg thing, not a cin one I think.

You can additionally activate background rendering to ensure fluid playback at timing-critical scenarios when fades, camera XYZ, Plug-ins and so on are used.

You can use your GPU for rendering. That should have a better rendering performance (in my case ~35% faster and lower CPU tmax [-> lower t = higher boost = no throttleing = higher CPU performance = better renderingefficiency]).

Here some detailed comparisons: How GPU acceleration affects Render Performance – Video Editing – Artists Forum for Cinelerra GG Community

Quadro p2000 is an old and entry-level mobile solution which is likely to get drivers from nvidias legacy driver channel soon.

You got a lot of information. Try out whether it fits your needs or not.

15

@nostromo

And a better Cineform encoding example found on a FFmpeg Cheat Sheet

ffmpeg -i input.mp4 -c:v cfhd -quality 8 output.mov