On 1/4/2019 10:08 AM, Vittorio Giovara wrote:
> On Fri, Jan 4, 2019 at 12:22 PM Nicolas George <geo...@nsup.org> wrote:
>
>> Rostislav Pehlivanov (12019-01-04):
>>>> +typedef struct AVRegionOfInterest {
>>>> + size_t self_size;
>>>> + size_t top;
>>>> + size_t bottom;
>>>> + size_t left;
>>>> + size_t right;
>>> I'd still much rather have uints with fixed sizes than these platform
>>> dependent types.
>>
>> Guo, Yejun said:
>>
>>>> I usually choose 'size_t' for the meanings with length/size.
>>
>> But that is a mistake. size_t is for length/size of objects in memory,
>> not any length/size.
>>
>> These numbers, unless I am mistaken, are coordinates within an AVFrame.
>> In that case, the only correct type is the same as AVFrame.width and
>> AVFrame.height.
>>
>
> I personally disagree, what are coordinates within an AVFrame if not the
> length/size of an object in memory?
> A buffer containing video data is still an object in memory after all, so
> IMHO using size_t makes a lot of sense here.
We already did size_t for AVSphericalMapping and had to change them to
uint32_t.
size_t is not the correct type at all, as video dimensions are not
system dependent, and it will generate the same issues we already
experienced with AVSphericalMapping in fate tests.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
