Based on Georgy's email (
https://www.mail-archive.com/[email protected]/msg09216.html) and
his further explanations, I would like to propose an addition to the manual
regarding an important aspect of CinGG's operation. I am attaching a
document and link to an image (https://i.postimg.cc/KjD1SXZS/AV-sync.png).
If you can improve, correct, and add information, we can then consider
modifying the manual.
Adjacent Edits in timeline

In \CGG{}, it can happen that two consecutive pieces of footage (edits) in a 
video track are not exactly adjacent to each other in timeline, so that in 
between there is a tiny (narrower than one single frame) empty segment in the 
track where there is no video at all. This happens when the next edit is 
attached to the preceding one, in which the lengts of audio (quantified in 
units of audio samples, at let's say, 48000 Hz) is slightly more than the 
length of video (quantified in frames, at let's say 30 Hz). If this is the 
case, \CGG{} can blink with a black frame at this position. See fig ...
The figure shows that edit 2 (audio and video) should be placed next to edit 1 
(audio and video) at position A, so that they are adjacent. Instead, edit 2 is 
positioned at position C, which is the next frame. This is because the audio 1 
samples are longer than determined by the fps of video 1. Edit 2 cannot even be 
placed next to position B, i.e., at the end of audio edit 1, because this is 
within a single frame and the program only works discretely from frame to frame.
This difference can appear at any stage, reading source, editing/compositing, 
rendering the result. The desynchronization can even accumulate and become 
worse.
The cause is probably the way in which \CGG{} internally resamples the media to 
conform it to the project settings. The source media are allowed to be in 
different formats, have different framerates/samplerates from that of the 
project. If this is the case, \CGG{} tries to resample them, this is resource 
consuming and not very accurate, leading to desync and black blinking frames. 
For example, if the source media has VFR (variable frame rate) formats, the 
program will definitely perform its own internal resampling. The rendering 
phase can also be affected by desync, as can cutting, splicing, and 
overwriting. Desync does not always occur (and worse still, propagate during 
the editing phases), but if it does occur, the cause is probably internal 
resampling. Codecs and formats can also affect desync or the functionality of 
\CGG{} for audio/video synchronization via waveform or “GoTo.”
A first solution is to prevent the problem by using source media with settings 
identical to those of the project, or transcoded externally to the project 
values before being imported into \CGG{}.
If, on the other hand, we notice blinking black frames during editing or in the 
final rendering, we must cut away the excess samples from audio edit 1 (A-B 
region) to allow for precise alignment of audio/video edits 2 on A point. If 
the user sets Settings --> Align cursor on frames in the Program window menu 
and manually cuts out this tiny empty segment, two edits segments become 
exactly adjacent and black blinking disappears.
_______________________________________________
Cin mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to