[FFmpeg-devel] FFmpeg 3.5 / 4.0

[wm4]

On Thu, 19 Apr 2018 02:19:06 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Apr 19, 2018 at 12:56:05AM +0200, wm4 wrote:
> > On Thu, 19 Apr 2018 00:40:21 +0200
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> >   
> > > On Wed, Apr 18, 2018 at 11:55:09PM +0200, Paul B Mahol wrote:  
> > > > On 4/18/18, wm4 <nfxjfg at googlemail.com> wrote:    
> > > > > On Wed, 18 Apr 2018 23:15:47 +0200
> > > > > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > > >    
> > > > >> On Wed, Apr 18, 2018 at 04:09:41PM +0200, Hendrik Leppkes wrote:    
> > > > >> > On Mon, Apr 16, 2018 at 1:24 PM, Michael Niedermayer
> > > > >> > <michael at niedermayer.cc> wrote:    
> > > > >> > > On Sat, Apr 14, 2018 at 02:04:43PM +0200, Michael Niedermayer wrote:    
> > > > >> > >> On Fri, Apr 13, 2018 at 12:53:08AM +0200, Michael Niedermayer wrote:
> > > > >> > >>    
> > > > >> > >> > On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer
> > > > >> > >> > wrote:    
> > > > >> > >> > > Hi
> > > > >> > >> > >
> > > > >> > >> > > Its 4 months since 3.4 was branched so its time for a new major
> > > > >> > >> > > release
> > > > >> > >> > >
> > > > >> > >> > > Is 4.0 or 3.5 preferred ?
> > > > >> > >> > > Any name suggestions ?
> > > > >> > >> > >
> > > > >> > >> > > If there are no objections i will likely make that release in the
> > > > >> > >> > > next weeks    
> > > > >> > >> >
> > > > >> > >> > more time has passed than intended ...
> > > > >> > >> >
> > > > >> > >> > what issues do remain that need to be fixed before the release ?
> > > > >> > >> > I see fate.ffmpeg.org is not looking that well (compared to most
> > > > >> > >> > releases in the past) i remember this being pretty much green
> > > > >> > >> > longer ago
> > > > >> > >> > do people want these to be fixed before the release ?    
> > > > >> > >>
> > > > >> > >> ok, so, my plan is to create a release/4.0 branch from master in the
> > > > >> > >> next
> > > > >> > >> 24-48 hours unless theres some issue brought to my attention (CC me
> > > > >> > >> just to
> > > > >> > >> be sure if theres an issue)
> > > > >> > >>
> > > > >> > >> then wait 2 days or so and backport any newly found bugfixes to
> > > > >> > >> release/4.0
> > > > >> > >> and then make the release finally
> > > > >> > >>
> > > > >> > >> delays at any point are possible due to issues, lack of time or
> > > > >> > >> other.
> > > > >> > >>
> > > > >> > >> as name i think kierans suggestion of Wu would make sense. IIRC we
> > > > >> > >> had
> > > > >> > >> no name suggested by more than 1 developer. Please correct me if i
> > > > >> > >> miscounted i did only briefly re-check the mails in the thread.    
> > > > >> > >
> > > > >> > >
> > > > >> > > release/4.0 branched
> > > > >> > > next is the release in a few days.
> > > > >> > > If theres something i should wait for please say so and CC me
> > > > >> > > also please backport all bugfixes to 4.0    
> > > > >> >
> > > > >> > I have two more fixes that should really go in 4.0, one is the
> > > > >> > tls_schannel fix that I plan to push soon (I'm the author of that
> > > > >> > module, so unless someone says otherwise soon), and the MSVC configure
> > > > >> > breakage introduced in the last 2 days.
> > > > >> > Not sure when you planned to tag, but hopefully both of those are
> > > > >> > resolved by tomorrow afternoon.    
> > > > >>
> > > > >> well i had a bad headache today and iam a bit behind now with stuff
> > > > >> so i likely wont be ready before tomorrow evening either.    
> > > > >
> > > > > Please also wait with the release until we've sorted out the general
> > > > > avio EOF mess.    
> > > >     
> > >   
> > > > No, that need to wait 5.0    
> > > 
> > > +1  
> > 
> > At this point it won't be possibly anymore, so it has to happen for
> > 4.0. Also why would we release something that is likely to break even
> > more API users? Wouldn't you agree that bugs need to be fixed.  
> 
> The API we have now, has been discussed, implemented and tested quite a
> while ago.

