чт, 3 нояб. 2022 г., 01:58 Terje J. Hanssen <[email protected]>:
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/0ff51f4c53e17ff3370...
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
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_Wit...
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.
since those times some progress was made in ffmpeg in bluray pcm audio. Can you try -c:a pcm_bluray in latest ffmpeg 5.1, with some-hdv-file as input ? c:v copy for video, obviously ... and tsmuxer for final mux/author.... biggest problem (for now) is lack of testing hardware, I mean picky hw players .... Also, may be Phyllis a bit lost in all those threads, so posting separate mail with your suggestions for manual section might help? full ffmpeg/mediainfo output probably not needed but some tricky options or un-intuitive switches better to be documented. In simplest case it probably will be as simple as ffmpeg -i file.mts -c:v copy -c:a pcm_bluray output.ts and then using tsmuxer template for cmd line or in gui for remuxing this ts into bd folder or directly into iso (actually udf) or try new bdwrite too (exactly like described in manual) and see if it authors disk playable on your hardware. then we hopefully can update manual text and move into lossless cutting matters ) 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/bl...
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/bl...
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 ...