[FFmpeg-devel] Politics

Calvin Walton calvin.walton at kepstin.ca
Mon Dec 13 21:32:19 EET 2021


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.walton at kepstin.ca>



More information about the ffmpeg-devel mailing list