On 09/25/2011 09:42 PM, Luca Barbato wrote:
> On 9/26/11 2:38 AM, Justin Ruggles wrote:
>> On 09/25/2011 06:58 PM, Luca Barbato wrote:
>>
>>> On 9/25/11 11:03 PM, Justin Ruggles wrote:
>>>> This also prevents NULL packets from being sent to the decoder unless
>>>> CODEC_CAP_DELAY is set.
>>>> ---
>>>> libavcodec/utils.c | 5 +++++
>>>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>>> index 8459e5f..85c9d76 100644
>>>> --- a/libavcodec/utils.c
>>>> +++ b/libavcodec/utils.c
>>>> @@ -747,6 +747,11 @@ int attribute_align_arg
>>>> avcodec_decode_audio3(AVCodecContext *avctx, int16_t *sa
>>>>
>>>> avctx->pkt = avpkt;
>>>>
>>>> + if (!avpkt->data&& avpkt->size) {
>>>> + av_log(avctx, AV_LOG_ERROR, "invalid packet: NULL data, size>
>>>> 0\n");
>>>> + return AVERROR(EINVAL);
>>>> + }
>>>> +
>>>> if((avctx->codec->capabilities& CODEC_CAP_DELAY) || avpkt->size){
>>>> //FIXME remove the check below _after_ ensuring that all audio
>>>> check that the available space is enough
>>>> if(*frame_size_ptr< AVCODEC_MAX_AUDIO_FRAME_SIZE){
>>>
>>> Seems ok as patch, I'm wondering about the reference to CODEC_CAP_DELAY
>>> though.
>>
>>
>> I basically added that because the documentation for CODEC_CAP_DELAY
>> says that the codec is guaranteed not to get a NULL packet unless that
>> capability is set, but that isn't true without preventing this case.
>>
>> But like Mans pointed out, there is no valid reason the user should ever
>> send packets like that in the first place...
>>
>
> Exactly =)
>
> Please reword as
>
> avc: reject packets with NULL data and non zero size
>
> And paste this explanation as body ^^
ok to push with this commit message?
avcodec: reject audio packets with NULL data and non-zero size
There is no valid reason the user should ever send such packets in the
first place, but the documentation for CODEC_CAP_DELAY states that the
codec is guaranteed not to get a NULL packet unless that capability is
set. That isn't true without preventing this case.
-Justin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
