On Wed, Mar 8, 2017 at 8:15 PM, James Almer <[email protected]> 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 <[email protected]> wrote: >>>> Hi, >>>> >>>> On Wed, Mar 8, 2017 at 9:31 AM, wm4 <[email protected]> wrote: >>>> >>>>> On Wed, 8 Mar 2017 14:09:53 +0100 >>>>> Michael Niedermayer <[email protected]> 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 [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
