On 6/27/2020 7:56 PM, lance.lmw...@gmail.com wrote:
> On Sat, Jun 27, 2020 at 05:54:52PM +0200, Carl Eugen Hoyos wrote:
>> Am Sa., 27. Juni 2020 um 17:46 Uhr schrieb <lance.lmw...@gmail.com>:
>>>
>>> From: Limin Wang <lance.lmw...@gmail.com>
>>>
>>> The issue is introduced from a705bcd763e344fa, please tested with below
>>> command line:
>>> make V=1 fate-sub-cc-scte20 TARGET_EXEC="valgrind --error-exitcode=1"
>>>
>>> Reported-by: Martin Storsjö <mar...@martin.st>
>>> Signed-off-by: Limin Wang <lance.lmw...@gmail.com>
>>> ---
>>> libavcodec/mpeg12dec.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
>>> index f0f92ac..2562027 100644
>>> --- a/libavcodec/mpeg12dec.c
>>> +++ b/libavcodec/mpeg12dec.c
>>> @@ -2276,6 +2276,8 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
>>> if (ret >= 0) {
>>> uint8_t field, cc1, cc2;
>>> uint8_t *cap = s1->a53_buf_ref->data;
>>> +
>>
>>> + memset(s1->a53_buf_ref->data + old_size, 0, cc_count *
>>> UINT64_C(3));
>>
>> Why is the promotion (?) to uint64 useful?
>
> I can't tell what's the real reason as the original code is coming in
> 80ea66112817c719b476de8f7
> for h264, HEVC and mpeg2 are following the same way.
The cast is done when combining the current captions with the existing
ones. old_size + cc_count * 3 in h264_sei.c can overflow, hence casting
to uint64_t, but cc_count * 3 alone can't, both here or in h264_sei.c
>
>>
>> Carl Eugen
>> _______________________________________________
>> 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".
>
_______________________________________________
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".
