Re: [FFmpeg-devel] FFmpeg 3.3

[Nicolas George]

Le sextidi 16 germinal, an CCXXV, James Almer a écrit :
> Apparently, av_strreplace didn't even get a version bump or an
> APIChanges line. This whole situation has been was overall pretty
> sloppy.

I do not see the point of throwing even more blame around; what is done
is done.

> I don't know what would be best. Master and release/3.3 have diverged,
> including separate version bumps. Renaming and backporting might be
> technically harmless,

Until http://ffmpeg.org/download.html points to ffmpeg-3.3.tar.bz2,
there can be no harm.

>   but still ugly.

Staying until the end of time with an ill-named function is ugly too.
(Did you not in the past advocate consistency above a lot of things?)
Releasing with an ill-named function and going the deprecation dance is
ugly too.

Between three uglies, I say we choose the one that will be forgotten a
week from now.

> I'd leave the decision to Michael since he's the release manager. But
> really, there should be more than half a day for reviewers to comment
> before new public symbols are pushed and especially in an incomplete
> way...

The reproach has already been made to Steven, IMHO there is no need to
pile even more of it.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[James Almer]

On 4/5/2017 2:18 PM, Nicolas George wrote:
> Le quartidi 24 ventôse, an CCXXV, Michael Niedermayer a écrit :
>> are there any issues/tickets that block making 3.3 ?
> 
> There is the issue of av_strreplace() / av_strireplace() that needs to
> be decided and then possibly backported.
> 
> Regardss,

Apparently, av_strreplace didn't even get a version bump or an
APIChanges line. This whole situation has been was overall pretty
sloppy.
I don't know what would be best. Master and release/3.3 have diverged,
including separate version bumps. Renaming and backporting might be
technically harmless, but still ugly.

I'd leave the decision to Michael since he's the release manager. But
really, there should be more than half a day for reviewers to comment
before new public symbols are pushed and especially in an incomplete
way...

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Nicolas George]

Le quartidi 24 ventôse, an CCXXV, Michael Niedermayer a écrit :
> are there any issues/tickets that block making 3.3 ?

There is the issue of av_strreplace() / av_strireplace() that needs to
be decided and then possibly backported.

Regardss,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Carl Eugen Hoyos]

2017-04-01 0:51 GMT+02:00 Hendrik Leppkes :
> On Sat, Apr 1, 2017 at 12:39 AM, Carl Eugen Hoyos  wrote:
>> 2017-03-14 12:29 GMT+01:00 Michael Niedermayer :
>>
>>> are there any issues/tickets that block making 3.3 ?
>>
>> What is the license of avisynth / avxsynth?
>> If it is GPL (as I suspect) or less permissive we should not immediately
>> make a release imo.
>
> AviSynth itself is GPLv2, but why does the license of AviSynth matter
> for our releases?

Because I suggest to fix the missing GPL dependency for AviSynth
before releasing.

Patch sent, Carl Eugen

PS: Decklink also comes to mind...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Hendrik Leppkes]

On Sat, Apr 1, 2017 at 12:39 AM, Carl Eugen Hoyos  wrote:
> 2017-03-14 12:29 GMT+01:00 Michael Niedermayer :
>
>> are there any issues/tickets that block making 3.3 ?
>
> What is the license of avisynth / avxsynth?
> If it is GPL (as I suspect) or less permissive we should not immediately
> make a release imo.
>

AviSynth itself is GPLv2, but why does the license of AviSynth matter
for our releases?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Carl Eugen Hoyos]

2017-03-14 12:29 GMT+01:00 Michael Niedermayer :

> are there any issues/tickets that block making 3.3 ?

What is the license of avisynth / avxsynth?
If it is GPL (as I suspect) or less permissive we should not immediately
make a release imo.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Michael Niedermayer]

On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote:
> Hi all
> 
> are there any issues/tickets that block making 3.3 ?
> 
> What about the spherical API size_t / uint32_t issue ?
> we can change it before the release but not after it

Ive finally branched release/3.3 off
feel free to backport anything
we also need release notes and all that stuff

once we all agree ill make 3.3 from it

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[wm4]

On Tue, 14 Mar 2017 12:29:52 +0100
Michael Niedermayer  wrote:

> Hi all
> 
> are there any issues/tickets that block making 3.3 ?
> 
> What about the spherical API size_t / uint32_t issue ?
> we can change it before the release but not after it
> 

