Anton Khirnov: > Quoting Gyan Doshi (2020-02-01 06:15:30) >> >> >> On 31-01-2020 10:41 pm, Andreas Rheinhardt wrote: >>> Gyan Doshi: >>>> Allows selecting demuxer by extension which are more widely recognized >>>> by users. >>>> >>>> Conditional cast added since this function will usually be called after >>>> av_find_input_format, and so matches its return type. >>> That's not a good point. av_demuxer_find_by_ext() already always >>> returns const AVInputFormat *, so you casting the const away when >>> returning is pointless. Furthermore, any caller that wants to use this >>> new function can simply use a pointer to const AVInputFormat to work >>> with both av_find_input_format() and av_demuxer_find_by_ext(). And >>> after all, adding const makes the code more future-proof >>> (av_find_input_format() will return const AVInputFormat * after the >>> next major bump). >> >> Ok, I don't think I should add const to the pointers at the receiving >> end (fftools) since they are global variables and may not be acceptable >> as const. So I'll cast away the const when receiving and remove the >> conditional cast. > > Why not? Nothing can conceivably modify the content of those structs, so > simply adding const to all their uses should work. > Then avformat_open_input() would have to be modified to accept a const AVInputFormat *, otherwise one would get compiler warnings. And then one would have to cast the const away in avformat_open_input() (should probably already have been made in 3aa6208d to allow users to write future-proof-code). But the av_opt-API seems to be based around non-const structures which may be a problem with the av_opt_find()-calls in open_input_file() in ffmpeg_opt.c.
- Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
