[FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:
> On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> >> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> >> <michael at niedermayer.cc> wrote:
> >> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> >> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer <michael at niedermayer.cc>:
> >> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> >> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer <michael at niedermayer.cc>:
> >> >> >> > Hi all
> >> >> >> >
> >> >> >> > I intend to make 3.4.1 very soon
> >> >> >>
> >> >> >> Shouldn't we first decide on how to proceed with #6775?
> >> >> >
> >> >> > This would be ideal.
> >> >> >
> >> >> > IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04
> >> >>
> >> >> This was confirmed by more than one developer, yes.
> >> >>
> >> >> > I see a patch that is said to improve 6775, can that be applied and
> >> >> > would that resolve this ?
> >> >>
> >> >> Iiuc, it would not completely resolve the issue, see:
> >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> >> >>
> >> >> > If so why was it not applied yet ?
> >> >>
> >> >> The patch did not get support here, see:
> >> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> >> >> in compat_decode
> >> >
> >> >
> >> > Is someone working on fixing this better than with the available patch ?
> >> >
> >>
> >> I don't even agree this needs fixing. Those projects use the API wrong.
> >
> > Had we documented the correct/wrong use precissely in the past when
> > these wrong uses where written ?
> >
> > Because if it was documented then few should have made the mistake.
> > But it seems this affects multiple projects, so i wonder if our API
> > really excluded the use
> >
> 
> Apparently not well enough, but I also don't even understand why you
> would *want* to drain in the middle of decoding.
> 
> The only mention of sending NULL/0 packets (in 3.0 docs, before the
> new API was introduced) do include the "at the end", however.
> 
> From CODEC_CAP_DELAY:
>  * Decoders:
>  * The decoder has a non-zero delay and needs to be fed with avpkt->data=NULL,
>  * avpkt->size=0 at the end to get the delayed data until the decoder no longer
>  * returns frames.
> 
> From avcodec_decode_video2
> * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a delay
> * between input and output, these need to be fed with avpkt->data=NULL,
> * avpkt->size=0 at the end to return the remaining frames.
> 
> There is a few more mentions of the same concept, but as far as I can
> see all include the key words "at the end".
> 

> For the suggested patch, draining and flushing in the middle of a
> bitstream is still going to result in problems, though, since it
> removes all reference frames, for example.
> The original behavior cannot really be stored, which was to just keep
> feeding frames into the decoder after a drain without a flush.
> However, some decoders actually crashed when you did this, so this was
> a rather unsafe action to begin with (not an issue any longer, since
> this pattern is now blocked).

Did the previous code really work if the frame after a flush was not a
new keyframe or there was some use of previous references ?


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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171118/fdbb097c/attachment.sig>