I will insist that

  avcodec, avformat: deprecate anything related to side data merging

will be part of the release.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Hendrik Leppkes]

On Tue, Mar 14, 2017 at 6:18 PM, wm4  wrote:
>
>> Now back to the current issue.
>>
>> Do you agree with the fact that uint32_t is a better technical choice?
>> (I think the main argument is that it's a pain to have proper FATE
>> coverage if you don't?)
>
> We've already established that the current way FATE is doing it is not
> a good idea. It relies on C ABI coincidences. It's equivalent to
> parsing file formats by using read() calls with pointers to structs.
> For example, big endian fate instances should be failing on side data
> represented by structs (but apparently we don't test side data contents
> anyway, only their size, which makes this whole side data discussion
> even more ridiculous).
>

We test the content, but it gets read as a struct and printed member
by member, not byte-dumped, so endianness doesn't change the result.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[wm4]

On Tue, 14 Mar 2017 17:59:38 +0100
Clément Bœsch  wrote:

> On Tue, Mar 14, 2017 at 05:33:41PM +0100, wm4 wrote:
> > On Tue, 14 Mar 2017 17:02:34 +0100
> > Hendrik Leppkes  wrote:
> >   
> > > On Tue, Mar 14, 2017 at 4:49 PM, wm4  wrote:  
> > > > On Tue, 14 Mar 2017 14:19:24 +
> > > > Rostislav Pehlivanov  wrote:
> > > >
> > > >> On 14 March 2017 at 13:38, wm4  wrote:
> > > >>
> > > >> > On Tue, 14 Mar 2017 10:24:10 -0300
> > > >> > James Almer  wrote:
> > > >> >
> > > >> > > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> > > >> > > > On 14 March 2017 at 11:29, Michael Niedermayer 
> > > >> > > >  > > >> > >
> > > >> > > > 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.  
> > 
> > Well, you're not the one who will have to deal with an increasing
> > number of different basic types on the same struct fields.
> > 
> > If we do this now, you can bet we'll change AVFrame.crop* from size_t
> > to something else too. And then if Libav changes AVFrame.width/height
> > to size_t too (like they apparently plan to), it will be even worse.
> > You probably don't care about this, because you won't have to deal with
> > the end result, but I'm not only going to have to use this subtle
> > different API, but I'll also probably contribute patches to both
> > projects, and then I'll have to change my patches to use the "correct"
> > type on each side. And what about potential project reunification?
> > Another idiotic thing we'll have to flame about?
> >   
> 
> We are diverging more and more API wise. Feel free to correct me, but I
> thought importing or not a change from Libav was dependent on two main
> factors:
> 
> - how much effort it will cause in a following merge?
> - is it technically a good change?
> 
> Beside the merge commits, with time we also diverged a lot in API, and not
> only in API additions, but also on internal breaking changes (typically in
> lavfi but not limited to).

These are only due to lack of communication.

> We know it's a problem for users who want to support both, but on the
> other hand, we can't always be shaped by Libav decisions, there is a need
> for a technical evaluations of the different solutions.

I doubt that.

> Now back to the current issue.
> 
> Do you agree with the fact that uint32_t is a better technical choice?
> (I think the main argument is that it's a pain to have proper FATE
> coverage if you don't?)

We've already established that the current way FATE is doing it is not
a good idea. It relies on C ABI coincidences. It's equivalent to
parsing file formats by using read() calls with pointers to structs.
For example, big endian fate instances should be failing on side data
represented by structs (but apparently we don't test side data contents
anyway, only their size, which makes this whole side data discussion
even more ridiculous).

Re: [FFmpeg-devel] FFmpeg 3.3

[wm4]

On Tue, 14 Mar 2017 13:50:53 -0300
James Almer  wrote:

> On 3/14/2017 1:33 PM, wm4 wrote:
> > On Tue, 14 Mar 2017 17:02:34 +0100
> > Hendrik Leppkes  wrote:
> >   
> >> On Tue, Mar 14, 2017 at 4:49 PM, wm4  wrote:  
> >>> On Tue, 14 Mar 2017 14:19:24 +
> >>> Rostislav Pehlivanov  wrote:
> >>>
>  On 14 March 2017 at 13:38, wm4  wrote:
> 
> > On Tue, 14 Mar 2017 10:24:10 -0300
> > James Almer  wrote:
> >
> >> On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> >>> On 14 March 2017 at 11:29, Michael Niedermayer 
> >>>  >>
> >>> 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.  
> > 
> > Well, you're not the one who will have to deal with an increasing
> > number of different basic types on the same struct fields.
> > 
> > If we do this now, you can bet we'll change AVFrame.crop* from size_t
> > to something else too. And then if Libav changes AVFrame.width/height
> > to size_t too (like they apparently plan to), it will be even worse.
> > You probably don't care about this, because you won't have to deal with
> > the end result, but I'm not only going to have to use this subtle
> > different API, but I'll also probably contribute patches to both
> > projects, and then I'll have to change my patches to use the "correct"
> > type on each side. And what about potential project reunification?
> > Another idiotic thing we'll have to flame about?
> > 
> > Can't you see what a giant heap of bullshit this is?  
> 
> I can see your point for other fields in other structs but in here
> size_t is simply wrong. It should have never been committed like
> this to begin with.

Why is it "simply wrong"?

> We could try to get libav to change it as well, but if they don't
> then at the very least this one (very obscure) struct will have to
> diverge between projects.

What about AVFrame.crop_top etc.?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Clément Bœsch]

On Tue, Mar 14, 2017 at 05:33:41PM +0100, wm4 wrote:
> On Tue, 14 Mar 2017 17:02:34 +0100
> Hendrik Leppkes  wrote:
> 
> > On Tue, Mar 14, 2017 at 4:49 PM, wm4  wrote:
> > > On Tue, 14 Mar 2017 14:19:24 +
> > > Rostislav Pehlivanov  wrote:
> > >  
> > >> On 14 March 2017 at 13:38, wm4  wrote:
> > >>  
> > >> > On Tue, 14 Mar 2017 10:24:10 -0300
> > >> > James Almer  wrote:
> > >> >  
> > >> > > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:  
> > >> > > > On 14 March 2017 at 11:29, Michael Niedermayer 
> > >> > > >  > >> > >  
> > >> > > > 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.
> 
> Well, you're not the one who will have to deal with an increasing
> number of different basic types on the same struct fields.
> 
> If we do this now, you can bet we'll change AVFrame.crop* from size_t
> to something else too. And then if Libav changes AVFrame.width/height
> to size_t too (like they apparently plan to), it will be even worse.
> You probably don't care about this, because you won't have to deal with
> the end result, but I'm not only going to have to use this subtle
> different API, but I'll also probably contribute patches to both
> projects, and then I'll have to change my patches to use the "correct"
> type on each side. And what about potential project reunification?
> Another idiotic thing we'll have to flame about?
> 

We are diverging more and more API wise. Feel free to correct me, but I
thought importing or not a change from Libav was dependent on two main
factors:

- how much effort it will cause in a following merge?
- is it technically a good change?

Beside the merge commits, with time we also diverged a lot in API, and not
only in API additions, but also on internal breaking changes (typically in
lavfi but not limited to).

We know it's a problem for users who want to support both, but on the
other hand, we can't always be shaped by Libav decisions, there is a need
for a technical evaluations of the different solutions.

Now back to the current issue.

Do you agree with the fact that uint32_t is a better technical choice?
(I think the main argument is that it's a pain to have proper FATE
coverage if you don't?)

If so, I'm assuming you believe that even if it's better, it's not worth
the breaking change for users. I do not share the feeling at all if it
reduces FATE coverage. If you share that sentiment, maybe it's worth
fighting for that technical argument where you want it to change. Why
would FFmpeg follow Libav even if you disagree with Libav's argument?

If not, then I think it's better to defend your technical disagreement
instead of using a political one. And maybe that size_t BS is going to
have acceptance here in FFmpeg and the problem will be solved that way.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[James Almer]

On 3/14/2017 1:33 PM, wm4 wrote:
> On Tue, 14 Mar 2017 17:02:34 +0100
> Hendrik Leppkes  wrote:
> 
>> On Tue, Mar 14, 2017 at 4:49 PM, wm4  wrote:
>>> On Tue, 14 Mar 2017 14:19:24 +
>>> Rostislav Pehlivanov  wrote:
>>>  
 On 14 March 2017 at 13:38, wm4  wrote:
  
> On Tue, 14 Mar 2017 10:24:10 -0300
> James Almer  wrote:
>  
>> On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:  
>>> On 14 March 2017 at 11:29, Michael Niedermayer >  
>>> 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.
> 
> Well, you're not the one who will have to deal with an increasing
> number of different basic types on the same struct fields.
> 
> If we do this now, you can bet we'll change AVFrame.crop* from size_t
> to something else too. And then if Libav changes AVFrame.width/height
> to size_t too (like they apparently plan to), it will be even worse.
> You probably don't care about this, because you won't have to deal with
> the end result, but I'm not only going to have to use this subtle
> different API, but I'll also probably contribute patches to both
> projects, and then I'll have to change my patches to use the "correct"
> type on each side. And what about potential project reunification?
> Another idiotic thing we'll have to flame about?
> 
> Can't you see what a giant heap of bullshit this is?

I can see your point for other fields in other structs but in here
size_t is simply wrong. It should have never been committed like
this to begin with.

We could try to get libav to change it as well, but if they don't
then at the very least this one (very obscure) struct will have to
diverge between projects.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[wm4]

On Tue, 14 Mar 2017 17:02:34 +0100
Hendrik Leppkes  wrote:

> On Tue, Mar 14, 2017 at 4:49 PM, wm4  wrote:
> > On Tue, 14 Mar 2017 14:19:24 +
> > Rostislav Pehlivanov  wrote:
> >  
> >> On 14 March 2017 at 13:38, wm4  wrote:
> >>  
> >> > On Tue, 14 Mar 2017 10:24:10 -0300
> >> > James Almer  wrote:
> >> >  
> >> > > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:  
> >> > > > On 14 March 2017 at 11:29, Michael Niedermayer 
> >> > > >  >> > >  
> >> > > > 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.

Well, you're not the one who will have to deal with an increasing
number of different basic types on the same struct fields.

If we do this now, you can bet we'll change AVFrame.crop* from size_t
to something else too. And then if Libav changes AVFrame.width/height
to size_t too (like they apparently plan to), it will be even worse.
You probably don't care about this, because you won't have to deal with
the end result, but I'm not only going to have to use this subtle
different API, but I'll also probably contribute patches to both
projects, and then I'll have to change my patches to use the "correct"
type on each side. And what about potential project reunification?
Another idiotic thing we'll have to flame about?

Can't you see what a giant heap of bullshit this is?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[wm4]

On Tue, 14 Mar 2017 14:19:24 +
Rostislav Pehlivanov  wrote:

> On 14 March 2017 at 13:38, wm4  wrote:
> 
> > On Tue, 14 Mar 2017 10:24:10 -0300
> > James Almer  wrote:
> >  
> > > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:  
> > > > On 14 March 2017 at 11:29, Michael Niedermayer  > >  
> > > > 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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Rostislav Pehlivanov]

On 14 March 2017 at 13:38, wm4  wrote:

> On Tue, 14 Mar 2017 10:24:10 -0300
> James Almer  wrote:
>
> > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> > > On 14 March 2017 at 11:29, Michael Niedermayer  >
> > > 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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[wm4]

On Tue, 14 Mar 2017 10:24:10 -0300
James Almer  wrote:

> On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> > On 14 March 2017 at 11:29, Michael Niedermayer 
> > 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.

If you don't like size_t, make Libav change it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[James Almer]

On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> On 14 March 2017 at 11:29, Michael Niedermayer 
> 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.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Rostislav Pehlivanov]

