[FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Michael Niedermayer]

On Tue, Oct 31, 2017 at 08:24:37PM +0000, Derek Buitenhuis wrote:
> On 10/31/2017 2:25 AM, Michael Niedermayer wrote:
> > (though as said, this fix is not ideal or complete, I would very much
> >  prefer if this would be fixed by using a single buffer or any other
> >  solution that avoids the speedloss.)
> 
> Using a single buffer would be marginally faster, but it does not solve
> the underlying problem, which is that the NAL "cache" (nals_allocated)
> seems to be cumulative, and the size of each buffer in it seems to be
> the largest observed size of a NAL in that position.
> 
> Consider I could craft a stream that contains, in order:
> 
> Has 1999 tiny NALs, followed by 1 10MiB NAL, in packet 1.
> Has 1998 tiny NALs, followed by 1 10MiB NAL, in packet 2.
> .
> .
> .
> Has 500 tiny NALs, followed by 1 10MiB NAL, in packet 1500.
> .
> .
> .
> And so forth.
> 
> The result would be that we have 2000 10MiB buffers allocated
> in the NAL memory "pool" (nals_allocated == 2000), which will
> persist until the decode is deinitialized.
>
> Am I missing something here?

The idea would be that there would only be one uint8_t buffer and the
2000 entries from te pool would point into that.
So as a larger NAL shifts through the 2000 the pointers would get
distributed differently but the size would not grow
Any variable size buffer the H2645NAL needs would be such a "shared"
buffer

I dont know if theres anything that would make this non trivial to
implement.


>
> P.S. I see Kieran mailed the same thing as I wrote this.
> 
> - Derek
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171101/c8fbfc36/attachment.sig>