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. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
