>> +#if CONFIG_S337M_DEMUXER
>> + {"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?
>
>/Tomas
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.
Nicolas
_______________________________________________
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".
