[FFmpeg-devel] libavcodec memory usage

[Michael Niedermayer]

On Tue, Jan 03, 2017 at 12:26:59PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, Jan 3, 2017 at 12:16 PM, Matthieu Beghin <
> matthieu.beghin at garagecube.com> wrote:
> 
> >
> > > On 03 Jan 2017, at 17:55, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jan 3, 2017 at 11:44 AM, Matthieu Beghin <
> > > matthieu.beghin at garagecube.com> wrote:
> > >
> > >>> I'm assuming that you're talking about 8K H264 with pixfmt=yuv420p10?
> > 8K
> > >> yuv420p10 frames are 100MB
> > >>
> > >> Correct
> > >>
> > >>> 32 plus delayed output and current_pic gives H264_MAX_PICTURE_COUNT =
> > 36
> > >> without threading: 36*100=3.6GB.
> > >>
> > >> What do you mean by "delayed output” ? Can you link me to a document ?
> > >
> > >
> > > Out-of-order coded P-frames, they are buffered internally but not counted
> > > (and thus extra) on top of the max_refs value. I believe the spec calls
> > > this dpb (delayed pic buffer).
> > >
> > >> Or maybe consider ditching 32bit support?
> > >>
> > >> Unfortunately, that’s 10 years old app using OSX Carbon library (not 64
> > >> bits), and rewriting that part would be too much work.
> > >>
> > >
> > > I'm frowning at you. Really badly.
> > >
> > > As an alternative, is there a way to know how much bytes are buffered ?
> > >> Iterating buffered frames ?
> > >
> > >
> > > What are you hoping to accomplish by knowing how many bytes are buffered?
> > > It doesn't solve the problem? But anyway, check
> > > H264Context->short/long_ref[]; delayed_pic[] gives you the delayed
> > output.
> > >
> >
> > I’m trying to let people use 8k movies if it will fit, but in case it
> > would use more than 1 GB, refuse to load the file. My application is a live
> > application, it cannot crash, and actually, it can...
> >
> > So to know how much bytes livavcodec is using, I have to know the number
> > of frames / field, if it is interlaced and the number of delayed frames,
> > that's correct ?
> >
> > How can I know the number of frames / field ?
> > To know if it’s interlaced: AVFrame::interlaced_frame
> > Number of delayed frames ?
> >
> > Another solution is to start playing the movie and to check the buffered
> > data amount each time I decode a frame, then stop the movie if it uses more
> > than 1 GB...
> > In this case, just iterating H264Context->short/long_ref[]; delayed_pic[]
> > would be enough ?
> > How can I get the H264Context ?
> 
> 
> You can't access H264Context outside libavcodec without hacks...
> 
> Does something in libavcodec crash if you use too much mem? (If so: what?
> We want to fix this...) Or something else?
> 

> The idea is that on OOM, libavcodec mallocs fail and we return gracefully.
> If that doesn't happen, we want to fix it.

yes

but at least on linux by default the kernel will kill a process that
touches too much memory *malloc() doesnt fail, its the write into
the memory that triggers the kill and this may or may not be the
process one wants killed. iam not sure what osx does

ive never tried it but on linux
If one wishes to get a failure at malloc time then one can disable
overcommit in te kernel
(which causes problems for some things like fork() and some applications IIUC)

or use some OS per process limits on
heap use, that will of course limit the whole process and anything
from the user app to any API&lib that executes in the process used by
the app will have to cope with malloc failures gracefully

or run libavcodec/format in a seperate process and use OS features
to limit the memory use of that process to get clean malloc failures
or get it killed without risk to other processes.

or one can use "[FFmpeg-devel] [PATCH 3/3] avutil/mem: Support limiting the heap usage"
to add a option to limit memory use without seperate processes, but
that patch is unpopular

These issues should be documented because i think some lib users dont
understand it.
documented with examples would be best.
Matthieu, would you be interrested in writing such documentation ?
maybe on the wiki ?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20170103/600517c9/attachment.sig>