On Wed, 28 Dec 2016 17:34:33 +0100 "Diego Biurrun" <di...@biurrun.de> wrote:
> On Wed, Dec 28, 2016 at 07:47:58AM +0100, Luca Barbato wrote: > > On 27/12/2016 19:31, Anton Khirnov wrote: > > > Extend the width/height doy to clarify that it should store coded > > > values. > > > --- > > > doc/APIchanges | 4 ++++ > > > libavutil/frame.c | 4 ++++ > > > libavutil/frame.h | 28 +++++++++++++++++++++++++++- > > > libavutil/version.h | 2 +- > > > 4 files changed, 36 insertions(+), 2 deletions(-) > > > > size_t, while correct, feels out of place somehow. > > > > Ok if we really plan to move to size_t everywhere else. > > I'm all for moving in the direction of size_t. See my patch that > changes parts of the crypto API to use size_t. While I agree that it'd be a good idea to use size_t instead of int for these things, creating an inconsistency is also a PITA. Other new API also uses int, so why size_t just for those new fields? _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
