| Message ID | 39bf9eb1-3d27-b8f9-59ce-3c4377f4e944@gmail.com |
|---|---|
| State | Accepted |
| Commit | 8ad83044b47a2544907562f5e8fd11dd1a62ef82 |
| Headers | show |
On 3/16/2018 10:24 AM, 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. Ping.
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@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 [...]
On 3/21/2018 3:02 AM, Michael Niedermayer wrote: > > do you want to also create a fate test for this Can you suggest an existing fate sample file that I can use? Ideally, a stream of a video codec with some delay. Seems to me most samples in the suite are anomalous or broken in one way or the other. Not ideal candidates to test some other feature than they were originally intended for. Regards, Gyan
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index ee7258fcd1..3c18e06713 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -4170,12 +4170,6 @@ static int seek_to_start(InputFile *ifile, AVFormatContext *is) ist = input_streams[ifile->ist_index + i]; avctx = ist->dec_ctx; - // flush decoders - if (ist->decoding_needed) { - process_input_packet(ist, NULL, 1); - avcodec_flush_buffers(avctx); - } - /* duration is the length of the last frame in a stream * when audio stream is present we don't care about * last video frame length because it's not defined exactly */ @@ -4244,6 +4238,17 @@ static int process_input(int file_index) return ret; } if (ret < 0 && ifile->loop) { + AVCodecContext *avctx; + for (i = 0; i < ifile->nb_streams; i++) { + ist = input_streams[ifile->ist_index + i]; + avctx = ist->dec_ctx; + if (ist->decoding_needed) { + ret = process_input_packet(ist, NULL, 1); + if (ret>0) + return 0; + avcodec_flush_buffers(avctx); + } + } ret = seek_to_start(ifile, is); if (ret < 0) av_log(NULL, AV_LOG_WARNING, "Seek to start failed.\n");