[Cin] Cinelerra CV direct copy feature demo
Andrew Randrianasulu
randrianasulu at gmail.com
Wed Nov 2 20:28:52 CET 2022
ср, 2 нояб. 2022 г., 19:19 Andrew Randrianasulu <randrianasulu at gmail.com>:
>
>
> ср, 2 нояб. 2022 г., 17:59 Terje J. Hanssen <terjejhanssen at gmail.com>:
>
>>
>> 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....
>
>
>
> https://github.com/cinelerra-cv-team/cinelerra-cv/commit/0ff51f4c53e17ff33701e8cc1096de33a87313b9
>
>
> 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....
>
> https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=157600
>> https://www.kevinmonahan.net/?p=88
>>
>
>
> thanks for links, will look into them.
>
>>
>>
>> And maybe also another CinGG theme "HDV on a Blu-ray without re-encode"
>> as discussed earlier, is related and needs some manual update?
>>
>> https://cinelerra-gg.org/download/CinelerraGG_Manual/HDV_on_Blu_ray_Disc_Without.html
>>
>
this one not dealing with cutting your footage, just author disk with
bdwrite :)
for cutting without reencoding you probably should test some ideas
discussed in
https://github.com/mifi/lossless-cut/pull/13
namely order of ffmpeg params and also
'-avoid_negative_ts', 'make_zero' params.
So, theory of operation you scan your media with ffprobe and it produces
list of timecodes where you *can* cut files safely. Then you can probably
output your cut-only edit as edl from Cinelerra and use it as input for
ffmpeg-based script doing cuts, with some math inside considering that
portions you can copy and that need reencoding.
https://github.com/mifi/lossless-cut/pull/13#issuecomment-279226516
But for this to works ffmpeg-based cutter should be accurate nearly always
...so testing on real HDV files (often hours long) very much needed (you
can put your source files on r/o mounted fs just for avoiding bad
surprises with ffmpeg output).
usual bad surprises include blank frames, bad/no play, sound
desynchronysing ....not something you hoped for while wishing for
-lossless- cut.
One can ask why bothering with NLE? well, timecode display and
bidirectional framestepping ....
>> https://www.mail-archive.com/cin@lists.cinelerra-gg.org/msg03520.html
>>
>
also IgorV recently rediscovered some scripts from old times, some of them
hope to produces avchd disks as readable by Sony's PS3 for example (they
used closed-source tsmuxer, but i hope opensource version works for now)
https://github.com/IgorVladimirsky/cinelerra-scripts-from-code.google.com/blob/main/mov2m2ts-1080p50.sh
those scripts reencode, so not very topical for cutting but might be
interesting evening read anyway.
https://github.com/IgorVladimirsky/cinelerra-scripts-from-code.google.com/blob/main/render-1080i50.sh
make_m2ts_avchd_dvd function namely
>>
> 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 ...
>
> https://github.com/NatronGitHub/Natron/issues/555
>
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20221102/ff6c88a0/attachment-0001.htm>
More information about the Cin
mailing list