[FFmpeg-devel] FFmpeg 3.4.1

[Hendrik Leppkes]

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).

- Hendrik