[FFmpeg-devel] [FEATURE] Cut a video (-ss) with timings non-aligned on keyframes, with minimal re-encoding
Michael Niedermayer
michael at niedermayer.cc
Wed Aug 21 12:22:09 EEST 2024
On Tue, Aug 20, 2024 at 11:52:20PM +0200, Lynne via ffmpeg-devel wrote:
> On 20/08/2024 22:33, Michael Niedermayer wrote:
> > On Tue, Aug 20, 2024 at 02:36:53PM +0200, Lynne via ffmpeg-devel wrote:
> > > On 20/08/2024 14:13, basj at gget.it wrote:
> > > > > > 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.
> > > >
> > > > Thank you Zhao for your answer.
> > > >
> > > > Is there a feature already available in ffmpeg to use one of your 2 solutions?
> > > > Or is someone already working on this topic? (if so, can I join this feature development?)
> > > >
> > > > In any case, if someone has a solution, many people are looking for a solution for this, either here: https://stackoverflow.com/questions/63548027/cut-a-video-in-between-key-frames-without-re-encoding-the-full-video-using-ffpme (closed),
> > > > or here: https://superuser.com/questions/1850814/how-to-cut-a-video-with-ffmpeg-with-no-or-minimal-re-encoding.
> > > > It would help many people if a ffmpeg-expert could help on this :)
> > >
> > > AVTransport, the new container I'm working on, supports more flexible
> > > signalling of decoded but discarded refs. Still WIP so no support for it in
> > > FFmpeg, but hopefully not for too long.
> >
> > Please dont add a new container. Such signalling can be added to
> > existing containers with little effort.
> > Iam also happy to help to add it to nut
>
> Why did you write FFv1 then?
>
> > reminded me of this:
> > https://xkcd.com/927/
>
> FYI, there are 3 organizations already behind it.
FFmpeg already has its own native container format.
There has been no suggestion or request to extend it in any way.
Now suddenly 3 organizations want to replace it?
I do not agree. This is not how open source development works.
These 3 organizations can create their own fork with their own format
if they choose not to participate in open discussion and design.
I certainly was and am interrested in participating in any
improvments to our native container format or the design of a new
one. I also actively maintain our native container format.
And i knew 0 about any plans to build a "new container".
If you consider this ok, iam not sure what to say.
If there is any suggestion to any change or extension of our native
container format. Then please start a proper open discussion about it.
Until this happens there is no way to even touch the question of a new
format or changes to an existing ...
Thanks and yes iam a little upset by this
PS: there is also 0 on our issue tracker and wiki about this:
https://trac.ffmpeg.org/search?q=avtransport
"No matches found."
and also no matches on the mailing list
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240821/5b3b11f4/attachment.sig>
More information about the ffmpeg-devel
mailing list