On Fri, 9 Mar 2018 21:57:38 +0100 Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Fri, Mar 9, 2018 at 9:52 PM, wm4 <nfx...@googlemail.com> wrote: > > On Fri, 9 Mar 2018 13:31:45 -0300 > > James Almer <jamr...@gmail.com> wrote: > > > >> On 3/9/2018 12:47 PM, Derek Buitenhuis wrote: > >> > On 3/9/2018 3:22 PM, James Almer wrote: > >> >> Yes, but it's slower, and the buffer is guaranteed to be written to with > >> >> actual data after being allocated. > >> >> > >> >> This is a filter that may run once per processed packet, so the less > >> >> overhead the better. > >> > > >> > Not sure I buy the "speed" argument here, but OK. > >> > > >> > - Derek > >> > >> There's really nothing to win zeroing then immediately writing actual > >> data on top of it. > >> > > > > Except code clarity and robustness? > > We use this sort of pattern in all sorts of places where buffers are > read and padded. Its clear enough. Well, the fact that there are patches every once in a while that fix places where this was not correctly done could hint otherwise. Not that I want to make a huge discussion about it (though I always disliked this padding requirement). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
