On Wed, 18 Apr 2018 15:46:55 -0300 James Almer <jamr...@gmail.com> wrote:
> On 4/18/2018 3:34 PM, Jan Ekström wrote: > > On Wed, Apr 18, 2018 at 7:53 PM, wm4 <nfx...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
