[FFmpeg-devel] Politics

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Calvin
> Walton
> Sent: Monday, December 13, 2021 8:32 PM
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Politics
> 
> 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.

Yes, I agree to that. But the heartbeat mechanism is not something that
I'm adding. 

It's something that exists and that I'm just keeping for now. 
At a later time, this should be better moved to a separate filter 
for providing better and more explicit control over the mechanism.

While I'm keeping this small part from the "sub2video hack", I'm 
removing all the rest of it and turning it into a regular and 
reasonable implementation.

> 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".

The might be a better way, but we need to be clear that this is 
another fundamental change, and I think it's impossible to do all those
things at once.

I'm not considering my patchset as the end of all wisdom, just as 
a solid step forward.

Thanks for your comments,
softworkz