Re: [FFmpeg-devel] [PATCH 02/14] vaapi_encode: Convert to send/receive API

2019-08-07 Thread Aman Gupta
On Thu, Dec 20, 2018 at 12:46 PM Mark Thompson  wrote:

> This attaches the logic of picking the mode of for the next picture to
> the output, which simplifies some choices by removing the concept of
> the picture for which input is not yet available.  At the same time,
> we allow more complex reference structures and track more reference
> metadata (particularly the contents of the DPB) for use in the
> codec-specific code.
>
> It also adds flags to explicitly track the available features of the
> different codecs.  The new structure also allows open-GOP support, so
> that is now available for codecs which can do it.
> ---
> This change and related pieces (patches 1-6) have been hanging around for
> a while.  If there are no comments I'll commit it probably early next year.
>
>
>  libavcodec/vaapi_encode.c   | 635 +---
>  libavcodec/vaapi_encode.h   |  74 +++-
>  libavcodec/vaapi_encode_h264.c  |   7 +-
>  libavcodec/vaapi_encode_h265.c  |   7 +-
>  libavcodec/vaapi_encode_mjpeg.c |   9 +-
>  libavcodec/vaapi_encode_mpeg2.c |   5 +-
>  libavcodec/vaapi_encode_vp8.c   |   3 +-
>  libavcodec/vaapi_encode_vp9.c   |   5 +-
>  8 files changed, 419 insertions(+), 326 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index d8bedbe162..eec083da4f 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -158,16 +158,10 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>  av_log(avctx, AV_LOG_DEBUG, ".\n");
>  }
>
> -av_assert0(pic->input_available && !pic->encode_issued);
> +av_assert0(!pic->encode_issued);
>  for (i = 0; i < pic->nb_refs; i++) {
>  av_assert0(pic->refs[i]);
> -// If we are serialised then the references must have already
> -// completed.  If not, they must have been issued but need not
> -// have completed yet.
> -if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING)
> -av_assert0(pic->refs[i]->encode_complete);
> -else
> -av_assert0(pic->refs[i]->encode_issued);
> +av_assert0(pic->refs[i]->encode_issued);
>  }
>
>  av_log(avctx, AV_LOG_DEBUG, "Input surface is %#x.\n",
> pic->input_surface);
> @@ -466,10 +460,7 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>
>  pic->encode_issued = 1;
>
> -if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING)
> -return vaapi_encode_wait(avctx, pic);
> -else
> -return 0;
> +return 0;
>
>  fail_with_picture:
>  vaEndPicture(ctx->hwctx->display, ctx->va_context);
> @@ -626,315 +617,330 @@ static int vaapi_encode_free(AVCodecContext *avctx,
>  return 0;
>  }
>
> -static int vaapi_encode_step(AVCodecContext *avctx,
> - VAAPIEncodePicture *target)
> +static void vaapi_encode_add_ref(AVCodecContext *avctx,
> + VAAPIEncodePicture *pic,
> + VAAPIEncodePicture *target,
> + int is_ref, int in_dpb, int prev)
>  {
> -VAAPIEncodeContext *ctx = avctx->priv_data;
> -VAAPIEncodePicture *pic;
> -int i, err;
> +int refs = 0;
>
> -if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING ||
> -ctx->issue_mode == ISSUE_MODE_MINIMISE_LATENCY) {
> -// These two modes are equivalent, except that we wait for
> -// immediate completion on each operation if serialised.
> -
> -if (!target) {
> -// No target, nothing to do yet.
> -return 0;
> -}
> -
> -if (target->encode_complete) {
> -// Already done.
> -return 0;
> -}
> -
> -pic = target;
> -for (i = 0; i < pic->nb_refs; i++) {
> -if (!pic->refs[i]->encode_complete) {
> -err = vaapi_encode_step(avctx, pic->refs[i]);
> -if (err < 0)
> -return err;
> -}
> -}
> -
> -err = vaapi_encode_issue(avctx, pic);
> -if (err < 0)
> -return err;
> -
> -} else if (ctx->issue_mode == ISSUE_MODE_MAXIMISE_THROUGHPUT) {
> -int activity;
> -
> -// Run through the list of all available pictures repeatedly
> -// and issue the first one found which has all dependencies
> -// available (including previously-issued but not necessarily
> -// completed pictures).
> -do {
> -activity = 0;
> -for (pic = ctx->pic_start; pic; pic = pic->next) {
> -if (!pic->input_available || pic->encode_issued)
> -continue;
> -for (i = 0; i < pic->nb_refs; i++) {
> -if (!pic->refs[i]->encode_issued)
> -break;
> -}
> -if (i < pic->nb_refs)
> -continue;
> -err = vaapi_encode_issue(avctx, pic);
> -if (err < 

Re: [FFmpeg-devel] [PATCH 02/14] vaapi_encode: Convert to send/receive API

2019-01-23 Thread Mark Thompson
On 20/12/2018 20:39, Mark Thompson wrote:
> This attaches the logic of picking the mode of for the next picture to
> the output, which simplifies some choices by removing the concept of
> the picture for which input is not yet available.  At the same time,
> we allow more complex reference structures and track more reference
> metadata (particularly the contents of the DPB) for use in the
> codec-specific code.
> 
> It also adds flags to explicitly track the available features of the
> different codecs.  The new structure also allows open-GOP support, so
> that is now available for codecs which can do it.
> ---
> This change and related pieces (patches 1-6) have been hanging around for a 
> while.  If there are no comments I'll commit it probably early next year.

These applied (a bit late, oh well).

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 02/14] vaapi_encode: Convert to send/receive API

2018-12-20 Thread Mark Thompson
This attaches the logic of picking the mode of for the next picture to
the output, which simplifies some choices by removing the concept of
the picture for which input is not yet available.  At the same time,
we allow more complex reference structures and track more reference
metadata (particularly the contents of the DPB) for use in the
codec-specific code.

It also adds flags to explicitly track the available features of the
different codecs.  The new structure also allows open-GOP support, so
that is now available for codecs which can do it.
---
This change and related pieces (patches 1-6) have been hanging around for a 
while.  If there are no comments I'll commit it probably early next year.


 libavcodec/vaapi_encode.c   | 635 +---
 libavcodec/vaapi_encode.h   |  74 +++-
 libavcodec/vaapi_encode_h264.c  |   7 +-
 libavcodec/vaapi_encode_h265.c  |   7 +-
 libavcodec/vaapi_encode_mjpeg.c |   9 +-
 libavcodec/vaapi_encode_mpeg2.c |   5 +-
 libavcodec/vaapi_encode_vp8.c   |   3 +-
 libavcodec/vaapi_encode_vp9.c   |   5 +-
 8 files changed, 419 insertions(+), 326 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index d8bedbe162..eec083da4f 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -158,16 +158,10 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_DEBUG, ".\n");
 }
 
-av_assert0(pic->input_available && !pic->encode_issued);
+av_assert0(!pic->encode_issued);
 for (i = 0; i < pic->nb_refs; i++) {
 av_assert0(pic->refs[i]);
-// If we are serialised then the references must have already
-// completed.  If not, they must have been issued but need not
-// have completed yet.
-if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING)
-av_assert0(pic->refs[i]->encode_complete);
-else
-av_assert0(pic->refs[i]->encode_issued);
+av_assert0(pic->refs[i]->encode_issued);
 }
 
 av_log(avctx, AV_LOG_DEBUG, "Input surface is %#x.\n", pic->input_surface);
