On 7/19/2018 4:31 PM, Nicolas George wrote: > James Almer (2018-07-19): >> This is more in line with the similar error above. Aborting gracefully >> by printing a message and returning an error value instead of a hard >> abort() with no explanation as to why "ret == AVERROR(ENOMEM)" was expected. > > Explaining to whom? If it is a consistency bug within lavc, notifying > the user is worthless, the correct thing to do is to prevent the > inconsistency from getting committed, hence assert and FATE test. > > Regards,
AVOptions available in bitstream filters, or even the range of accepted values, may depend on configure time options (external or internal dependencies). A simple ./configure could enable all that's needed for the option to be available as required by the decoder auto inserting the bsf, but ./configure --disable-everything --enable-decoder=foo may not. It may not enable the bsf (checked earlier in this same function and also reported as a bug), or it may not enable an optional dependency required to have the AVOption the decoder in question wants to use available (checked by this new code). See commit 5a366f9770. A fate test will not suffice to detect this kind of issue. I don't mind if we change it into a hard av_assert0(), but it will not prevent inconsistencies from being committed any more than what was committed. It will only give a less helpful error message to the user. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
