On 2020-07-22 11:56 +0200, Nicolas George wrote:
> James Almer (12020-07-20):
> > No, i'll push v3 soon if my argumentation below was not enough to
> > convince Nicolas or Michael. My intention is to use ints for the new
> > function, not to postpone committing it in any form indefinitely.
>
>
James Almer (12020-07-20):
> No, i'll push v3 soon if my argumentation below was not enough to
> convince Nicolas or Michael. My intention is to use ints for the new
> function, not to postpone committing it in any form indefinitely.
Sorry, I missed you mail earlier, I only read your arguments
On 7/20/2020 6:32 PM, Brian Kim wrote:
> Just wanted to check if there was any consensus on what we wanted to do
> with these changes. Are we holding off until a future module wide change?
No, i'll push v3 soon if my argumentation below was not enough to
convince Nicolas or Michael. My intention
Just wanted to check if there was any consensus on what we wanted to do
with these changes. Are we holding off until a future module wide change?
On Wed, Jul 15, 2020 at 8:09 AM James Almer wrote:
> On 7/15/2020 4:06 AM, Nicolas George wrote:
> > Michael Niedermayer (12020-07-14):
> >> Let me
On 7/15/2020 4:06 AM, Nicolas George wrote:
> Michael Niedermayer (12020-07-14):
>> Let me phrase my suggestion in a more high level sense
>>
>> Currently the functions use int for lots of cases where they should not
>> ultimately we want the functions to use more correct types for linesize
>>
Michael Niedermayer (12020-07-14):
> Let me phrase my suggestion in a more high level sense
>
> Currently the functions use int for lots of cases where they should not
> ultimately we want the functions to use more correct types for linesize
> sizes and so on.
>
> We need to add these
On 7/14/2020 5:49 PM, Michael Niedermayer wrote:
> On Tue, Jul 14, 2020 at 11:19:54AM -0300, James Almer wrote:
>> On 7/14/2020 9:47 AM, Nicolas George wrote:
>>> James Almer (12020-07-10):
Because my opinion and tastes are not yours. I already said why *i*
consider it ugly. It doesn't
On Tue, Jul 14, 2020 at 11:19:54AM -0300, James Almer wrote:
> On 7/14/2020 9:47 AM, Nicolas George wrote:
> > James Almer (12020-07-10):
> >> Because my opinion and tastes are not yours. I already said why *i*
> >> consider it ugly. It doesn't need to fit *your* conception of ugliness.
> >
> >
On 7/14/2020 9:47 AM, Nicolas George wrote:
> James Almer (12020-07-10):
>> Because my opinion and tastes are not yours. I already said why *i*
>> consider it ugly. It doesn't need to fit *your* conception of ugliness.
>
> If it is only a matter of taste, then it cannot count as an argument.
>
James Almer (12020-07-10):
> Because my opinion and tastes are not yours. I already said why *i*
> consider it ugly. It doesn't need to fit *your* conception of ugliness.
If it is only a matter of taste, then it cannot count as an argument.
But tastes are frequently a proxy for minor factors. If
On 7/10/2020 11:29 AM, Nicolas George wrote:
> James Almer (12020-07-10):
>> It's adding an extra parameter to get a value that ultimately can be
>> derived from the output of another parameter. If you can use the >0 part
>> of the return value for that,
>
> Yes. And for me, it is totally a good
James Almer (12020-07-10):
> It's adding an extra parameter to get a value that ultimately can be
> derived from the output of another parameter. If you can use the >0 part
> of the return value for that,
Yes. And for me, it is totally a good thing.
So why are you calling it ugly?
This
On 7/10/2020 9:03 AM, Nicolas George wrote:
> James Almer (12020-07-09):
>> int av_image_fill_plane_sizes(size_t *size, size_t planesizes[4], enum
>> AVPixelFormat pix_fmt, int height, const ptrdiff_t linesizes[4])
>>
>> But it's also somewhat ugly and inconsistent with other functions in
>> this
James Almer (12020-07-09):
> int av_image_fill_plane_sizes(size_t *size, size_t planesizes[4], enum
> AVPixelFormat pix_fmt, int height, const ptrdiff_t linesizes[4])
>
> But it's also somewhat ugly and inconsistent with other functions in
> this module.
I find this is by far the best solution.
On 7/9/2020 3:20 PM, Brian Kim wrote:
> [...]
>
> On Wed, Jul 8, 2020 at 7:42 PM James Almer wrote:
>> The sum of all sizes should be size_t if each size is a size_t. But if
>> you do that you can't return error values, so i'm not sure what to
>> suggest other than just stick to ints for both
[...]
On Wed, Jul 8, 2020 at 7:42 PM James Almer wrote:
> The sum of all sizes should be size_t if each size is a size_t. But if
> you do that you can't return error values, so i'm not sure what to
> suggest other than just stick to ints for both (ptrdiff_t linesizes
> should be ok).
> I'd like
On 7/8/2020 10:50 PM, Brian Kim wrote:
> Patch attached.
>
> Main changes from v1 are switching to from int to size_t/ptrdiff_t
> where relevant and removing av_image_fill_pointers_from_sizes()
>
> Some things to note:
> - The av_image_fill_planes_sizes uses size_t/ptrdiff_t for buffer
> sizes,
Patch attached.
Main changes from v1 are switching to from int to size_t/ptrdiff_t
where relevant and removing av_image_fill_pointers_from_sizes()
Some things to note:
- The av_image_fill_planes_sizes uses size_t/ptrdiff_t for buffer
sizes, but as mentioned during the v1 review, this leads to
18 matches
Mail list logo
