 |
I looked at the dump again more thoroughly and have still not found any "smoking gun". The same code (cinelerra and libraries) is executed whether it has a bitrate of 4 MB or 8 MB. That is why I still think some resource is being exhausted, but this usually shows itself in the dump with weird numerical/nonsensical values and I see none of those. I did look at the disassembly of the executed code as provided in the dump with line 20 below being the code executing when it crashed - this code could be anywhere! in the program so I am clueless. Disassembly: 0: 00 ba 20 00 00 00 add BYTE PTR [rdx+0x20],bh 6: 4c 63 83 24 93 00 00 movsxd r8,DWORD PTR [rbx+0x9324] d: ff 93 c8 bb 00 00 call QWORD PTR [rbx+0xbbc8] 13: 48 8b 44 24 60 mov rax,QWORD PTR [rsp+0x60] 18: 48 83 c4 40 add rsp,0x40 1c: 48 c1 e0 06 shl rax,0x6 20: 4c 8b 94 03 10 18 00 mov r10,QWORD PTR [rbx+rax*1+0x1810] 27: 00 28: 4d 85 d2 test r10,r10 2b: 74 2d je 0x5a 2d: 44 89 e8 mov eax,r13d 30: 45 89 e1 mov r9d,r12d I have completely run out of ideas so it looks like the only workaround is to use a different render format or smaller bitrate. Not sure if it is the O/S and I could not get CinGG from Elive to work on my 32-bit system (it installs and comes up but then just hangs and it is probably due to my total lack of experience). Oh, in case anyone else missed this the dump shows that the CinGG program was built EXE: built: Feb 3 2021 17:00:52 -- that is 2021, not 2022 so there is more changes than what I previously stated. P.S. we are aware that "vaapi" renders will crash in the AppImage unless the level of library code is an exact match of the computer on which Cinelerra was built. |
 |
Yes, the difference between intraframe and interframe codecs is always very big. With intraframe the frames are all retained, more or less compressed. With interframe, a lot of frames are removed, which are then more or less reconstructed. I took your example clip and duplicated it to 1440 frames (58 sec). Rendering in mp4 @9Mbit results in a 68 MB file. DNxHR_proxy produces a 271 MB file (but of insufficient quality, it serves only as a temporary proxy). DNxHR_SQ --> 844 MB and DNxHR_HQ --> 1.2 GB. I guess you used the higher quality DNxHR (444 or HQX), they are useless starting with a 420p interframe. You could try avcintra_100.mxf (130 MB), which is more compressed (and lossy) but still intraframe. |
 |
OK, through the manual I found mxf, which I hadn't noticed before. The DNxHR options produce some pure quality but massive files... 1 min @6Gigbytes! But there is also mpeg2 as well, and h264, which I can use with high bitrate. No crash just now, but I only tested 1min with each. Yes crashes earlier were with the Appimage. |
|
|
If you don't have space/transfer rate problems, I recommend DNxHR which always guarantees quality and efficiency during editing. You can see an overview of codecs and formats in the manual: https://cinelerra-gg.org/download/CinelerraGG_Manual/Overview_on_Formats_Codecs.html However you have too many problems with rendering, you must have something wrong with your system (maybe some missing dependencies?). |
|
|
The MPEG render option doesn't export the audio. What output format would you recommend for a high quality file than can be edited later on? Where is MPEG2? I set output to MPEG-2_vaapi and the prog crashed on hitting OK to render. |
|
|
Unfortunately, I cannot reproduce the crash. I have tried h264 with 1 - 3 - 6 and 9 Mbit. @Andrew, can you you examine the dump to figure out the cause of the crash? |
|
|
@quintao And today's crashes are with AppImage?? instead of Elive package? I will test with a much bigger file here and use bitrate @8Mbit -- my current "guess" is that some resource is being overrun. Without being able to create the problem here, there is no way to fix it. |
|
|
More crashes today. Any bitrate @3Mbit or higher, both h264 and h265. Encoding @1Mbit succeeded. Two effects, colour balance and contrast applied throughout. Encode to MPEG @6Mbit succeeded. |
|
|
It is difficult to compile CinGG with system ffmpeg; you have to use the --without-thirdparty option and also disable dv, dpx and something else I don't remember. I succeeded only because of Andrew's help. There is a thread on the mailing list but I can't find it. Better to use CinGG's internal one which, I believe, will soon be upgrading from 4.4 to ffmpeg 5.1. It is not directly mentioned in the manual. You can see chapter 1 "installation" and the appendix "Developer Section". |
|
|
Re. Ffmpeg, I really don't know which one would be used by cinelerra, the system ffmpeg or the inbuilt one. Does the manual explain about it? In any case, I just downloaded ffmpeg 5.0 |
|
|
@Andrea_Paz Elive has both 64 and 32 bit. But anyway I do have a 32-bit 11 Debian partition and will see if I can install Elive Debian there and test. |
|
|
Am I wrong or is Elive 32 bit? Recently there have been problems with 32-bit Debian 10-11, although they should be fixed now. Do you use system ffmpeg instead of CinGG's internal ffmpeg? That could give problems as well. |
|
|
Ok, first segfaults happened with cinelerra-gg_5.1.202103+git Updated recently to the cinelerra-gg_5.1.2022+03+git package from elive repo and still got segfaults. Format: ffmpeg mp4 h264, bitrate 4000000, 1920*1080 I have ffmpeg 4.2 built from source on my system, could that interfere? |
|
|
@quintao The one major new thing in the code starting in March was the addition of Alt-h for Help and that would take more memory but it sounds like you are watching the memory usage from your initial description. |
|
|
@quintao You are right, the indexes would have been rebuilt when you ran as root. I wish it were that simple that it is just the package install, but that would be unusual. Which version did you have installed before March and which version is now giving the render issues? AppImage?? your own build ?? which render options are you using ?? The dump is not leading me to any insight, but I can only do the simplest of dump analysis. Will continue to see if I can reproduce the crash. |
|
|
When I ran as root for the debugging, surely the indexes were rebuilt? Must have been something with the package install messed up somewhere?? |
|
|
I think we are sorted. No segfault with the Appimage. I will always use that from now on. Was using the elive package before. Thanks for helping out. |
|
|
@quintao Have you done a "rebuild index"? This has been known to resolve this type of problem when other people (Andrea and myself) can not reproduce the error. This can be done in the Resources Window after the Media is loaded. You can rebuild all indexes in the Settings, Preferences, Interface, Index area - it will slow down as every loaded file has to rebuild indexes the first time (indexes help to play faster). I will continue to edit your test file a lot and then try rendering some more. I will also load it in an earlier version to see if the updated version is causing the problem, but I have looked at the March changes in the releasenotes.pdf and see nothing that should affect rendering at all. Or perhaps you updated from an earlier version and I should be checking for changes since version dated ??? |
|
|
I tried a few renders of your example and other sources as well. All OK. I used both CinGG compiled by me and appimage. I use arch linux. Unfortunately, I cannot install devuan on vm so I could not test it. Try CinGG appimage. |
|
|
It's also not immediate crash, could reach 80%, sometimes less. I keep an eye on memory, I have 16Gig. Normally it's around 11 or 12 Gig used during a render. |
|
|
No batch render. No farm. Just direct from render dialog |
|
|
Sample mp4 file here https://mega.nz/file/srY3VTiA#tZ4qb0kk0mbAwqE6yYiNUz6xLvf_GgJ7r5vVsDTx694 |
|
|
Are you using batch render? Render farm? Are your projects all 10-bit mp4? I can try to test if you tell me the steps you followed to render. |
|
|
cin-dump (364,339 bytes) |
- Anonymous
