quinkbl...@foxmail.com:
> From: Zhao Zhili
>
> This is a micro-optimization. Saving almost 200 reallocations makes it
> worth a try.
> ---
> libavfilter/formats.c | 43 +++
> 1 file changed, 35 insertions(+), 8 deletions(-)
>
> diff --git
On Fri, 03. Jan 22:25, quinkbl...@foxmail.com wrote:
> From: Zhao Zhili
>
> This is a micro-optimization. Saving almost 200 reallocations makes it
> worth a try.
> ---
> libavfilter/formats.c | 43 +++
> 1 file changed, 35 insertions(+), 8 deletions(-)
>
From: Zhao Zhili
This is a micro-optimization. Saving almost 200 reallocations makes it
worth a try.
---
libavfilter/formats.c | 43 +++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index
zhilizhao (12019-12-24):
> I get the idea. However, if lavi is built agains version A of libavutils
> and use version B at runtime, it’s not guaranteed to work with or without
> access to AV_PIX_FMT_NB:
In principle, it is.
> 1. For major version bump, AV_PIX_FMT_XXX may have different values
>
Hi Nicolas,
> On Dec 24, 2019, at 6:50 PM, Nicolas George wrote:
>
> zhilizhao (12019-12-24):
>> 1. AV_PIX_FMT_NB depends on !gaps, unless we calculate and set it manually
>
> NB is not really the "number of".
>
>> 2. The reason to deprecated VAAPI in this way (ABI incompatible) is
>>
zhilizhao (12019-12-24):
> 1. AV_PIX_FMT_NB depends on !gaps, unless we calculate and set it manually
NB is not really the "number of".
> 2. The reason to deprecated VAAPI in this way (ABI incompatible) is
> AV_PIX_FMT cannot have gaps
No, it was because we WANTED AV_PIX_FMT to not have gaps.
> On Dec 24, 2019, at 4:32 AM, Michael Niedermayer
> wrote:
>
> On Mon, Dec 23, 2019 at 04:11:53PM +0100, Nicolas George wrote:
>> Tomas Härdin (12019-12-09):
>>> As far as I can tell this is OK, and it passes FATE. But it just looks
>>> very very wrong. Why does this function even exist if
On Mon, Dec 23, 2019 at 04:11:53PM +0100, Nicolas George wrote:
> Tomas Härdin (12019-12-09):
> > As far as I can tell this is OK, and it passes FATE. But it just looks
> > very very wrong. Why does this function even exist if all it
> > effectively does is return the integers from 0..count-1?
>
Tomas Härdin (12019-12-09):
> As far as I can tell this is OK, and it passes FATE. But it just looks
> very very wrong. Why does this function even exist if all it
> effectively does is return the integers from 0..count-1?
For some time, there were gaps in the list of pixel formats, the task of
Tomas Härdin (12019-12-15):
> Perhaps someone with more insight into lavfi wants to comment?
I intend to look at it, but it have been a hectic week here.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing
tis 2019-12-10 klockan 22:14 +0800 skrev zhilizhao:
> > On Dec 10, 2019, at 4:20 AM, Tomas Härdin wrote:
> >
> > lör 2019-12-07 klockan 01:06 +0800 skrev Zhao Zhili:
> > > This is a micro-optimization. Saving almost 200 reallocations makes
> > > it
> > > worth a try.
> > > ---
> > > fix commit
> On Dec 10, 2019, at 4:20 AM, Tomas Härdin wrote:
>
> lör 2019-12-07 klockan 01:06 +0800 skrev Zhao Zhili:
>> This is a micro-optimization. Saving almost 200 reallocations makes
>> it
>> worth a try.
>> ---
>> fix commit message typo: relocations -> reallocations
>>
>> libavfilter/formats.c
lör 2019-12-07 klockan 01:06 +0800 skrev Zhao Zhili:
> This is a micro-optimization. Saving almost 200 reallocations makes
> it
> worth a try.
> ---
> fix commit message typo: relocations -> reallocations
>
> libavfilter/formats.c | 35 +--
> 1 file changed, 21
This is a micro-optimization. Saving almost 200 reallocations makes it
worth a try.
---
fix commit message typo: relocations -> reallocations
libavfilter/formats.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/libavfilter/formats.c
14 matches
Mail list logo
