View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000677 | Cinelerra-GG | Bug | public | 2026-06-23 07:55 | 2026-07-06 19:13 |
| Reporter | quintao | Assigned To | PhyllisSmith | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | AMD Ryzen 3700X | OS | Linux | OS Version | Devuan Beowulf |
| Summary | 0000677: Mxf files have no timestamps | ||||
| Description | Previously, like in 2025, I had been rendering to ffmpeg > mxf > avcintra 100, for its balance of good q and liw file sizes. These files are then burned in handbrake to produce sharable movies. Haven't made any renders this year and had to make a movie just now. Put the mxf in hb and it can't read the video stream, outputs only audio. I was asking Krave AI what i could do, and it told me to remux the file with ffmpeg, but ffmpeg (just built it from git) reports no timestamps and aborts. So my question is, has cinelerra changed the output format of avcintra? Are there any format settings that could resolve this so that output mxf files contain timestamps? I tried these options: mxf_opmode=1a frame_rate=60000/1001 | ||||
| Steps To Reproduce | Render to mxf avcintra 100 Open output file in handbrake Try to output to any format h264 or h265 etc --files produced by cinelerra in 2025 are ok and produce video/audio mp4 --files produced now output no video | ||||
| Tags | No tags attached. | ||||
|
|
Using Cinelerra May 2026 |
|
|
None of the presets with MXF containers work for me: AVC, DNxHR, etc. However, the same codecs in MOV containers work fine for me. Outside of CinGG, when using a GUI for FFmpeg (I don't use HandBrake, but Shutter Encoder), the rendering process (avc_intra_100; mxf) goes smoothly. |
|
|
Yes,, with Mov container, files are good, but huge bitrate with large files. No option similar to avcintra 100. Mxf DNxHF did work for me, but then lossless and huge files. |
|
|
@quintao @Andrea_Paz Like Andrea, a simple render using mxf did not work for me either. I will test first to see if I can get mxf render to work, then check for missing timestamps. Will check an older version from 2025 since quintao reports it was working then. May have some followup questions for specifics. |
|
|
@Andrea_Paz "None of the presets with MXF containers work for me: AVC, DNxHR, etc." Finally the following worked for me: mxf_DNxHR_444.mxf, mxf_DNxHR_HQ.mxf, mxf_DNxHR_HQX.mxf, mxf_DNxHR_proxy.mxf AFTER I changed Settings->Format to samplerate of 48000 (my default was 44100, but other samplerates besides 48000 may work too). Before that I was getting the errors: FFMPEG::encode_activate: write header failed /tmp/avc.mxf err: Operation not permitted However, mxf_avintra_100.mxf is NOT working for me yet, even without the audio and getting these errors which are really interesting: FFStream::write_packet: write packet failed. file:/tmp/avc.mxf err: Not yet implemented in FFmpeg, patches welcome FFStream::encode_frame: encode failed. file: /tmp/avc.mxf err: Not yet implemented in FFmpeg, patches welcome FFMPEG::mux_video err: Operation not permitted FFStream::write_packet: write packet failed. file:/tmp/avc.mxf Keep in mind that I am not using the AppImage, but an older Fedora with a complete build/compile. |
|
|
@quintao @Andrea_Paz Testing with May AppImage and getting errors when using mxf_avcintra_100.mxf as mentioned in the last note, i.e. FFStream::encode_frame: encode failed. file: /tmp/avc.mxf err: Not yet implemented in FFmpeg, patches welcome I believe the upgrade to FFmpeg 8.x is the root cause as in 2025, we were still at FFmpeg 7.0 before the latter half. Later I will verify that the problem did not exist at FFmpeg 7.0. |
|
|
@quintao @Andrea_Paz Using 2025 AppImage that you can still download on the cinelerra-gg.org website in images, i.e. CinGG-20250228-x86_64.AppImage, I believe mxf_avcintra_100.mxf works as expected. This is consistent with the report by Quintao. Meanwhile, I will ask Andrew-R if someone has added a patch as suggested in the error message to FFmpeg ("err: Not yet implemented in FFmpeg, patches welcome) as he is good at researching that kind of thing. Waiting for feedback from Quintao and Andrea and Andrew. |
|
|
@quintao @PhyllisSmith [for the render I used the mxf_pcm16.mxf and mxf_avcintra_100.mxf preset] Even with the patch, the render still isn't working. In the terminal, I have: FFMPEG::encode_activate: write header failed /home/paz/test_avc.mxf err: Operation not permitted Render::render_single: Session finished. Changing settings --> format --> samplerate to 48000, the render works, but I get a long series of lines in the terminal: [...] FFStream::write_packet: write packet failed. file:/home/paz/test_avc.mxf err: Not yet implemented in FFmpeg, patches welcome FFStream::encode_frame: encode failed. file: /home/paz/test_avc.mxf err: Not yet implemented in FFmpeg, patches welcome FFStream::flush failed :file:/home/paz/test_avc.mxf err: Operation not permitted Render::render_single: Session finished. ** rendered 4726 frames in 40.506 secs, 116.674 fps |
|
|
@quintao @Andrea_Paz Andrew-R has provided a fix which I am testing, but alternatively if that does not work, the below note is a temporary workaround. ------------------------------------------------------------------------------------------------------ This render formkat is now working for me and I will check it into the source base, but you can modify the current mxf_avcintra_100.mxf parameters by adding just the extra 2 lines as follows (edit using the wrench (after the line avc-intra=100) keyint_min=25 x264-params keyint=25 In addition, I was only able to use the mxf render formats if I set Settings->Format-> Audio samplerate to 4800 Contents of file mxf_avcintra_100.mxf: mxf libx264 # must set Audio samplerate to 48000 if rendering audio too # cin_pix_fmt=yuv422p10le avc-intra=100 # use framerate for 1 keyframe/sec, needed for seeks keyint_min=25 x264-params keyint=25 |
|
|
@quintao @Andrea_Paz Checked into the source base, the patches that Andrew-R supplied which added g=1 since per Andrew's explanation, all frames are keyframes. A new AppImage which includes the changes made will be available on July 1. |
|
|
Yeah it seems that MXF container is really strict in itself (at least ffmpeg/libavformat muxer is struct now) It really does not support any audio samplerate outside of 48Khz (tested by trying to encode random flv with 22khz sound to it. ffmpeg 8.1.2 produces more verbose message about limitations) h264 can be long-gop, but random framerate also seemingly unsupported, I tried 12 fps video and it was refusing to mux even with strict=-1 added to mxf_h264_b.mxf profile So, I think mxf_h264_b profile should be better for smaller, h264 constrained baseline profile files in MXF, but other restrictions still apply, so you may need to check Project parameters and move them as close to relevant broadcast/TV standard as possible (MXF mostly used in this environment) |
|
|
@PhyllisSmith Confirmed, these lines work for me in render video settings. While also removing the line cin_pix_fmt=yuv422p10le Handbrake now scans the output file correctly, without seeming to regress on the progress bar, and output from that has video stream. Ffmpeg 8.1 must need these extra options to output the file with good timestamps. Where can I save this file for mxf settings? In .bcast5? |
|
|
@quintao I think you used wrong profile for what you want to do. avcintra is specifically 422p10 (4:2:2 chroma subsampling with 10 bits per component) type of h264. for 8bit 4:2:0 (consumer video) you can try mxf_h264_b.mxf, with added strict=-1 possibly I also do not understand why you use handbrake (additional encode step). Is there something wrong with our other profiles, something missing? I think yes, for appimage you can enter profile name in Rendering window and hit save, and it will be saved in .bcast5 directory. But generally as long as you do not switch profile manually those settings remain there even across cingg reboots. |
|
|
@Andrew-R You are probably right, that I m using the wrong profile. I just wanted a high Q output for storage, but not too lossless and huge bitrate/file size. This avcintra 100 formt was actually suggested by someone here, can' t remember when. Handbrake is for ease of use, i can load files and add them to the queue and let them run. And it's easy to set constant bitrate or video dimensions with a few clicks. I'm well aware i can output directly from cingg, to h264 1mbps for mobile devices, and perhaps i just need to set up a profile for switching to. But when one set of raw files might produce 4 or 5 movies, it seems easier to render each one to a hq format and when I'm done using cinelerra I can load all the movies in hb, maybe 30 or so, and let it run. I am always open to learning and finding better workflows. Video editor then handbrake has been my workflow for the last 15 years. And i don't think cinelerra is missing any profiles, there really ample choice! Perhaps a Pb -> Au converter would be useful but that's asking a lot! Cinelerra will be my choice for years to come. |
|
|
Should I better use MOV -> h264 ? The bitrate is very close to avcintra, @ 24mbs. |
|
|
@quintao it really depend on software (or hardware!) used at the other side. Handbrake is based on same libav* set of libraries like ffmpeg and many other programs. If it eats cingg-produced movs correctly, no a/v desync, no color shifts, etc - then go for it. Archival use tend to have different meaning for home users and archivists - archivists naturally hope for more like lossless format, no matter how slow it for decode (in some usable range). You can try to set b=24M in mxf_h264_b.mxf profile (in addition to g=25 and strict=-1) and see if it serves you well. We need to add some #comments there about framerate/samplerate limitations, but IIUC for now Phyllis basically at night time relative to me here in Spb, so I try to answer some questions because I finally dragged my password here (firefox on mobile Android tablet blow up in size to full unusability in 3Gb, so Chrome it is for now). In theory there is also batchrender function in cingg, but I never used it directly, outside of BD/DVD creation. :( For laughs and giggles there was "new" OSX build for ppc machines, so Handbrake works there on 10.6.8 but not on my more stable 10.5.8! I never used it on Linux, so I have no experience with it. |
|
|
Just for info, this is from AI Visually Lossless Quality: AVC-Intra is an intraframe codec (every frame is a complete image), making it far superior to long-GOP formats like H.264 for editing and preservation. It is widely classified as "visually lossless," meaning quality loss is negligible to the human eye, though technically some data is discarded. Industry Standard: It is a Preferred/Acceptable format for many broadcast archives (e.g., those using Panasonic workflows) and is explicitly listed as an Acceptable mezzanine format by institutions like the Library of Congress (often grouped with XDCAM HD). Container Robustness: The MXF wrapper (specifically OP1a) is highly robust, self-contained, and designed for long-term storage, handling metadata and essence streams reliably |
|
|
I do not understand this instant switchover to "AI" as data source, I still use old-style google and try to filter more relevant info with my brain ... Official documents usually best, but sometimes costly. |
|
|
Yes I mostly agree that AI takeover if human work is not good in many ways, but when snrching for information I have found it very time saving, as it can scan all over the web and summarise what wouud take hours to look up by old methods (stack excnhange answers or man pages etc). As an example, I have used it mostly for asking questions on how to write javscript and css, buiuding a website. It can mki mistakes and everything needs testing, using your own logic as well. But the amount of information it seems to 'know' on these areas is quite impressive. I'll give it my problem or code and et will tell me where I'm wrong. |
|
|
@quintao MOV is an excellent container format, compatible and well-suited for editing. It can contain both intraframe and interframe (LongGOP) codecs, and in addition to H.264 and H.265 (HEVC), it can also use their open-source counterparts, VP9 and AV1. Another option is MKV, which is a modern container format with a vast number of parameters that allow you to create the best preset for your specific needs. However, it is less widespread than MOV and therefore less compatible; I also experienced some minor performance issues with it. Additionally, you need to be familiar with the parameters to create your own optimized preset. Here are a few links recommending parameters to use for small-to-medium-sized (LongGOP) files that are visually lossless: https://academysoftwarefoundation.github.io/EncodingGuidelines/ https://academysoftwarefoundation.github.io/EncodingGuidelines/Encoding.html https://blog.frame.io/2017/02/13/compare-50-intermediate-codecs/ Just out of curiosity, what kind of video files does your camera or other source produce? Edit: I almost forgot: in CinGG, the presets can be found under both MOV and QT; they're the same MOV container. |
|
|
@Andrea_Paz I have tried using Mov, but full cpu power is not utilised on render. Is cingg muxer compatible with quicktime? Also mkv, I couldn't start the render, as perhaps the preset needs tweaking. My best clips come off my Nikon z6, which are Mov mpeg4, @50mbps, PCM audio. But i do have clips off a Panasonic Which are MTS BDAV @24M AC3. And my phone, Mp4 NTSC @19M |
|
|
@quintao Did you tried cinelerra/cinelerra-5.1/ffmpeg/video/h264.mov ? there is bunch of .qt profiles too. They are really .mov At some point I tested some of them with older quicktime versions (4 ... latest for 68k Macs! in emulation. And more modern like 6.x on OS 9.2) and they seemed to work? But of course regressions still possible ! Will try to re-check while I have Mac machine running |
|
|
@quintao Yeah, you're right—not being able to use all the CPU threads is an old problem that's always been there. The only solution is to use a render farm, but that involves extra work and wastes time. https://download.cinelerra-gg.org/files/CinelerraGG_Manual/Render_Farm_Usage.html CinGG supports QuickTime well, since Adam, the creator of Cinelerra, is a leading expert on this format. However, I don't think he's updated his program much, and consequently CinGG hasn't been updated much either; in fact, CinGG has largely shifted to using FFmpeg as its primary rendering engine. In any case, FFmpeg supports QT well; it's something about the way Cinelerra works that prevents it from using all the threads. You're right about MKV, too: just as MXF stopped working, my MKV presets aren't working anymore either. FFmpeg must have really introduced some hidden changes that are causing problems. Your source files are all from the MPEG family and are therefore compressed (LongGOP). When you render a compressed file, you’re adding compression on top of compression in an exponential manner; as early as the third rendering, you may notice artifacts, and the visual quality declines rapidly. But even if you don’t notice any artifacts, the loss of (irrecoverable) data is always present. There are two scenarios: 1) You accept this loss to keep processing times short and file sizes small, either by trying to reduce the number of renders needed or by using only the “demuxer/muxer,” thus without changing the codec. 2) A DI (or mezzanine) workflow is used, transcoding to a high-quality digital intermediate (ProRes, DNxHR, CineformHD, etc.) that is either uncompressed or uses minimal intraframe compression. This way, the source data remains unaltered throughout the workflow, and then, during the final rendering phase, you can choose the codec best suited for the intended use (including compressed formats). With these codecs, processing times aren’t significantly longer because they’re highly efficient and optimized; editing is faster and more stable, but file sizes are about 10 times larger. Furthermore, these high-quality formats are also suitable for backups and, above all, for archiving, without the need for specific formats (FFV1, lossless, etc.). If I understand your workflow correctly: you import the various sources directly into CinGG, edit them, and then export them using the old avc_intra_100.mxf codec (which no longer works). Then you batch-render all the files you’ve created in CinGG (using Handbrake) to create compilations or movies. In what format? At this stage, you might just want to remux the files instead of transcoding it. |
|
|
@Andrea_Paz I was also getting weird segfaults/extreme slowdowns on ffv1 mov/mkv presets on Termux. Turned out I had vulkan accel enabled, and only Vulkan device here is slow lavapipe! Disabling vulkan acceleration fixed ffv1 presets or me. Alternatively, you can set non-default coder for those ffv1 presets, but I am afraid ffv1 vulkan accel is in many cases not accelerating :( |
|
|
@quintao Try using the “av1_svt.mkv” preset (disable Vulkan hardware acceleration if you have it enabled). You can also adjust the parameters to achieve the desired quality and file size. Your CPU supports Intel’s AVX2 extensions, so CPU rendering is quite fast. AV1 is a good alternative to H.265, but it renders more slowly; the AVX2 instructions make it more efficient. In my tests, I’m able to render at higher fps than with HEVC. |
|
|
@Andrea_Paz I guess for shared movies, that ark only needed 1M or less one more encoding from the cigg output (2 pass as well if it helps) won't really show any q decrease.. At least people haven't noticed. I could hardly share a remuxed high q file at Gigabytes. Is there a render mode that cuts and remuxes the original input files, instead of reincoding to another format? The resulting 'cutup' or 'stitched up' file could then be encoded to smaller files as desired. |
|
|
Prob. a dumb question that last one, as cutting compressed files would only work on keyframes right? Best would be to decompress and cut/stitch render into the same raw format. When 100TB is @$100 it should be more feasible! |
|
|
@quintao Unfortunately, CinGG can't handle remuxing on its own; you'll need to use external programs such as Avidemux, ffmpeg, or Shutter Encoder. For example, Shutter Encoder does the same things as Handbrake, although it's less general-purpose and more specifically designed for video editing. Compared to Handbrake, it allows you to trim and remux files without re-encoding. It's available as an AppImage. An interframe video is divided into GOPs; the keyframes (I-frames) are the first and last frames of the GOP (or, more precisely, the first frame of the next GOP), while the internal frames (B-frames and P-frames) are calculated and created by the algorithm. When you cut an interframe video, in most cases the cut will fall within a GOP, so the encoder will have to create a new keyframe at that point, altering the original GOP and recalculating all the frames within the new GOP. Furthermore, although this new keyframe functions as an I-frame, it is not a frame from the original video but is created in a similar way to how B-frames and P-frames are created. This results in a continuous calculation that requires CPU resources, and it also leads to a loss of quality because an original frame is replaced with a frame created from scratch using “virtual” frames. These days, algorithms are highly optimized, so there isn’t a significant difference in processing time between intra- and inter-frames; moreover, the major compression codecs can take advantage of hardware acceleration, which provides an additional performance boost. Fun fact: Adobe Premiere was able to supplant Avid in the professional sphere precisely because it handled compressed codecs directly, while Avid was still required to always transcode to DNxHD (not anymore!). [Ironically, Premiere is now being supplant by DaVinci Resolve because the latter is much more efficient at handling compressed codecs. Adobe defends itself by stating that, in any case, it’s always better to transcode to a DI (ProRes) than to process compressed files directly!] I can’t predict the future, when AI will generate frames as it sees fit, without needing to keep the original frames as a baseline... |
|
|
@quintao The latest AppImage at https://download.cinelerra-gg.org has the fix in. If mxf_h264_b works for you, that avoids the large size of the output that the default mxf_avcintra_100 format -- but if you wan to continue using mxf_avcintra_100, then use the wrench in the video to delete the b=100m line. This change will remain in your HOME/.bcast defaults as long as you do NOT change your render format (for example just to look at mxf_h264_b and then go back, will change it). I will close this issue in a couple of days. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-06-23 07:55 | quintao | New Issue | |
| 2026-06-23 08:01 | quintao | Note Added: 0005825 | |
| 2026-06-23 16:06 | Andrea_Paz | Note Added: 0005826 | |
| 2026-06-23 16:16 | Andrea_Paz | Note Edited: 0005826 | |
| 2026-06-23 16:17 | Andrea_Paz | Note Edited: 0005826 | |
| 2026-06-24 05:24 | quintao | Note Added: 0005827 | |
| 2026-06-24 19:35 | PhyllisSmith | Note Added: 0005829 | |
| 2026-06-24 19:44 | PhyllisSmith | Assigned To | => PhyllisSmith |
| 2026-06-24 19:44 | PhyllisSmith | Status | new => acknowledged |
| 2026-06-24 20:47 | PhyllisSmith | Note Added: 0005830 | |
| 2026-06-24 20:48 | PhyllisSmith | Note Edited: 0005830 | |
| 2026-06-24 21:02 | PhyllisSmith | Note Added: 0005831 | |
| 2026-06-24 23:46 | PhyllisSmith | Note Added: 0005832 | |
| 2026-06-25 09:41 | Andrea_Paz | Note Added: 0005833 | |
| 2026-06-25 10:04 | Andrea_Paz | Note Edited: 0005833 | |
| 2026-06-25 10:05 | Andrea_Paz | Note Edited: 0005833 | |
| 2026-06-26 17:01 | PhyllisSmith | Note Added: 0005834 | |
| 2026-06-26 17:38 | PhyllisSmith | Note Edited: 0005834 | |
| 2026-06-27 00:52 | PhyllisSmith | Note Added: 0005835 | |
| 2026-06-27 00:52 | PhyllisSmith | Status | acknowledged => confirmed |
| 2026-06-27 06:41 | Andrew-R | Note Added: 0005839 | |
| 2026-06-27 08:12 | quintao | Note Added: 0005840 | |
| 2026-06-27 08:23 | Andrew-R | Note Added: 0005841 | |
| 2026-06-27 08:57 | quintao | Note Added: 0005842 | |
| 2026-06-27 09:26 | quintao | Note Added: 0005843 | |
| 2026-06-27 09:47 | Andrew-R | Note Added: 0005844 | |
| 2026-06-27 10:57 | quintao | Note Added: 0005845 | |
| 2026-06-27 11:09 | Andrew-R | Note Added: 0005846 | |
| 2026-06-27 13:53 | quintao | Note Added: 0005847 | |
| 2026-06-27 15:06 | Andrea_Paz | Note Added: 0005848 | |
| 2026-06-27 15:24 | Andrea_Paz | Note Edited: 0005848 | |
| 2026-06-28 07:35 | quintao | Note Added: 0005849 | |
| 2026-06-28 08:07 | Andrew-R | Note Added: 0005850 | |
| 2026-06-28 13:42 | Andrea_Paz | Note Added: 0005851 | |
| 2026-06-28 15:37 | Andrew-R | Note Added: 0005852 | |
| 2026-06-28 16:12 | Andrea_Paz | Note Added: 0005853 | |
| 2026-06-29 03:34 | quintao | Note Added: 0005854 | |
| 2026-06-29 03:43 | quintao | Note Added: 0005855 | |
| 2026-06-29 17:41 | Andrea_Paz | Note Added: 0005856 | |
| 2026-06-29 17:44 | Andrea_Paz | Note Edited: 0005853 | |
| 2026-07-01 21:48 | PhyllisSmith | Status | confirmed => assigned |
| 2026-07-01 21:48 | PhyllisSmith | Note Added: 0005858 | |
| 2026-07-06 19:13 | PhyllisSmith | Status | assigned => closed |
| 2026-07-06 19:13 | PhyllisSmith | Resolution | open => fixed |
