[FFmpeg-devel] [PATCH 4/6] avformat/wavdec: s337m support

Nicolas Gaullier nicolas.gaullier at cji.paris
Fri Feb 17 12:30:56 EET 2023

>> +    {"non_pcm_mode", "Chooses what to do with s337m",
>> OFFSET(non_pcm_mode), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, DEC, 
>> "non_pcm_mode"},
>> +    {"copy"        , "Pass s337m through unchanged", 0,
>> AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 1, DEC, "non_pcm_mode"},
>> +    {"demux"       , "Demux s337m"                 , 0,
>> AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 1, DEC, "non_pcm_mode"},
>> +#endif
>>      { NULL },
>>  };
>So default is to demux? Sounds OK and probably avoids eardrum destruction

Well, to be honest, I am not very comfortable with that.
The fact is, I fear that many users have scripts to mux wav/dolby_e into mxf outputs and they will be affected...
But I completely understand the ffmpeg logic to "always decode", as is done currently in wav files to probe dts or even spdif which is really the same thing as s337.
It does not seem reasonable to break this here.
And another point here in this latest edition on my patch serie is that the use of an existing AVOption makes it possible for users
to upgrade their command lines just now by adding the option : ignored in previous version, it will take effect the day they upgrade their ffmpeg version,
so the transition can be smooth...

>> +                            } else {
>> +                                av_log(s, AV_LOG_INFO, "Passing
>> through S337M data: codec will not be reported\n");
>> +                            }
>Perhaps the user should also be informed when S337m is demuxed rather than passed through?

I could add a debug message if you think that could be helpful ?
I think I cannot add an INFO log as spdif and other probe-mecanisms are not verbose in current code.


More information about the ffmpeg-devel mailing list