[FFmpeg-devel] [PATCH 1/2] avformat/utils: Assert that stream_index is valid

Gyan ffmpeg at gyani.pro
Tue Sep 24 21:09:49 EEST 2019



On 24-09-2019 11:38 PM, Marton Balint wrote:
>
>
> On Tue, 24 Sep 2019, Gyan wrote:
>
>>
>>
>> On 24-09-2019 10:01 PM, Andreas Rheinhardt wrote:
>>> There is currently an ordinary check for this (which would lead to a
>>> memleak), but given that no demuxer should ever return a packet with an
>>> invalid stream_index it is more appropriate for this to be an assert.
>>>
>>> FATE passes with this change.
>>>
>>> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at gmail.com>
>>> ---
>>>   libavformat/utils.c | 6 ++----
>>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>>> index 3983a3f4ce..d8ef5fe54c 100644
>>> --- a/libavformat/utils.c
>>> +++ b/libavformat/utils.c
>>> @@ -884,10 +884,8 @@ int ff_read_packet(AVFormatContext *s, AVPacket 
>>> *pkt)
>>>               continue;
>>>           }
>>>
>>> -        if (pkt->stream_index >= (unsigned)s->nb_streams) {
>>> -            av_log(s, AV_LOG_ERROR, "Invalid stream index %d\n", 
>> pkt->stream_index);
>>> -            continue;
>>> -        }
>>> +        av_assert0(pkt->stream_index < (unsigned)s->nb_streams &&
>>> +                   "Invalid stream index.\n");
>>
>> The mpegts demuxer can send packets from new streams which appear 
>> mid-way. See the check in ffmpeg.c process_input() which discards 
>> these packets.
>
> That checks InputFile->nb_streams not AVFormatContext->nb_streams as 
> far as I see.
>
>> Whereas the patch will lead to an abort in fftools and other user 
>> apps transcoding a live feed.
>
> Are you sure? I think the demuxer always creates a new stream before 
> returning a packet, so AVFormatContext->nb_streams should always be 
> up-to-date when this code runs.

No. I'll have to craft an input and check.

Gyan


More information about the ffmpeg-devel mailing list