9 Sept 2021, 19:40 by one...@gmail.com: > On Thu, Sep 9, 2021 at 12:51 PM Nicolas George <geo...@nsup.org> wrote: > >> Lynne (12021-09-09): >> > That's fine, no argument about this. We talked about this on IRC >> > and I agreed that duration fields on frames make no sense and >> > are difficult to guarantee. >> >> Thank you for mentioning this. >> >> Not everybody can spend time synchronously on IRC. >> > > Such people should than leave project. > > >> > One thing though, "Speaking as the maintainer of libavfilter"? >> > Please don't discredit Paul, he maintains and cares about lavfi >> > just as much as you do. >> >> I am not discrediting Paul. He maintains a lot of useful filters, and he >> is the expert on intra-frame threading, but the global framework, >> including negotiation and scheduling, is really my thing ever since >> Stefano stopped worked on the code. >> > > I read this as personal attack. > > Tell me how one is supposed to fix last frame duration when muxing & > encoding? >
A duration field that's set to the previous frame's duration would be a good start. It'll work with CFR and most VFR video. If it's a static image, the duration could be set to infinity or NOPTS to flag this. I don't mind a patch which introduces that, although we already have a pkt_duration field, which may fit. But setting it as above may be an API-breaking change, so a dedicated field would be better. _______________________________________________ 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".
