On Wed, Mar 8, 2017 at 8:15 PM, James Almer <jamr...@gmail.com> wrote: > On 3/8/2017 9:45 PM, Michael Niedermayer wrote: >> On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote: >>> On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: >>>> Hi, >>>> >>>> On Wed, Mar 8, 2017 at 9:31 AM, wm4 <nfx...@googlemail.com> wrote: >>>> >>>>> On Wed, 8 Mar 2017 14:09:53 +0100 >>>>> Michael Niedermayer <mich...@niedermayer.cc> wrote: >>>>> >>>>> If the size printing is removed then other code should be added >>>>>> to test for the size to match the correct value >>>>> >>>>> Then it would be more reasonable to make av_packet_add_side_data() >>>>> check whether the size is correct for the given side data type. >>>> >>>> >>>> I think you're both right here, this is a pretty good idea (for fixed-size >>>> side-data types). >>>> >>> >>> So how do we fix fate now? Change the datatypes to uint32_t, remove >>> the size print out? >> >> why is the data type size_t and not uint32_t int64_t or unsigned int ? >> >> independant of the fate issue i mean, size_t seems a strange choice
Well as the name implies, size_t should be usable to represent sizes ;) Beside that, the choice of making these elements size_t was made after the rectangle defined in avframe, whose fields are defined with size_t too. -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
