[FFmpeg-devel] [PATCH v2] cpu: add a function for querying maximum required data alignment

wm4 nfxjfg at googlemail.com
Thu Sep 28 04:43:17 EEST 2017

On Wed, 27 Sep 2017 22:26:48 -0300
James Almer <jamrial at gmail.com> wrote:

> On 9/27/2017 9:59 PM, wm4 wrote:
> > On Wed, 27 Sep 2017 21:37:54 -0300
> > James Almer <jamrial at gmail.com> wrote:
> >   
> >>> API users can rely on it. So you better make sure that can't break.
> >>> Other aspects don't really matter.    
> >>
> >> What do you mean with this? Do i apply it or not? The function will
> >> return a value based on runtime cpuflags. The value is guaranteed to be
> >> correct, but how the user uses it is beyond our control.  
> > 
> > If the user uses the return value of the API to align pointers, and
> > then passes these pointers to ffmpeg functions that process data, they
> > must not crash or exhibit low performance. Or in other words, the
> > alignment returned by the function must be high enough. At least as
> > long as the global CPU flags are not changed afterwards.
> > 
> > So if this is correct, I see no reason not to apply this patch?
> > 
> > I'm not sure if your question was only about this patch, or potentially
> > later Libav commits that need to be merged.  
> Yes, i mentioned there's a commit after this one that makes use of the
> function internally, which based on the above (global CPU flags can be
> changed by the user), should probably not be applied in favor of keeping
> the current safe hardcoded STRIDE value.

I'd argue we should use this commit. But it doesn't matter too much,
since it doesn't affect the API. But only if the API function is
correct. If the API function were to become buggy because FFmpeg does
something else internally, the outcome would be worse.

> My question was, since it will not be used by ffmpeg itself, does it
> make sense adding it? You argued that yes (users may have use for it),
> so I'll merge it.

Yes, definitely.

More information about the ffmpeg-devel mailing list