James Almer (12023-12-06): > I honestly can't believe you're arguing this.
Yet I do, so I suggest you think a little harder to understand why I do. > And being condescending will not help your case. Can you tell that to Anton too please? > If i request -bitexact, i want bitexact output, regardless of running on a > core i3 or a Threadripper. There's nothing more to it. I had not noticed the -bitexact on the test command line. I will grant the change is acceptable if bit-exact is requested. > Calling random output that happens to be "acceptable" within the subjective > expectations of the user as useful sounds to me like you're trying to find > an excuse to keep buggy code with unpredictable results around, just because > it's been there for a long time. Well, you are wrong, and what I explained is the real reason: most subtitles are not timed that accurately. The subtitles on HBO's Last Week Tonight, for example, can randomly lag or be early by several seconds. Even serious subtitles, like the ones for scripted shows on Netflix/Amazon/Crunchyroll/whatever vary by a few tenths of seconds, i.e. several frames. And I have used this code. And I look carefully at subtitles. If the result was lower quality than the source material, I would have noticed and I would have endeavored to fix it. There never was need. Now, can Anton claim similar experience working with subtitles from the real world? Most of this discussions points to the answer being no. > So, like Anton has asked several times, suggest a way to keep deterministic > and bitexact output without exponentially increasing memory consumption due > to buffering. I will spend time and effort searching for a solution when we agree to work together. “Do this or I will break your code” is an unacceptable behavior, whether it is directed at me or at Paul or at anybody else, and I do not spend effort when unacceptable behavior is tolerated. -- Nicolas George _______________________________________________ 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".