> On Aug 14, 2024, at 18:05, b...@gget.it wrote: > > >>> Do you think it would be worth developing a command-line option so that >>> exact cutting with minimal re-encoding would be easier? >> >> How do you plan to figure out the options needed to be passed to each >> and every encoder, so that it'll produce compatible output to enable the >> necessary concatenation of old and new encoded data? >> >> That's by far the biggest roadblock I see with this. > > I see. You're right, then this technique is probably a dead-end... > > More generally, which is the recommanded way to cut a video with a specific > starting point and specific length, with minimal re-encoding? > Millions of hours of CPU-time are probably wasted to reencode > already-perfectly-encoded content, just for cutting ;)
Only do remux without transcoding, and let mp4 muxer use editlist to strip the timeline from IDR to the requested start time. The preroll at the beginning can be slow when playback, but seeking also has the same preroll Other choice is use multiple groups of SPS/PPS in mp4 sample description. We have that support in mp4 demuxer, but not in muxer. It’s standard in specification but not widely supported. So if we add support to muxer and it works with our own demuxer, it’s not surprise to experience a lot of compatibility issues with other software. > > Are there already promising dev attempts in the direction of a feature able > to cut with minimal re-encoding? > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
