diff mbox series

[FFmpeg-devel,3/6] fftools/ffmpeg: search for demuxer by extension as well

Message ID 20200131142608.42729-3-ffmpeg@gyani.pro
State New
Headers show
Series [FFmpeg-devel,1/6] avformat/format: add av_demuxer_find_by_ext
Related show

Checks

Context Check Description
andriy/ffmpeg-patchwork pending
andriy/ffmpeg-patchwork success Applied patch
andriy/ffmpeg-patchwork success Configure finished
andriy/ffmpeg-patchwork success Make finished
andriy/ffmpeg-patchwork success Make fate finished

Commit Message

Gyan Doshi Jan. 31, 2020, 2:26 p.m. UTC
Identifies demuxer based on extension if short name search fails.
---
 fftools/ffmpeg_opt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Andreas Rheinhardt Jan. 31, 2020, 5:47 p.m. UTC | #1
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
Gyan Doshi Jan. 31, 2020, 6:38 p.m. UTC | #2
On 31-01-2020 11:17 pm, Andreas Rheinhardt wrote:
> 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.
I do. I thought of adding the cast in the user calls. But I think the 
better way around is to do what I did originally, use ff_const59 with 
the return cast.
And remove that cast post-bump.

> 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-request@ffmpeg.org with subject "unsubscribe".
diff mbox series

Patch

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);
         }