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
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
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 du
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 al
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 - drain all decoded fr
