[FFmpeg-devel] FFmpeg 3.3

Hendrik Leppkes h.leppkes at gmail.com
Tue Mar 14 18:02:34 EET 2017


On Tue, Mar 14, 2017 at 4:49 PM, wm4 <nfxjfg at googlemail.com> wrote:
> 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.

Using "API divergence" as an excuse to accept silly decision is
equally silly, if not more so.

- Hendrik


More information about the ffmpeg-devel mailing list