[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