@@ -466,10 +460,7 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 
 pic->encode_issued = 1;
 
-if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING)
-return vaapi_encode_wait(avctx, pic);
-else
-return 0;
+return 0;
 
 fail_with_picture:
 vaEndPicture(ctx->hwctx->display, ctx->va_context);
@@ -626,315 +617,330 @@ static int vaapi_encode_free(AVCodecContext *avctx,
 return 0;
 }
 
-static int vaapi_encode_step(AVCodecContext *avctx,
- VAAPIEncodePicture *target)
+static void vaapi_encode_add_ref(AVCodecContext *avctx,
+ VAAPIEncodePicture *pic,
+ VAAPIEncodePicture *target,
+ int is_ref, int in_dpb, int prev)
 {
-VAAPIEncodeContext *ctx = avctx->priv_data;
-VAAPIEncodePicture *pic;
-int i, err;
+int refs = 0;
 
-if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING ||
-ctx->issue_mode == ISSUE_MODE_MINIMISE_LATENCY) {
-// These two modes are equivalent, except that we wait for
-// immediate completion on each operation if serialised.
-
-if (!target) {
-// No target, nothing to do yet.
-return 0;
-}
-
-if (target->encode_complete) {
-// Already done.
-return 0;
-}
-
-pic = target;
-for (i = 0; i < pic->nb_refs; i++) {
-if (!pic->refs[i]->encode_complete) {
-err = vaapi_encode_step(avctx, pic->refs[i]);
-if (err < 0)
-return err;
-}
-}
-
-err = vaapi_encode_issue(avctx, pic);
-if (err < 0)
-return err;
-
-} else if (ctx->issue_mode == ISSUE_MODE_MAXIMISE_THROUGHPUT) {
-int activity;
-
-// Run through the list of all available pictures repeatedly
-// and issue the first one found which has all dependencies
-// available (including previously-issued but not necessarily
-// completed pictures).
-do {
-activity = 0;
-for (pic = ctx->pic_start; pic; pic = pic->next) {
-if (!pic->input_available || pic->encode_issued)
-continue;
-for (i = 0; i < pic->nb_refs; i++) {
-if (!pic->refs[i]->encode_issued)
-break;
-}
-if (i < pic->nb_refs)
-continue;
-err = vaapi_encode_issue(avctx, pic);
-if (err < 0)
-return err;
-activity = 1;
-// Start again from the beginning of the list,
-// because issuing this picture may have satisfied
-// forward dependencies of earlier ones.
-break;
-