On Sun, Oct 04, 2020 at 05:04:05PM -0300, James Almer wrote: > On 10/4/2020 4:41 PM, Michael Niedermayer wrote: > > Fixes: OOM > > Fixes: > > 23817/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-6300869057576960 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > --- > > libavcodec/h2645_parse.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c > > index 0f98b49fbe..61105a6eb5 100644 > > --- a/libavcodec/h2645_parse.c > > +++ b/libavcodec/h2645_parse.c > > @@ -467,7 +467,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const > > uint8_t *buf, int length, > > memset(pkt->nals + pkt->nals_allocated, 0, sizeof(*pkt->nals)); > > > > nal = &pkt->nals[pkt->nb_nals]; > > - nal->skipped_bytes_pos_size = 1024; // initial buffer size > > + nal->skipped_bytes_pos_size = FFMIN(1024, > > 1+(extract_length>>4)); // initial buffer size > > Why is there even an initial buffer? Why not just let > ff_h2645_extract_rbsp() allocate it when needed?
i wondered that too and assumed it was done that way to avoid spending cpu cycles on reallocations later [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
signature.asc
Description: PGP signature
_______________________________________________ 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".
