[FFmpeg-devel] [PATCH] ffmdec: sanitize codec parameters

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Sat Nov 19 18:30:59 EET 2016

On 19.11.2016 16:28, Michael Niedermayer wrote:
> On Sat, Nov 19, 2016 at 02:04:44PM +0100, Andreas Cadhalpun wrote:
>> On 19.11.2016 02:14, Michael Niedermayer wrote:
>>> On Fri, Nov 18, 2016 at 10:35:29PM +0100, Andreas Cadhalpun wrote:
>>>> On 18.11.2016 02:40, Michael Niedermayer wrote:
>>>>> On Thu, Nov 17, 2016 at 07:35:01PM +0100, Andreas Cadhalpun wrote:
>>>>>> +                if (size < 0 || size >= FF_MAX_EXTRADATA_SIZE) {
>>>>>> +                    av_log(s, AV_LOG_WARNING, "Invalid extradata size %d\n", size);
>>>>> i think this and possibly others should be a hard failure
>>>>> or why would a invalid extradata_size be ok ?
>>>> The decoder might still be able to work.
>>>> What would be the advantage of a hard failure?
>>> the advantage of stoping clearly invalid data early
>>> The decoder runs on a seperate machine with ffm possibly. The file
>>> just gets demuxed and sent over the network. The warning hinting to
>>> the issue is on the sending side. The decoder failure at the receiver
>>> i didnt try but if iam not mixing things up that would be confusing
>>> neither side would fully understand whats going on without the other
>> OK, I changed the extradata_size case to an error.
>> Which others do you think should be changed, too?
> why do you want to accept any invalid values ?
> ffm files should only be generated by FFmpeg, why should FFmpeg
> generate invalid files or what is the use case where this occurs ?
> It feels like iam missing something here ...

A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
convinced me that it should be avoided.

Best regards,

1: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202783.html
2: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202785.html

More information about the ffmpeg-devel mailing list