[FFmpeg-devel] FFmpeg 3.5 / 4.0

Michael Niedermayer michael at niedermayer.cc
Thu Apr 19 03:19:06 EEST 2018


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.
That was the time for everyone to bring their oppinions in.

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
 
 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

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"


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

Thanks


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

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180419/064a17b6/attachment.sig>


More information about the ffmpeg-devel mailing list