Den 02.11.2022 20:28, skrev Andrew Randrianasulu:
ср, 2 нояб. 2022 г., 19:19 Andrew Randrianasulu <[email protected]>:
ср, 2 нояб. 2022 г., 17:59 Terje J. Hanssen <[email protected]>:
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/[email protected]/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/[email protected]/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
--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin
