Gyan Doshi:
> Identifies demuxer based on extension if short name search fails.
> ---
> fftools/ffmpeg_opt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 12d44886ee..ecc7d8f1c5 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -1026,7 +1026,8 @@ static int open_input_file(OptionsContext *o, const
> char *filename)
> }
>
> if (o->format) {
> - if (!(file_iformat = av_find_input_format(o->format))) {
> + if (!(file_iformat = av_find_input_format(o->format)) &&
> + !(file_iformat = av_demuxer_find_by_ext(o->format))) {
> av_log(NULL, AV_LOG_FATAL, "Unknown input format: '%s'\n",
> o->format);
> exit_program(1);
> }
>
This discards the const qualifier. You should get a warning for this.
But looking at this a bit more made me realize that a library user
that does not want to wait with const-correctness until the next major
version bump can't do so (without casts, that is):
avformat_open_input() does not accept a const AVInputFormat yet. Maybe
it would have been better to already accept it now (which means that
one has to cast a const away inside avformat_open_input() until the
next major bump)?
Furthermore, adding const will likely also lead to const-warnings wrt
av_opt_find(). This is bad and will need to be dealt with before the
next major bump. Maybe one should add versions of av_opt_find[2] that
accepts a const void* (this seems to be more of a problem for
av_opt_find2 because of its target_obj)?
- 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".
