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

[Nicolas George]

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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210324/5cc6fe16/attachment.sig>