On Thu, Oct 15, 2015 at 2:22 PM, Vittorio Giovara
<[email protected]> wrote:
> On Thu, Oct 15, 2015 at 2:14 PM, Luca Barbato <[email protected]> wrote:
>> On 15/10/15 13:38, Vittorio Giovara wrote:
>>> On Thu, Oct 15, 2015 at 2:26 AM, Luca Barbato <[email protected]> wrote:
>>>> `av_packet_unref` replaces it.
>>>
>>> Might be a tad bit more verbose here, deprecating is never fun for
>>> users so each step has to be very well explained.
>>
>> I'll think something.
>>
>>>> ---
>>>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>>>> index 5f1755a..3d5af09 100644
>>>> --- a/libavcodec/avcodec.h
>>>> +++ b/libavcodec/avcodec.h
>>>> @@ -1152,13 +1152,13 @@ typedef struct AVPacketSideData {
>>>>   *
>>>>   * The semantics of data ownership depends on the buf or destruct 
>>>> (deprecated)
>>>>   * fields. If either is set, the packet data is dynamically allocated and 
>>>> is
>>>> - * valid indefinitely until av_free_packet() is called (which in turn 
>>>> calls
>>>> + * valid indefinitely until av_packet_unref() is called (which in turn 
>>>> calls
>>>>   * av_buffer_unref()/the destruct callback to free the data). If neither 
>>>> is set,
>>>>   * the packet data is typically backed by some static buffer somewhere 
>>>> and is
>>>>   * only valid for a limited time (e.g. until the next read call when 
>>>> demuxing).
>>>>   *
>>>>   * The side data is always allocated with av_malloc() and is freed in
>>>> - * av_free_packet().
>>>> + * av_packet_unref().
>>>
>>> not sure we want to do this: at least this does not happen in the
>>> av_frame_unref version and probably would make more sense to free it
>>> in free_packet
>>
>> This part needs rework indeed. What do you suggest exactly?
>
> I think it would be simpler if APIs between frames and packets behaved
> similarly, so packet_unref should not free side data.

ops, misread code, ignore this comment
-- 
Vittorio
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to