On 31/07/13 21:15, Anton Khirnov wrote: > > On Wed, 31 Jul 2013 13:11:36 +0200, Luca Barbato <[email protected]> wrote: >> On 31/07/13 12:25, Anton Khirnov wrote: >>> >>> On Wed, 31 Jul 2013 12:10:03 +0200, Luca Barbato <[email protected]> wrote: >>>> On 31/07/13 08:47, Anton Khirnov wrote: >>>>> >>>>> On Wed, 31 Jul 2013 01:51:23 +0200, Luca Barbato <[email protected]> >>>>> wrote: >>>>>> AVPacket by default uses unaligned buffers >>>>>> --- >>>>>> libavcodec/avcodec.h | 5 +++-- >>>>>> 1 file changed, 3 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h >>>>>> index bd9a80c..cf52c62 100644 >>>>>> --- a/libavcodec/avcodec.h >>>>>> +++ b/libavcodec/avcodec.h >>>>>> @@ -3167,8 +3167,9 @@ int av_grow_packet(AVPacket *pkt, int grow_by); >>>>>> * >>>>>> * @param pkt packet to be initialized. This function will set the >>>>>> data, size, >>>>>> * buf and destruct fields, all others are left untouched. >>>>>> - * @param data Data allocated by av_malloc() to be used as packet data. >>>>>> If this >>>>>> - * function returns successfully, the data is owned by the >>>>>> underlying AVBuffer. >>>>>> + * @param data Data allocated by av_realloc() to be used as packet >>>>>> data. If >>>>> >>>>> This is just not true. AVPackets allocated by av_new_packet() are >>>>> av_realloc()ed, sure, but the data supplied to this function can come from >>>>> either. Perhaps write 'av_malloc()/av_realloc() family' >>>> >>>> The open question is if we allow reallocating avpackets or not. >>>> >>> >>> I don't see why not, reallocating a packet created with this function should >>> work perfectly well and result in a malloc+memcpy. >> >> why are we using realloc in other cases then? >> > > I fail to see how any other cases are related to the documentation for this > function. This function accepts anything that is av_free()able. Claiming that > it > only accepts av_realloc()ed data is not true. >
Agreed, I'll send over an updated patch and drop this from this set. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
