[FFmpeg-devel] [PATCH] ffmpeg.c - drain all decoded frames during stream_loop flush
michael at niedermayer.cc
Tue Mar 20 23:32:16 EET 2018
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
> 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
do you want to also create a fate test for this
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the ffmpeg-devel