From e5c9a921addc3721b73b7dd4fb0a6d6b06049f75 Mon Sep 17 00:00:00 2001 From: Guillaume Desmottes Date: Sat, 25 May 2019 19:23:35 +0200 Subject: [PATCH] videometa: document how the meta can be used to negotiate buffers layout I'm going to use this new API in gst-omx so an encoder can request v4l2src to produce buffers matching the encoder stride and slice heights preventing copies of incoming buffers. --- gst-libs/gst/video/gstvideometa.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/gst-libs/gst/video/gstvideometa.h b/gst-libs/gst/video/gstvideometa.h index 3519a54..4abf173 100644 --- a/gst-libs/gst/video/gstvideometa.h +++ b/gst-libs/gst/video/gstvideometa.h @@ -59,6 +59,21 @@ typedef struct _GstVideoCropMeta GstVideoCropMeta; * to no padding and no alignment. Since: 1.18 * * Extra buffer metadata describing image properties + * + * This meta can also be used by downstream elements to specifiy their + * buffer layout requirements for upstream. Upstream should try to + * fit those requirements, if possible, in order to prevent buffer copies. + * + * This is done by passing a custom #GstStructure to + * gst_query_add_allocation_meta() when handling the ALLOCATION query. + * This structure should be named 'video-meta' and can have the following + * fields: + * - padding-top (uint): extra pixels on the top + * - padding-bottom (uint): extra pixels on the bottom + * - padding-left (uint): extra pixels on the left side + * - padding-right (uint): extra pixels on the right side + * The padding fields have the same semantic as #GstVideoMeta.alignment + * and so represent the paddings requested on produced video buffers. */ struct _GstVideoMeta { GstMeta meta; -- 2.7.4