Quoting Paul B Mahol (2023-12-21 12:53:58) > 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.
It most likely is, but I expect the optimal value would depend on the specific configuration. More testing welcome. -- Anton Khirnov _______________________________________________ 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".
