[FFmpeg-devel] [PATCH] avformat/mov: Don't allocate unnecessarily large blocks of memory

[FFmpeg-devel] [PATCH] avformat/mov: Don't allocate unnecessarily large blocks of memory

[Hendi]

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(+)

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".

Re: [FFmpeg-devel] [PATCH] avformat/mov: Don't allocate unnecessarily large blocks of memory

["zhilizhao(赵志立)"]

> 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".

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avformat/mov: Don't allocate unnecessarily large blocks of memory

[Hendi]

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.
_______________________________________________
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".