Hi, On Tue, Jan 3, 2017 at 4:35 PM, Matthieu Beghin < matthieu.beg...@garagecube.com> wrote:
> Hi, > > > On 03 Jan 2017, at 18:26, Ronald S. Bultje <rsbul...@gmail.com> wrote: > > > > Hi, > > > > On Tue, Jan 3, 2017 at 12:16 PM, Matthieu Beghin < > > matthieu.beg...@garagecube.com> wrote: > > > >> > >>> On 03 Jan 2017, at 17:55, Ronald S. Bultje <rsbul...@gmail.com> wrote: > >>> > >>> Hi, > >>> > >>> On Tue, Jan 3, 2017 at 11:44 AM, Matthieu Beghin < > >>> matthieu.beg...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
