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, we're 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. It's 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. I'm 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. We're very happy that Cinelerra GG exists, and we will share our process with the community as the project progresses.
Thanks!
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 https://github.com/einhander/cin-gg-packages/releases/tag/20240522 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.
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 I'm 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!
I'm 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 cfhd DEV.L. cfhd GoPro CineForm HD
Help with the cfhd encoder can be listed with
ffmpeg -hide_banner -h encoder=cfhd
I 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.mkv
frame= 5963 fps=465 q=-0.0 Lsize= 7906905KiB time=00:03:58.77 bitrate=271272.5kbits/s speed=18.6x
Comparing the input and output file sizes
du -sh hdv09_04.m2t cfhd09_04.mkv 745M hdv09_04.m2t 7.6G cfhd09_04.mkv
At 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
@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://www.cinelerra-gg.org/bugtracker/view.php?id=604
For Render Farm:
https://cinelerra-gg.org/download/CinelerraGG_Manual/Render_Farm_Usage.html
3) 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:
https://www.cinelerra-gg.org/forum/help-video/yuv-to-rgb-conversion-issues/
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.
4) 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 don't use and know the codec though so I can't 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.
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?
I'm 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, I'm sure that, for our initial project, we can work around the existing color-management system (or lack of).
Thanks again!
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://www.cinelerra-gg.org/bugtracker/view.php?id=238
https://www.cinelerra-gg.org/bugtracker/view.php?id=646
https://www.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, I'll try to cite this discussion, hoping for more technical contributions than I'm able to bring (I'm not a programmer).
https://lists.cinelerra-gg.org/pipermail/cin/2024-July/008385.html
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 Cinelerra's 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!
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 can't 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 😉
Thank you, @skinkie for sharing your experiences using Cinelerra in a professional television-production-editing scenario. It's 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. It's interesting to hear from someone who is using Cinelerra for broadcast-ready work.
Thanks again!
Response from Andrew-R
It's 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. It's build to perform on editing.
Cinelerra is super universal at import and export. The maintained FFmpeg implementation is really good.
It's 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 you're using a 15 years old computer you of course won't be able to playback your 6K files or whatever your plan is. IMHO if you're a professional you needn't worry about that.
You can prepare intermediate formats like cineform or dnxhr with FFmpeg before import to cin, but you don't 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: https://www.cinelerra-gg.org/forum/help-video/stats-for-gpu-render/#post-2854
Quadro p2000 is an old and entry-level mobile solution which is likely to get drivers from nvidia's legacy driver channel soon.
You got a lot of information. Try out whether it fits your needs or not.
