On Fri, May 4, 2018 at 8:13 AM, Matthieu Bouron
wrote:
> On Thu, May 03, 2018 at 10:24:49AM -0700, Aman Gupta wrote:
> > On Thu, May 3, 2018 at 12:33 AM, Matthieu Bouron <
> matthieu.bou...@gmail.com>
> > wrote:
> >
> > > On Wed, May 02, 2018 at 07:24:58PM -0700, Aman Gupta wrote:
> > > > From: A
On Thu, May 03, 2018 at 10:24:49AM -0700, Aman Gupta wrote:
> On Thu, May 3, 2018 at 12:33 AM, Matthieu Bouron
> wrote:
>
> > On Wed, May 02, 2018 at 07:24:58PM -0700, Aman Gupta wrote:
> > > From: Aman Gupta
> > >
> > > The new logic follows a recommendation by @rcombs to use
> > > dequeueInput
On Thu, May 3, 2018 at 12:33 AM, Matthieu Bouron
wrote:
> On Wed, May 02, 2018 at 07:24:58PM -0700, Aman Gupta wrote:
> > From: Aman Gupta
> >
> > The new logic follows a recommendation by @rcombs to use
> > dequeueInputBuffer with a timeout of 0 as a way to detect
> > whether the codec wants mo
On Wed, May 02, 2018 at 07:24:58PM -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> The new logic follows a recommendation by @rcombs to use
> dequeueInputBuffer with a timeout of 0 as a way to detect
> whether the codec wants more data. The dequeued buffer index is
> kept in MediaCodecDecContext
From: Aman Gupta
The new logic follows a recommendation by @rcombs to use
dequeueInputBuffer with a timeout of 0 as a way to detect
whether the codec wants more data. The dequeued buffer index is
kept in MediaCodecDecContext until it can be used next.
A similar technique is also used by the Goog
