[FFmpeg-devel] [PATCH] avformat/utils: add helper functions to retrieve index entries from an AVStream

[James Almer]

On 3/24/2021 4:48 PM, Nicolas George wrote:
> James Almer (12021-03-24):
>> Because it's not even a pointer that's guaranteed to be valid or point to
>> valid data until the next call to one specific function or set of functions
>> (Your example is basically av_dict_get(), where only calls to av_dict_set*()
>> on a AVDictionary you own will make previously returned AVDictionaryEntry
>> invalid), and instead it's a pointer that may or may not be valid after the
>> next call to potentially *any* lavf function, because it could be modified
>> by reading the header, reading a packet, and maybe more cases, all depending
>> on demuxer, and after which it could still be pointing to the desired entry,
>> or to some other entry, or to freed memory.
> 
> What you say is true, but it is absolutely not a problem if the user
> access the pointer immediately, before calling any other function, just
> like it is supposed to do when derefencing ctx->streams.
> 
>> In any case, would a
>>
>> int av_get_index_entry(AVStream *st, int idx, int64_t *pos,
>>                         int64_t *timestamp, int *size,
>>                         int *distance, int *flags);
>>
>> implementation, which is basically the inverse of av_add_index_entry(), be
>> ok instead? No AVIndexEntry usage, only the fields the caller cares about
>> can be returned, and no "This pointer will autodestruct in five seconds"
>> situation.
> 
> I will not block it as I would block the version with dynamic
> allocation, but you will need a little more work to convince me that
> this is better than just returning the pointer. You make more work for
> yourself and more work for the user, you have to have a good reason for
> it.

I think it's clear by now that nothing i could say will convince you 
it's better to not return a pointer to an internal array when there are 
safer alternatives, and i already gave my reasons why, none of which 
satisfied you, so i don't see the point in keeping this discussion going.

If some other developer wants to chime in and comment which approach 
they prefer, then that would be ideal. I have no hurry to push this, and 
I'd rather know which direction to go before i write a v3, so it can wait.

> 
> Regards,
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>