On 14 March 2017 at 11:29, Michael Niedermayer 
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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FFmpeg 3.3

[Michael Niedermayer]

Hi all

are there any issues/tickets that block making 3.3 ?

What about the spherical API size_t / uint32_t issue ?
we can change it before the release but not after it

Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Bodecs Bela]

2017.01.25. 9:40 keltezéssel, Tobias Rapp írta:

On 23.01.2017 02:11, Michael Niedermayer wrote:

Its a while since the last relase so ill make 3.3 within the next
week(s)
Name suggestions needed like always


What about "Hilbert", named after David Hilbert?

+1 vote



I also intend to make some new point releases from the currently
maintained branches if someone wants to backport something


If not already done, please backport commit 
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6d579d7c1bdc4126955cae7f385208e455685986


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Carl Eugen Hoyos]

2017-01-25 12:09 GMT+01:00 Tobias Rapp :

> Not sure about your definition of "regression".

An issue that was not reproducible with earlier versions (of FFmpeg).

> The given scenario works for FFmpeg <= 2.6 but fails with
> versions between 2.7 and 3.2.

Then the patch should of course be backported.

> Besides, I'd think the fix is low on side effect risks. What are your
> concerns?

That people start backporting random patches (as happened in the
past), making our releases that unfortunately see very limited
support even worse (backporting patches of course leads inevitably
to even more regressions).

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Tobias Rapp]

