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? The idea is that on OOM, libavcodec mallocs fail and we return gracefully. If that doesn't happen, we want to fix it. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
