Thank you Kieran, Michael, Derek, and Carl. I ran some benchmarks and the patch I provided really does have a speed impact so I was considering alternative ways to achieve the same result. After a little thought last week I came to the same conclusion as Michael that a single rbsp_buffer per packet, with the nals pointing into that would be ideal because * allows a single allocation for all the NALs, sized to the size of the packet (+ padding. see next) * I think the padding is only to allow unchecked bitstream reading, so we only need 1 unit of padding (MAX_MBPAIR_SIZE) if we have a single buffer, rather than 1 per NAL. Also IIRC it used to be this way a long time ago.
Likewise skipped_bytes_pos could also be made a single buffer for the packet rather than 1 per NALU. Probably not as big a benefit to be made there though, besides avoiding some allocations. I was going to prepare a patch, but it sounds like Kieran is going to. Thank you Kieran. Let me know if there's anything you want me to do, or if you would prefer me to do it for the experience. As for the NAL memory pool, I think I see what you mean. You are saying h264dec.c is reusing the H2645Packet packet in decode_nal_units, so any growth in nals_allocated from previous packets carries over to later packets, and also the nals themselves also carry over even if the current packet has small pkt->nb_nals. Moving rbsp_buffer (and maybe skipped_bytes_pos) out of the nals and into H2645Packet should fix the worst of this. On Tue, Oct 31, 2017 at 1:28 PM, Kieran Kunhya <kier...@obe.tv> wrote: > > > > Am I missing something here? > > > > P.S. I see Kieran mailed the same thing as I wrote this. > > > > Further to Derek's excellent explanation, I think the best way is to go > back to the old "in-place" NAL parsing code for H264. > I will prepare a patch to do this. > > Kieran > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -- Nikolas Bowe | SWE | nb...@google.com | 408-565-5137 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
