[FFmpeg-devel] FFmpeg 3.3

[wm4]

On Tue, 14 Mar 2017 14:19:24 +0000
Rostislav Pehlivanov <atomnuker at gmail.com> wrote:

> On 14 March 2017 at 13:38, wm4 <nfxjfg at googlemail.com> wrote:
> 
> > On Tue, 14 Mar 2017 10:24:10 -0300
> > James Almer <jamrial at gmail.com> wrote:
> >  
> > > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:  
> > > > On 14 March 2017 at 11:29, Michael Niedermayer <michael at niedermayer.cc  
> > >  
> > > > wrote:
> > > >  
> > > >>
> > > >> What about the spherical API size_t / uint32_t issue ?
> > > >> we can change it before the release but not after it
> > > >>
> > > >>  
> > > > IMO its better to have the same type on all platforms. It also doesn't  
> > make  
> > > > sense to use size_t for something describing a position.  
> > >
> > > wm4 argued it would generate problems for being different than libav's.
> > > We don't care about ABI compatibility anymore so struct field size or
> > > position isn't a problem.
> > >
> > > What kind of trouble would having the function signatures use uint32_t
> > > here and size_t on libav generate? It's technically breaking API
> > > compatibility i guess.  
> >
> > I'm mostly thinking about things like overflow checks. And of course,
> > you know, the damn user API.
> >
> >  
> Since the only way to currently get the (float) value of the position on
> any platform is to measure its size, convert it to bits and calculate the
> limit and divide it, changing the type to a static wouldn't cause any
> problems for someone already doing this and will keep compatibility with
> libav. Someone who assumes size_t is always going to be 64 or 32 bits will
> be disappointed when their code doesn't work on MIPS/32 bit stuff but its
> their fault for incorrectly assuming that and its our fault for letting
> this patch in with size_t in the first place, so we ought to fix it.

Feel free to send a patch to Libav. Hopefully I won't be the one who
allows subtle and pointless API divergence over silly reasons.