On Mon, 3 Jul 2017 20:57:21 +0200
Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> The old API did that just fine, and if we provide
> a compatibility layer it should at least be compatible.
> For the test-case (feeding AVParser output directly to
> decoder, failing to discard 0-size packets) just discarding
> 0-size packets at the start works, but not sure if in some
> cases we might want to pass them on to e.g. allow retrieving
> additional pending frames.
> ---
> libavcodec/decode.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 052f93d82f..c63090f137 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -842,6 +842,7 @@ static int compat_decode(AVCodecContext *avctx, AVFrame
> *frame,
> avci->compat_decode = 1;
>
> if (avci->compat_decode_partial_size > 0 &&
> + pkt->size &&
> avci->compat_decode_partial_size != pkt->size) {
> av_log(avctx, AV_LOG_ERROR,
> "Got unexpected packet size after a partial decode\n");
> @@ -902,7 +903,10 @@ finish:
> ret = FFMIN(avci->compat_decode_consumed, pkt->size);
> }
> avci->compat_decode_consumed = 0;
> - avci->compat_decode_partial_size = (ret >= 0) ? pkt->size - ret : 0;
> + // for compatibility with old API behaviour handle
> + // 0-size specially
> + if (pkt->size)
> + avci->compat_decode_partial_size = (ret >= 0) ? pkt->size - ret : 0;
>
> return ret;
> }
I thought it was decided that 0-sized packets are always disallowed for
encoding? Also, 0-sized packets are drain packets even with the old
API, and thus could never properly work. You just relied in implicit
restart behavior (i.e. leaving the drained state by feeding a new
non-0-sized packet), which also didn't work with all decoders.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