It was about half a year ago, and we're finding new problems all the
time. Like schannel just a few days ago.

If we release it as it is, application users will suffer from these bugs
too.

> That was the time for everyone to bring their oppinions in.

I wasn't on the list at that time, you know why.

> About API change, was 0 ever documented to mean EOF ?
> If not, AVERROR_EOF was documented so iam not sure if the bug is not
> in code returning 0 for EOF in cases where this was not documented.
> 
> Thus rather a long standing bug that got fixed now instead of a new one
> 
> I looked a bit at the documentation but i couldnt find a reference to
> 0 means EOF, i looked at a old release to make sure iam not basing this
> on a recent change
> It is very possible iam missing something, in which case someone please
> correct me and
> 
> Ive not checked all docs but if i look at 
> avio_read()
> /**
>  * Read size bytes from AVIOContext into buf.
>  * @return number of bytes read or AVERROR
>  */
>  
>  0 is not EOF here in the API

It doesn't mention EOF at all. In practice, 0 and AVERROR_EOF have been
mixed inside and outside of ffmpeg all the time. In fact, the EOF
change immediately triggered regressions in a bunch of FFmpeg users at
the time.

Since you always argue for strict API compatibility, and going ways to
ensure it, you arguing the other way is quite strange.

>  if we look at the url,h one:
>  
>     /**
>      * Read data from the protocol.
>      * If data is immediately available (even less than size), EOF is
>      * reached or an error occurs (including EINTR), return immediately.
>      * Otherwise:
>      * In non-blocking mode, return AVERROR(EAGAIN) immediately.
>      * In blocking mode, wait for data/EOF/error with a short timeout (0.1s),
>      * and return AVERROR(EAGAIN) on timeout.
>      * Checking interrupt_callback, looping on EINTR and EAGAIN and until
>      * enough data has been read is left to the calling function; see
>      * retry_transfer_wrapper in avio.c.
>      */
>     int     (*url_read)( URLContext *h, unsigned char *buf, int size);
> 
> it also doesnt say 0 is EOF

That doesn't explain how EOF is handled.

> now, this is release/1.0 rather long ago its not a change
> 
> The only functions which i could find that are documented to return 0 on EOF
> are:
> 
>  * @note return 0 if EOF, so you cannot use it if EOF handling is
>  *       necessary
> ...
> int          avio_r8  (AVIOContext *s);
> unsigned int avio_rl16(AVIOContext *s);
> unsigned int avio_rl24(AVIOContext *s);
> unsigned int avio_rl32(AVIOContext *s);
> uint64_t     avio_rl64(AVIOContext *s);
> unsigned int avio_rb16(AVIOContext *s);
> unsigned int avio_rb24(AVIOContext *s);
> unsigned int avio_rb32(AVIOContext *s);
> uint64_t     avio_rb64(AVIOContext *s);
> 
> Also these dont say 0 means EOF, they say 
> "you cannot use it if EOF handling is necessary"

These functions inherently can't signal errors or EOF at all, so your
argumentation is very misleading. I never claimed that 0 means EOF
because these functions return 0 on EOF.

> 
> I do faintly remember that MANY years ago there was some intend to have 
> the API match the file stuff with 0 being EOF. But iam not sure if that 
> was actually documented or intended for network protocols where 0 sized 
> packets can occur.
> 
> also 4.0 is a new major version with new major API version

And? The deprecation period is 2 years. Everything from 2 years ago
must still work. Right now, at least EOF handling for datagram streams
will be broken with no backwards compatibility if a user has a custom
avio context and returns 0 for EOF (which previously worked).