Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2024-01-24 Thread Anton Khirnov
Quoting Marth64 (2024-01-16 00:51:14) > Hello, I wanted to call out 2 issues that I think are bugs from this, and > that I was able to trace to the exact commit. > > *#1: Concat filter issues: *A user from IRC support reported it, and I was > able to successfully reproduce it. > When using concat

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2024-01-15 Thread Marth64
Hello, I wanted to call out 2 issues that I think are bugs from this, and that I was able to trace to the exact commit. *#1: Concat filter issues: *A user from IRC support reported it, and I was able to successfully reproduce it. When using concat filter on multiple inputs alongside -ss (same

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-11 Thread Anton Khirnov
both should now be fixed in my tree -- 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

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-07 Thread Michael Niedermayer
On Thu, Dec 07, 2023 at 11:52:47AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-12-06 21:21:55) > > On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > > > Hi, > > > this should hopefully be the last version of this set. If nobody has new > > > comments, I will push

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-07 Thread Michael Niedermayer
On Thu, Dec 07, 2023 at 11:52:47AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-12-06 21:21:55) > > On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > > > Hi, > > > this should hopefully be the last version of this set. If nobody has new > > > comments, I will push

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-07 Thread Anton Khirnov
Quoting Michael Niedermayer (2023-12-06 21:21:55) > On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > > Hi, > > this should hopefully be the last version of this set. If nobody has new > > comments, I will push it in a few days. > > I have a case that becomes really non

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Anton Khirnov
Quoting Cosmin Stejerean via ffmpeg-devel (2023-12-06 21:29:11) > There is still a penalty as you could do asetnsamples without multi-threading > and get even higher performance, > but given the general benefits of multi-threading and the fact that it's > possible to increase the performance of

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Vittorio Giovara
On Wed, Dec 6, 2023 at 3:14 PM Nicolas George wrote: > Lie. > A summary of your proposal or a link to your suggestion would be appreciated. Without reference we're all shouting in the void. > I guess now that your side holds most of the power the mask is off. > > This mail you just sent

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Anton Khirnov
Also, the numbers I'm seeing on my 16-core Ryzen 9 5950X are quite different: * 5.0, your command:speed=3.25e+03x * 5.0, filter_complex: speed=5.29e+03x * 5.1, your command:speed=3.2e+03x * 5.1, filter_complex: speed=5.2e+03x * 6.0, your command:speed=2.44e+03x * 6.0, filter_complex:

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Cosmin Stejerean via ffmpeg-devel
> On Dec 6, 2023, at 11:36 AM, Anton Khirnov wrote: > >> In some cases the performance penalty because of threading is quite >> significant: >> >> Example command line: >> >> ffmpeg -f lavfi -i sine -af volume=6dB -f null none >> >> After latest threading changes: speed=810x >> Before

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Michael Niedermayer
On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > Hi, > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. I have a case that becomes really non deterministic for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Nicolas George
Anton Khirnov (12023-12-06): > Would guess this is caused by overhead from tons of tiny frames. So > 1) generate larger frames > 2) use -filter_complex with no inputs instead of -f lavfi to eliminate >all overhead from demuxing, decoding, and demux-decode/decode-filter >inter-thread

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Nicolas George
Anton Khirnov (12023-12-06): > As usual when someone disagrees with him, Nicolas converged to being > utterly unreasonable and deaf to all arguments. I see no point in Ad-hominem attack. > discussing this with him any further and intend to push the set > tomorrow, unless somebody else has

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Vittorio Giovara
On Wed, Dec 6, 2023 at 5:30 AM Anton Khirnov wrote: > Hi, > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. > LGTM -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Anton Khirnov
Quoting Marton Balint (2023-12-06 20:29:01) > > > On Wed, 6 Dec 2023, Anton Khirnov wrote: > > > Hi, > > this should hopefully be the last version of this set. If nobody has new > > comments, I will push it in a few days. > > In some cases the performance penalty because of threading is quite

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Marton Balint
On Wed, 6 Dec 2023, Anton Khirnov wrote: Hi, this should hopefully be the last version of this set. If nobody has new comments, I will push it in a few days. In some cases the performance penalty because of threading is quite significant: Example command line: ffmpeg -f lavfi -i sine

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Anton Khirnov
Hi all, As usual when someone disagrees with him, Nicolas converged to being utterly unreasonable and deaf to all arguments. I see no point in discussing this with him any further and intend to push the set tomorrow, unless somebody else has substantial objections. I've considered asking for a

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Nicolas George
Anton Khirnov (12023-12-06): > After weeks of discussion, you have NOT suggested any workable > alternative. Indeed. And the reason for that is that all the time I have available on this is spent debunking your libel about the current logic. > Producing unpredictable output generally means

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Anton Khirnov
Quoting Nicolas George (2023-12-06 13:10:41) > I have offered Anton my help. After weeks of discussion, you have NOT suggested any workable alternative. The single suggestion I did see from you * was already implemented * did not address the issues at all > But first he needs to acknowledge

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Nicolas George
Zhao Zhili (12023-12-06): > For such large patch set, it’s almost impossible to not break any corner case. Yes, that is what review is for. > Considering the improvements the patch set brings into fftools, those corner > cases can be fixed after merge. That means never. No. > And any body can

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Zhao Zhili
> On Dec 6, 2023, at 18:55, Nicolas George wrote: > > Anton Khirnov (12023-12-06): >> this should hopefully be the last version of this set. If nobody has new >> comments, I will push it in a few days. > > Absolutely not: you cannot push until consensus is reached, and > consensus is not

Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Nicolas George
Anton Khirnov (12023-12-06): > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. Absolutely not: you cannot push until consensus is reached, and consensus is not reached since you are still breaking the sparseness of sub2video