Mar 1, 2024, 19:59 by an...@khirnov.net: > Quoting Lynne (2024-02-29 14:30:55) > >> We offer support for it. Someone must have used it. >> I'm sure there are less used game codecs we support than Sonic. >> > > [citation needed] > > Is there any evidence that it was used for anything other than > development and testing? That anyone has any actual samples in it they'd > like to play? >
There's always the possibility that someone encoded samples years ago and deleted the originals. Same as with Snow. My only concern is that this sets a sensitive precedent to get rid of old codec code with low weight under unclear conditions. Where do we draw the line? SMPTE? ISO/IEC standardization? IETF? AOM? Having *a* spec (Sonic doesn't, but neither did FFv1 until a few years ago)? A single company pushing for it many years ago with no spec, like SpeedHQ, or the many niche lossless/intra-only codecs? Or simply having one single implementation in FFmpeg, and no spec at all, and having an experimental flag, and no activity for a very long amount of time? If it's the last case, or simply being a one-off, I can agree with deprecating and remove it next bump. But if the developer thinks they will have time and have motivation to work on it in the future, I think we should leave it at just deprecation plus disabling building the encoder by default, until the issue is brought up again at say, after the next version bump. After all, CELT started out more than 10 years before Opus was standardized, and its EC code has made it all the way to AV2 despite its core remaining visibly similar over the years. And FFv1 was used as an inspiration for FLIC, which went on to become JPEG-XL. _______________________________________________ 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".
