[FFmpeg-devel] [PATCH] ffmpeg.c - drain all decoded frames during stream_loop flush

[Michael Niedermayer]

On Fri, Mar 16, 2018 at 10:24:09AM +0530, Gyan Doshi wrote:
> Revised patch only drains 1 packet per call and loops via transcode_step()
> till EOF, just like when decoders are truly closed. Functionally the same
> result as first version.
> 
> On 3/15/2018 3:31 PM, Gyan Doshi wrote:
> >Fixes a bug with flushing decoders during stream_loop. Note that the issue
> >is also averted if we skip flushing altogether.

>  ffmpeg.c |   17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 31b6c25bedf841173ae26d8a26741ca3c327559c  v2-0001-ffmpeg.c-drain-all-decoded-frames-during-stream_l.patch
> From a19b5586ae343a2b36d9dce5a1343629ec0fb40f Mon Sep 17 00:00:00 2001
> From: Gyan Doshi <gyandoshi at gmail.com>
> Date: Thu, 15 Mar 2018 16:45:51 +0530
> Subject: [PATCH v2] ffmpeg.c - drain all decoded frames during stream_loop
>  flush
> 
> When a decoded stream is being looped, after each post-EOF rewind,
> decoders are flushed in seek_to_start(). This only drains 1 frame, and
> thus the output has a few frames missing at the tail of each iteration
> except the last.
> 
> With this patch, process_input is looped till process_input_packet
> reaches EOF.
> 
> Fixes #7081

Will apply

do you want to also create a fate test for this

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180320/6c7aae1d/attachment.sig>