On Thu, Dec 7, 2023 at 6:26 PM Paul B Mahol <one...@gmail.com> wrote:
> > > 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. > I found out if I increase queue size of thread for frames/packets in fftools/ from 1 to >1 it increases speed in decoding by 10%. Looks like other numbers greater than 2 do not make much any difference. Still current state is sub-optimal. _______________________________________________ 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".
