[FFmpeg-devel] libavcodec memory usage

[Ronald S. Bultje]

Hi,

On Tue, Jan 3, 2017 at 4:35 PM, Matthieu Beghin <
matthieu.beghin at garagecube.com> wrote:

> Hi,
>
> > On 03 Jan 2017, at 18:26, Ronald S. Bultje <rsbultje at gmail.com> 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?
>
> I’m generally blocked by crashes in Apple nVidia GL driver. When I’m not
> blocked by my own assertions (I should use a macro…) but anyway if the GL
> driver calls crash I can’t reach memory limit.


Hm, right... OK, yeah, I understand the issue, but I somehow doubt there's
an easy way to resolve that that isn't disgustingly hacky on our side.
Really, if they crash, they need to provide a solution. If it is critical
that it doesn't crash, you most likely want to run that portion as a
separate process with shmem/whatever so if it crashes, your app stays
alive, but I'm obviously not in a position to make design recommendations
to you. You know that code better than me ;)

> The idea is that on OOM, libavcodec mallocs fail and we return gracefully.
> > If that doesn't happen, we want to fix it.
>
> If I have any crash in FFMPEG when reaching memory limit, I’ll document it
> and send you the info.


Thanks :)

Ronald