> -Original Message-
> From: Rogozhkin, Dmitry V
> Sent: Wednesday, July 25, 2018 1:36 AM
> To: libav-devel@libav.org
> Cc: Rogozhkin, Dmitry V ; Maxym
> Dmytrychenko ; Li, Zhong
> Subject: [PATCH] avcodec/qsv: fix async support
>
> Current implementations of qsv components incorrectly
On Wed, 2018-07-25 at 22:36 +0200, Maxym Dmytrychenko wrote:
> On Wed, Jul 25, 2018 at 10:24 PM Luca Barbato
> wrote:
>
> > On 25/07/2018 19:39, Rogozhkin, Dmitry V wrote:
> > > So, I encourage to embrace this change and understand that there
> > > are
> > > some changes in performance
On Wed, Jul 25, 2018 at 10:24 PM Luca Barbato wrote:
> On 25/07/2018 19:39, Rogozhkin, Dmitry V wrote:
> > So, I encourage to embrace this change and understand that there are
> > some changes in performance associated with it which aligns the
> > behavior with the expected usage models.
>
> I
On 25/07/2018 19:39, Rogozhkin, Dmitry V wrote:
> So, I encourage to embrace this change and understand that there are
> some changes in performance associated with it which aligns the
> behavior with the expected usage models.
I guess we could change the default so it is less surprising.
lu
On Wed, 2018-07-25 at 15:29 +0200, Maxym Dmytrychenko wrote:
thanks for the patch.
any performance impact you see, depth == 1 and higher ?
our tests shows some drop when async_depth == 1.
You indeed can notice some FPS drop on async=~1. This is due to the fact that
ffmpeg tried to work on
On Tue, 2018-07-24 at 09:53 -0700, Dmitry Rogozhkin wrote:
> On Wed, 2018-07-18 at 14:07 +0200, Maxym Dmytrychenko wrote:
> > Not used VPP sessions, like for hwupload/hwdownload handling,
> > can increase CPU utilization and this patch fixes it.
> > thank you,Joe, for the contribution.
> >
> >
On Wed, Jul 25, 2018 at 3:39 AM Dmitry Rogozhkin <
dmitry.v.rogozh...@intel.com> wrote:
> Current implementations of qsv components incorrectly work with async
> level, they
> actually try to work in async+1 level stepping into MFX_WRN_DEVICE_BUSY
> and polling
> loop. This change address this
