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

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

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

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

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

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

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

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

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

Fixes a bug with flushing decoders during stream_loop. Note that the issue is also averted if we skip flushing altogether. From 2d3f9b06092d1a0ac09d9b2d1b86fbf6692282e4 Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Thu, 15 Mar 2018 15:01:53 +0530 Subject: [PATCH] ffmpeg.c