On Sun, 2021-12-12 at 06:15 +0000, Soft Works wrote: > Good Morning, > > yesterday, it happened for the 4th and 5th times that another > developer > called my patchset a “hack”.
This might be partially a language problem. Ffrom familiarity with the usage in several primarily-English development communitities, the primary meaning of the word "hack" as I interpret it is "doing something in a way that wasn't the original intent of the code". It's not *necessarily* a bad thing. In my opinion, the heartbeat mechanism as it has been designed in this patchset fits that description of a "hack" relative to the current libavfilter design, since it is a fix to a very specific problem on top of an existing system, rather than a design change to fix the underlying system in a way that would correct the problem in general. In general, ffmpeg filters deal very poorly with long timestamp gaps of *any* media type, which can cause stalls or excessive buffering. Moving to the "activate" callback mechanism did a bit to help with this - like, for example, I rewrote the "fps" filter to use the activate callback to handle filling in large timestamp gaps a frame at a time rather than buffering a ton of frames all at once and causing OOM. But that only fixed the situation in files with single streams. I believe that a more general solution is needed to handle working with multiple "synchronized" streams - i.e. produced from the same demuxer - where one stream can have large timestamp gaps which others do not. IMO, this probably requires going all the way back to the demuxer level, since the demuxer is the only part of ffmpeg that knows for sure that "some pts has passed without any packets from stream X". -- kepstin Calvin Walton <calvin.wal...@kepstin.ca> _______________________________________________ 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".
