On Sat, Feb 15, 2014 at 8:00 PM, Tim Walker <tdskywal...@gmail.com> wrote:
> On 15 Feb 2014, at 19:53, Vittorio Giovara <vittorio.giov...@gmail.com> wrote:
>
>> On Sat, Feb 15, 2014 at 7:31 PM, Tim Walker <tdskywal...@gmail.com> wrote:
>>> On 15 Feb 2014, at 19:02, Vittorio Giovara <vittorio.giov...@gmail.com> 
>>> wrote:
>>>> On Sat, Feb 15, 2014 at 3:24 PM, Tim Walker <tdskywal...@gmail.com> wrote:
>>>>> On 12 Feb 2014, at 00:13, Vittorio Giovara <vittorio.giov...@gmail.com> 
>>>>> wrote:
>>>>>
>>>>> Is there a chance that the packet has been used before and already 
>>>>> contains side data? Or is it necessarily a new packet with no side data 
>>>>> to begin with?
>>>>
>>>> Well you have an array of side data in avpacket and
>>>> av_packet_new_side_data takes care of (re)allocation.
>>>> Side data is also correctly passed during copy_props so all should be fine.
>>>> Vittorio
>>>
>>> But:
>>> - av_packet_new_side_data always adds side data
>>> - av_packet_new_side_data always adds it to the end of the array
>>> - av_packet_get_side_data always returns the first side data of a given type
>>>
>>> So if you add side data of type T to an AVPacket which already has side 
>>> data of type T, you'll get the
>>> correct pointer back in libavcodec, but libavcodec users will never be able 
>>> to get that side data, since
>>> there will be another side data of the same type earlier in the side data 
>>> array.
>>>
>>> This is only an issue if the AVPacket may already contain side data of the 
>>> same type, hence my question.
>>
>> Ah well good point, bug I guess this is a bug true for *any* side data no?
>
> Yes. This is e.g. why I added ff_side_data_update_matrix_encoding() in 
> 5b4797a21db900b7d509660b7a4d49829089b004

ok but that is something for a separate patch, assuming it's actually
needed here (this sida data is added only once and i'm not even sure
mov supports changing this atom live).
Cheers,
Vittorio
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to