ср, 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.... > > 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/[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
