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
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 file
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 "unsubsc
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
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
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 deterministi
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 t
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 should
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:
> 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 lates
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 mszh-zlib
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 communi
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 substan
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
htt
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
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 -a
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 TC
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 broken
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 there
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 t
> 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 reache
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 frame.
Hi,
this should hopefully be the last version of this set. If nobody has new
comments, I will push it in a few days.
Cheers,
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To uns
23 matches
Mail list logo
