On 12.08.2019, at 21:53, Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote: >> On 08.08.2019, at 10:36, Michael Niedermayer <mich...@niedermayer.cc> wrote: >> >>> This provides an alternative to retry counters. >>> Useful if there is no reasonable maximum number of iterations and >>> no ordering that naturally avoids loops. >> >> Going by the old principle of "an API is not tested until it has at least 3 >> users" >> might it make sense to delay this until we've found and tested it in a few >> use-cases? >> Depending on how much hurry there is to get the bug-fix in. > >> I assume there is also an actual bug-fix patch somewhere, maybe we should >> have that >> in the same patch series to make it easier to review the actual usage? > > sure will repost this eventually with 3+ bugfixes. > But wont search for such bugs ATM as ive too many other things to do > so it might take a bit of time before i do Of course. Though on re-considering: if it is added as a purely internal API that we can change at any time and we do not need to think on backwards compatibility (and a comment on the file that we might want to have and review use-cases before making it public) I would have no objections. I realized only being locked-in compatibility-wise had me worried at this point actually. _______________________________________________ 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".
