On Fri, Jan 4, 2019 at 7:57 PM Rostislav Pehlivanov <atomnu...@gmail.com> wrote:
> On Fri, 4 Jan 2019 at 16:28, Vittorio Giovara <vittorio.giov...@gmail.com> > wrote: > > > On Fri, Jan 4, 2019 at 2:37 PM Nicolas George <geo...@nsup.org> wrote: > > > > > Vittorio Giovara (12019-01-04): > > > > I personally disagree, what are coordinates within an AVFrame if not > > the > > > > length/size of an object in memory? > > > > > > That would be an argument for making AVFrame.width and AVFrame.height > > > size_t. But they are not, and therefore these ROI values have no reason > > > to be either. There is no point in being able to express ROI > coordinates > > > in the quadrillion when the size of the frame is bounded by much less. > > > > > > > That seems a poor argument since the code base is so old that there are a > > plethora of bad design decisions that should not dictate what choices are > > made now. > > > > Hence we should avoid making a new one now. Right, we should do things that make sense and argument them with something more than saying "it's confusing". Pixels shouldn't have the size_t type, it just makes things confusing. > -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
