On Fri Oct 28 02:35:53
CEST 2022, Andrew
Randrianasulu wrote:
Recorded with Cin-GG :-)
https://youtu.be/7pXG5cnjckQ
5min or so ....
I put in an extract of section 20.5 of the CinCV manual here:
http://cinelerra-cv.wikidot.com/cincv-manual-en:rendering-files
Most of the time you will want to bring in the rendered
output and fine tune the timing on the timeline. Also some file
formats like MPEG can not be direct copied. Because of this, the
jobs are left in individual files.
You can load these by creating a new track and specifying
concatenate to existing tracks in the load dialog. Files which
support direct copy can be concatenated into a single file by
rendering to the same file format with renderfarm disabled. Also
to get direct copy, the track dimensions, output dimensions, and
asset dimensions must be equal.
MPEG files or files which do not support direct copy have to be
concatenated with a command line utility. MPEG files can be
concatenated with cat.
By reading the parallell email thread "[Cin] fileexr/fileppm direct
copy support", I wonder if this isn't equivalent to some other NLE's
"Smart Rendering" or "by-pass re-encode/compression when possible"?
partially, but sadly not (yet) smart enough for dealing with non-i-only files ...
there was interesting piece of code potentially decompressing anything ffmpeg can decode in fileyuv in CinCV, but this need some encoding counterpart and also more info passing between assets, edits and renderer....
If so it would be fine to get this dealed with in the CinGG manual
....?
CinGG as for now accelerates _image sequences_ in this way, due to our de/muxer moved from dedicated libquicktime-based filemov.c into more complete but complex ffmpeg.c's libavformat de/muxer.
so, no hdv copy in this mode yet (at least automatic)
May be you can rig avidemux or ffprobe for noting hdv keyframes and set cuts in cin on those boundaries, but this is time-consuming....
thanks for links, will look into them.
As far as I understand problem for mpeg like codecs you must re-encode not just frames you altered, but also frames between your cut and codec-defined input keyframes, and this kind of info simply not wired inside cinelerra .... I'll try to download ffprobe-based I-frames finder as prototyped by Bill long time ago and play with its output as guidance for cutting mpeg2 like streams
but just for unexpected side of video decoding at some time Natron apparently had weird reordering problem on reading mp4 files, probably due to in-decoder reordering ...some fun (eh) to code for ...