| Message ID | 3b2f7e96-4cb6-cabe-8d0e-eb3beb965e93@googlemail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] avformat/mov: Don't allocate unnecessarily large blocks of memory | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/configure_loongarch64 | warning | Failed to apply patch |
| andriy/configure_x86 | warning | Failed to apply patch |
> On Jun 9, 2023, at 07:51, Hendi <finalcountdown72@googlemail.com> wrote: > > mov_try_read_block is regularly called with sizes such as 48 bytes, > but would allocate 1 MiB each time, hogging more and more memory > until playback ends. > > Fixes #7641 and #9243. It’s a quick fix, but I’m afraid the two tickets are caused by more deep pitfalls. It would be helpful if someone can provide a sample for test. > > Signed-off-by: Hendi <hendi48@freenet.de> > --- > libavformat/mov.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index a8d004e02b..2e4df42256 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c > @@ -6662,6 +6662,9 @@ static int mov_try_read_block(AVIOContext *pb, size_t size, uint8_t **data) > while (offset < size) { > unsigned int new_size = > alloc_size >= INT_MAX - block_size ? INT_MAX : alloc_size + block_size; > + if (size < new_size) { > + new_size = size; > + } > uint8_t *new_buffer = av_fast_realloc(buffer, &alloc_size, new_size); > unsigned int to_read = FFMIN(size, alloc_size) - offset; > if (!new_buffer) { > -- > 2.40.0.windows.1 > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 09.06.2023 04:47, "zhilizhao(赵志立)" wrote: > > It’s a quick fix, but I’m afraid the two tickets are caused by more deep > pitfalls. > > It would be helpful if someone can provide a sample for test. > I've uploaded a sample called bear-640x360-v_frag-cenc-senc.mp4. You can play it with -decryption_key ebdd62f16814d27b68ef122afce4ae3c. The code path is only taken for fragmented encrypted MP4 files. I was not able to use ffmpeg to produce a file that exhibits the same behavior. The mov_try_read_block function will be called with a size of 82 in this case. It's a very short sample, but for longer content this will be done every few seconds, whenever a new fragment starts. The encryption info is only freed when the format context is closed. That's not an inherent problem imo, but it does quickly escalate if you allocate a megabyte each time only to store a couple bytes.
diff --git a/libavformat/mov.c b/libavformat/mov.c index a8d004e02b..2e4df42256 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -6662,6 +6662,9 @@ static int mov_try_read_block(AVIOContext *pb, size_t size, uint8_t **data) while (offset < size) { unsigned int new_size = alloc_size >= INT_MAX - block_size ? INT_MAX : alloc_size + block_size; + if (size < new_size) { + new_size = size; + } uint8_t *new_buffer = av_fast_realloc(buffer, &alloc_size, new_size);
mov_try_read_block is regularly called with sizes such as 48 bytes, but would allocate 1 MiB each time, hogging more and more memory until playback ends. Fixes #7641 and #9243. Signed-off-by: Hendi <hendi48@freenet.de> --- libavformat/mov.c | 3 +++ 1 file changed, 3 insertions(+) unsigned int to_read = FFMIN(size, alloc_size) - offset; if (!new_buffer) {