On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote:
> Kieran Kunhya: > > On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt < > > andreas.rheinha...@gmail.com> wrote: > > > >> Up until now, the H.264 parser has allocated a new buffer for every > >> frame in order to store the unescaped RBSP in case the part of the RBSP > >> that will be unescaped contains 0x03 escape bytes. This is expensive > >> and this commit changes this: The buffer is now kept and reused. > >> > >> For an AVC file with an average framesize of 15304 B (without in-band > >> parameter sets etc.) and 132044 frames (131072 of which ended up in the > >> results) this reduced the average time used by the H.264 parser from > >> 87708 decicycles (excluding about 1100-1200 skips in each iteration) > >> to 16963 decicycles (excluding about 10-15 skips in each iteration). > >> The test has been iterated 10 times. > >> > > > > If I understand correctly, this patch means if you have a large frame (or > > large NAL) you are stuck with the large allocation of memory until the > > decoder is closed. > > Not sure if you have read the discussion here > > https://patchwork.ffmpeg.org/patch/5631/ > > > > Kieran > > > I am aware of said discussion; and also of your solution [1] to it. It > actually does exactly the same as I propose for the parser: It keeps a > single buffer that does not shrink. Given that this is used for the > decoders (and for cbs_h2645), I didn't deem this to be problematic. > (There is clearly no quadratic memory usage and what Derek warns about > (with huge NALs at specific positions) is a no issue for both.) > > - Andreas > > [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219100.html My solution frees the buffer when it's done. With yours it stays around as a large buffer essentially forever. Kieran _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".