[FFmpeg-devel] [PATCH] avformat/tls_schannel: fix the return value on EOF

wm4 nfxjfg at googlemail.com
Wed Apr 18 22:10:35 EEST 2018


On Wed, 18 Apr 2018 15:46:55 -0300
James Almer <jamrial at gmail.com> wrote:

> On 4/18/2018 3:34 PM, Jan Ekström wrote:
> > On Wed, Apr 18, 2018 at 7:53 PM, wm4 <nfxjfg at googlemail.com> wrote:  
> >>
> >> Maybe we should consider reverting this whole avio EOF change for the
> >> release? So many breakages...  
> > 
> > While I have kind of felt like this for a while now, I am just not
> > sure if we can find all the things where with or without mention
> > things have been poked to fix issues with it, which would now have to
> > all be reverted. Also we already angered API users once with this
> > change (albeit I'm not sure if it ever ended up in release yet?), so
> > I'm not sure if we want to do it again. Of course as I mentioned if
> > this was never in any release then that is kind of not relevant.  
> 
> I think it was not in any release, so if we revert anything, we do it
> /now/. ffmpeg 4.0 has been delayed enough as is.

Uh, good point I guess. Plus a revert could cause other regressions in
FFmpeg. JEEB makes a good point about how we might need to find or
change EOF fixes that were made after the initial commits that changed
the behavior.

> Mind, quite a few downstream projects use git head, but afaik there was
> a commit that added temporary backwards compat code so most of such
> users shouldn't have noticed anything.

This is only a problem if any project explicitly relies on getting
AVERROR_EOF, and ignores 0. User code is compatible with older ffmpeg
most likely will consider both 0 and AVERROR_EOF to be eof. So I don't
expect too many problems here, although a revert _could_ break API
users.

I still would love if we could make 0 mean EOF again, with the only
change that the aviobuf read loop exits on 0 instead of retrying. This
would not be very disruptive and is unlikely to break anything. Even if
code was changed to return AVERROR_EOF instead of 0, the change would
not break it.

The only incompatibility is with code that either implements avio and
was changed to return 0 in cases that mean "retry" (like the FFmpeg UDP
code), or application code which was changed to ignore 0 returns and
check _only_ for AVERROR_EOF (unlikely).

I doubt I want to send a patch though, because I'd only stir up more
shit.


More information about the ffmpeg-devel mailing list