On Thu, Apr 19, 2018 at 12:56:05AM +0200, wm4 wrote: > On Thu, 19 Apr 2018 00:40:21 +0200 > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > On Wed, Apr 18, 2018 at 11:55:09PM +0200, Paul B Mahol wrote: > > > On 4/18/18, wm4 <nfx...@googlemail.com> wrote: > > > > On Wed, 18 Apr 2018 23:15:47 +0200 > > > > Michael Niedermayer <mich...@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 > > > >> > <mich...@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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
