[Cin] Cinelerra CV direct copy feature demo

Wed Nov 2 23:59:04 CET 2022

Den 02.11.2022 20:28, skrev Andrew Randrianasulu:
>
>
> ср, 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....
>

There is also another program, "VideoCut" Version 2.1.1 - MP2/MP4 Cutter 
for Linux on base of mpv and ffmpeg. Cutting is lossless, the target 
file will not be reencoded.
https://github.com/kanehekili/VideoCut

>
>         https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=157600
>         <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 :)
>

Yeah, I see that.
But as we concluded, the manual section needs update, both on the HDV 
definition, and adding the procedures to transcode and remux HDV mp2 
audio into a Bluray compliant format.
https://www.mail-archive.com/cin@lists.cinelerra-gg.org/msg03521.html

>
> 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/26307cde/attachment-0001.htm>