A bit of a conundrum really. I have reason to use some footage that has been stored on a hard drive for 3 years and has been edited in Cin before.
The clips are 2160p full range HEVC at either 200 or 400Mb/s, some are long-GOP and some all-i. I am not mixing the variations in Cin, they have just been tried for test purposes.
I opened a project via the .xml file and found one clip had not loaded correctly, the audio was full length, the video was short. I reloaded the clips as a new project, but the same clip was still short. Suspecting a corrupt file I reloaded from an external drive, but it was the same.
Some clips play in Cin with occasional black intervals i. e. showing a few full frames then a black frame or two, then full again. The same clips do not do this in a player. When rendered, some clips flash colour/black/colour/black rapidly upon playback, for their full length. I played with the cache size which made no difference and also rendered 2160p and 1080p. 1080p cured the problem during one all-i test. I am rendering to DNxNR_HQX and I tried ProRes HQ to no avail.
My Cin settings have not been changed, except for test purposes.
The same clips no not exhibit these problems in other NLEs.
If you have not already done this:
the first thing you should try is to "rebuild indexes" - either per clip in the Resources window or in the Settings-> Preferences, Interface tab for all index files and I would do the clip thumbnails too.
the second thing you should try is to start CinGG with default settings and to do this without messing up you current settings, type in a window:
CIN_CONFIG=/tmp/bcast1 {location of cinelerra}/bin/cin
Thanks Phyl
Neither worked, but removing the .bcast5 file (I parked it in the Wastebin) allowed the short clip to load fully and play without flashing. I will test some more clips to ensure all the glitches have gone, but is there anything else I should try before committing to the new .bcast5 file and starting resetting everything from scratch?
I can not think of anything else to try. Because so many modifications were being made previously with clips and just about everything else, it is very possible that settings in the .bcast5 are expecting some new or changed value that is causing problems.
Thanks again. I'm just going to crash ahead with the new .bcast5 folder.
what versions of Cinelerra-GG are you using?
What is the project format?
With which Cinelerra-GG version were these projects created, without any problem (Play, Rendering,...)?
In Cinelerra-GG, on the top-right of the Timeline there is the FF icon (o, at least, that
is what I see in SUV theme); usually it is set to FFmpeg first. Could you check?
Have you tested that with a small piece of footage, let's say 10 seconds?
If you can/want, could you share 10 seconds of a video that shows this problem, please? So We may test it.
Do you have suggestions anyway so that in the future these can be tried also? It would be helpful to me to know of other possibilities.
Igor, thanks for replying and offering to help.
I am using 21220531 and FFMPEG first is enabled.
The project formats vary as the camera was new and I was using a slightly different format each time for comparison. All are 2160p full range 10-bit 4:2:0 HEVC, some are long-GOP some all-i, some are 200mbps, some 400, some log, some not, all .mov.
The projects were created using whichever Cin release was current at the time, the first one June 2019, but this may be just a red herring (as we say here 😀 ), because when I finish a project I delete all except the raw (not RAW!) camera files and the reason there is an .xml file is because I have visited it more recently and saved my settings. As I said, when the problem first appeared I reloaded the clips without the .xml file as if it was a new project and it was the same. I reloaded again from an external back-up drive, still the same. I tested other projects from the same camera, all of which had the "flashing" on one or more clips. I knew it wasn't the clips as I tested them in other NLE's and they were fine.
Phyllis' reply prompted me to replace the .bcast5 file, which I temporarily parked in the Waste bin and that solved the problem.
@phylsmith2004
You are speaking about videos to test?
It is not easy to help somebody without a part of the video or project to test on our machines ( https://www.youtube.com/watch?v=aX6vPWW8n-I).
The only think I can do is to search in the WEB a video with a format that that user uses, or something that comes close.
For @DeJay issue I used a video I found time ago (see https://lists.cinelerra-gg.org/pipermail/cin/2022-January/004593.html).
You can download the video from https://www.eoshd.com/news/download-my-4k-hdr-10bit-h-265-videos-shot-with-the-panasonic-s1-firmware-v1-0/
Direct link to https://drive.google.com/open?id=1jcSp9JZR8eFKq9jTXNLbG5nFIjWhD8YJ
DeJay, it is hard to narrow the problem because you are saying that some footage are long-GOP (and it is bad for any NLE) some all-i and other thinks. Too many variables, sorry.
It would be fine to have a little piece of the Project that creates the problem.
Usually, when I do a Project I create a README.txt file where I write some info about:
Date, Description, Format Project, Rendering, Proxy, Cinelerra-GG version. I do this also for Graphics (GIMP, Inkscape).
After six months or more I don't remember how I did this or that; so it is better to write some notes.
My test are done using cinelerra-5.1-ub16.04-20201031.x86_64-static and CinGG-20220331-x86_64-older_distros.AppImage on UbuntuStudio_16.04-64bit.
I used P1000111.MP4 file. It is a hevc (H265) 3840x2160 @25.00 yuv420p10le.
Like I wrote in the MailingLists, because my Notebook is very old I must use Proxy (for the Timeline and editing). Rendering to H.264 and H.265 without Proxy (of course). Here it seems all good.
DeJay wrote:
Phyllis' reply prompted me to replace the .bcast5 file, which I temporarily parked in the Waste bin and that solved the problem.
Good to know that It solved the problem! Great Phyllis!
Below the info about P1000111.MP4 using ffprobe and mediainfo program to compare with DeJay footage.
ffprobe -hidebanner -i P1000111.MP4
Metadata:
major_brand : mp42
minor_version : 1
compatible_brands: mp42hvc1
creation_time : 2019-01-24 22:22:15
Duration: 00:00:06.24, start: 0.000000, bitrate: 29175 kb/s
Stream #0:0(und): Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(tv, bt2020nc/bt2020/unknown), 3840x2160 [SAR 1:1 DAR 16:9], 28756 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc (default)
Metadata:
creation_time : 2019-01-24 22:22:15
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 124 kb/s (default)
Metadata:
creation_time : 2019-01-24 22:22:15
handler_name : Panasonic Static Metadata
mediainfo P1000111.MP4
General
Complete name : P1000111.MP4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (mp42/hvc1)
File size : 21.7 MiB
Duration : 6 s 240 ms
Overall bit rate : 29.2 Mb/s
Encoded date : UTC 2019-01-24 22:22:15
Tagged date : UTC 2019-01-24 22:22:15Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main [email protected]@High
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 6 s 240 ms
Bit rate : 28.8 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Original frame rate : 50.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.139
Stream size : 21.4 MiB (99%)
Encoded date : UTC 2019-01-24 22:22:15
Tagged date : UTC 2019-01-24 22:22:15
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : HLG
Matrix coefficients : BT.2020 non-constant
Codec configuration box : hvcCAudio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 6 s 240 ms
Source duration : 6 s 293 ms
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 94.9 KiB (0%)
Source stream size : 95.5 KiB (0%)
Encoded date : UTC 2019-01-24 22:22:15
Tagged date : UTC 2019-01-24 22:22:15
DeJay, it is hard to narrow the problem because you are saying that some footage are long-GOP (and it is bad for any NLE) some all-i and other thinks. Too many variables, sorry.
It would be fine to have a little piece of the Project that creates the problem.
Yes, I understand, but it's not just one project that exhibits the problem. Perhaps I did not explain very well.
I want to use again a camera that shoots video with log profile, so for some colour correction practice I opened a project of which only the HEVC camera clips remain, plus there is an .xml file, obviously (only to me) from a re-visit at some time in the last three years and (again obviously) did not have this problem then.
When imported into Cin and the problems started to appear, I suspected corrupt files and re-loaded from an external back-up drive, but it was the same. I then tried other projects from that camera and had similar problems. None of the "defective" files showed problems in a media player, nor did they when imported into either Kdenlive or Shotcut, therefore it has to be something to do with Cin. After Phyllis' reply and neither suggestion working, it occurred to me to start a new .bcast5 file as a test and immediately the problems had gone, suggesting something in the .bcast5 file had become corrupted.
What I am saying is, I don't have any project that creates the problem, so there is nothing to give you a piece of.
By the way, to answer your comment, normally I would transcode to an all-i intermediate codec before editing.
Thank you very much for trying to help.