On 25.01.2017 11:59, Carl Eugen Hoyos wrote:

2017-01-25 11:47 GMT+01:00 Tobias Rapp :

On 25.01.2017 11:23, Carl Eugen Hoyos wrote:


2017-01-25 9:40 GMT+01:00 Tobias Rapp :


If not already done, please backport commit
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6d579d7c


This doesn't look as if it fixes a regression, does it?


It fixes the scenario where you create an AVI file > 256GiB
with FFmpeg and then try to read it back. Versions after
commit bbcc09518e0d1efc189a43ff0120c1a31f51c802
and without the fix will produce a longer video stream.


So it does not fix a regression?
In this case, I suggest not to backport the patch.


Not sure about your definition of "regression". The given scenario works 
for FFmpeg <= 2.6 but fails with versions between 2.7 and 3.2.


Besides, I'd think the fix is low on side effect risks. What are your 
concerns?


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Carl Eugen Hoyos]

2017-01-25 11:47 GMT+01:00 Tobias Rapp :
> On 25.01.2017 11:23, Carl Eugen Hoyos wrote:
>>
>> 2017-01-25 9:40 GMT+01:00 Tobias Rapp :
>>
>>> If not already done, please backport commit
>>> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6d579d7c
>>
>> This doesn't look as if it fixes a regression, does it?
>
> It fixes the scenario where you create an AVI file > 256GiB
> with FFmpeg and then try to read it back. Versions after
> commit bbcc09518e0d1efc189a43ff0120c1a31f51c802
> and without the fix will produce a longer video stream.

