On Wed, Dec 6, 2023 at 2:38 PM Nicolas George <geo...@nsup.org> wrote:
> 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. > > From 3.4 version of ffmpeg to 6.1 version demuxing truehd (-c:a copy) files dropped by factor of 2x speed. But simple transcode from doc/examples is still several times faster than that. I bet using mutexes and condition variables is far from perfect solution or fftools/ code is buggy. This is similar to -lavfi sources dropouts in performance but more used by users of truehd/any small packets format. > -- > 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". > _______________________________________________ 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".