So it does not fix a regression?
In this case, I suggest not to backport the patch.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Tobias Rapp]

On 25.01.2017 11:23, Carl Eugen Hoyos wrote:

2017-01-25 9:40 GMT+01:00 Tobias Rapp :


If not already done, please backport commit
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6d579d7c


This doesn't look as if it fixes a regression, does it?


It fixes the scenario where you create an AVI file > 256GiB with FFmpeg 
and then try to read it back. Versions after commit 
bbcc09518e0d1efc189a43ff0120c1a31f51c802 and without the fix will 
produce a longer video stream.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Carl Eugen Hoyos]

2017-01-25 9:40 GMT+01:00 Tobias Rapp :

> If not already done, please backport commit
> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6d579d7c

This doesn't look as if it fixes a regression, does it?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Tobias Rapp]

On 23.01.2017 02:11, Michael Niedermayer wrote:

Its a while since the last relase so ill make 3.3 within the next
week(s)
Name suggestions needed like always


What about "Hilbert", named after David Hilbert?


I also intend to make some new point releases from the currently
maintained branches if someone wants to backport something


If not already done, please backport commit 
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6d579d7c1bdc4126955cae7f385208e455685986


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Michael Niedermayer]

On Mon, Jan 23, 2017 at 07:07:55AM +0100, Reto Kromer wrote:
> Michael Niedermayer wrote:
> 
> >Its a while since the last relase so ill make 3.3 within
> >the next week(s)
> 
> Thank you, Michael!
> 

> >I also intend to make some new point releases from the
> >currently maintained branches if someone wants to backport
> >something
> 
> I suggest to switch "Nash" 2.7.7 to the old releases (the
> last update has been made on 2016-04-30).

good idea, done that

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Jörn Heusipp]

On 01/23/2017 02:11 AM, Michael Niedermayer wrote:

I also intend to make some new point releases from the currently
maintained branches if someone wants to backport something


https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/367cac7827870054ae3bd6d4517e7b13f4f3f72c
needs to be applied to the 3.2 branch.

Regards,
Jörn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.3

[Reto Kromer]

Michael Niedermayer wrote:

>Its a while since the last relase so ill make 3.3 within
>the next week(s)

Thank you, Michael!

>I also intend to make some new point releases from the
>currently maintained branches if someone wants to backport
>something

I suggest to switch "Nash" 2.7.7 to the old releases (the
last update has been made on 2016-04-30).

Best regards, Reto

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FFmpeg 3.3

[Michael Niedermayer]

Hi all

Its a while since the last relase so ill make 3.3 within the next
week(s)
Name suggestions needed like always

I also intend to make some new point releases from the currently
maintained branches if someone wants to backport something

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel