All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Mauro Carvalho Chehab <m.chehab@samsung.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Sakari Ailus <sakari.ailus@iki.fi>,
	linux-media@vger.kernel.org, Tomasz Figa <tfiga@chromium.org>
Cc: Hirokazu Honda <hiroh@chromium.org>,
	Nicolas Dufresne <nicolas@ndufresne.ca>,
	Brian Starkey <Brian.Starkey@arm.com>,
	kernel@collabora.com
Subject: Re: [RFC PATCH v2 3/7] media: v4l2: Add extended buffer operations
Date: Fri, 12 Apr 2019 10:57:55 +0200	[thread overview]
Message-ID: <20190412105755.42764170@collabora.com> (raw)
In-Reply-To: <20190404081700.30006-4-boris.brezillon@collabora.com>

On Thu,  4 Apr 2019 10:16:56 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:


> +/**
> + * struct v4l2_ext_buffer - extended video buffer info
> + * @index: id number of the buffer
> + * @type: enum v4l2_buf_type; buffer type. _MPLANE and _OVERLAY formats are
> + *	  invalid
> + * @flags: buffer informational flags
> + * @field: enum v4l2_field; field order of the image in the buffer
> + * @timestamp: frame timestamp
> + * @sequence: sequence count of this frame
> + * @memory: enum v4l2_memory; the method, in which the actual video data is
> + *          passed
> + * @planes: per-plane buffer information
> + * @num_planes: number of plane buffers
> + * @request_fd: fd of the request that this buffer should use
> + * @reserved: some extra space reserved to add future fields (like timecode).
> + *	      Must be set to 0
> + *
> + * Contains data exchanged by application and driver using one of the Streaming
> + * I/O methods.
> + */
> +struct v4l2_ext_buffer {
> +	__u32 index;
> +	__u32 type;
> +	__u32 flags;
> +	__u32 field;
> +	__u64 timestamp;
> +	__u32 sequence;
> +	__u32 memory;
> +	struct v4l2_ext_plane planes[VIDEO_MAX_PLANES];

I had a discussion with Tomasz last week, and he made me realize I was
misunderstanding the concept of V4L2 planes. I thought it was encoding
pixel-component planes, but it's actually memory planes, and sometimes
those one memory planes might contain all component planes placed next
to each others (like the V4L2_PIX_FMT_NV12 format).

So, the question is, what do we want v4l2_ext_plane to encode (memory
planes or pixel component planes)?
If we go for the pixel component plane approach (which IMHO would be a
good thing), that means we'll have to convert V4L2_PIX_FMT_NV12-like
single-memory-plane buffers into v4l2_ext_buffer containing X planes,
each pointing to the same memory object but at a different offset.

> +	__u32 num_planes;
> +	__u32 request_fd;
> +	__u32 reserved[10];
> +};
> +
>  /**
>   * v4l2_timeval_to_ns - Convert timeval to nanoseconds
>   * @ts:		pointer to the timeval variable to be converted
> @@ -1062,6 +1139,35 @@ struct v4l2_exportbuffer {
>  	__u32		reserved[11];
>  };
>  


  reply	other threads:[~2019-04-12  8:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04  8:16 [RFC PATCH v2 0/7] media: v4l2: Add extended fmt and buffer ioctls Boris Brezillon
2019-04-04  8:16 ` [RFC PATCH v2 1/7] media: v4l2: Get rid of ->vidioc_enum_fmt_vid_{cap,out}_mplane Boris Brezillon
2019-04-11  7:59   ` Hans Verkuil
2019-04-11 10:36     ` Boris Brezillon
2019-04-11 10:38       ` Hans Verkuil
2019-04-12  8:25         ` Boris Brezillon
2019-04-12  8:33           ` Boris Brezillon
2019-04-12  9:36           ` Hans Verkuil
2019-04-04  8:16 ` [RFC PATCH v2 2/7] media: v4l2: Extend pixel formats to unify single/multi-planar handling (and more) Boris Brezillon
2019-04-11  8:24   ` Hans Verkuil
2019-04-11  8:37     ` Boris Brezillon
2019-04-04  8:16 ` [RFC PATCH v2 3/7] media: v4l2: Add extended buffer operations Boris Brezillon
2019-04-12  8:57   ` Boris Brezillon [this message]
2019-05-08 13:58     ` Hans Verkuil
2019-05-16  8:23       ` Tomasz Figa
2019-04-04  8:16 ` [RFC PATCH v2 4/7] media: videobuf2: Expose helpers to implement the _ext_fmt and _ext_buf hooks Boris Brezillon
2019-04-04  8:16 ` [RFC PATCH v2 5/7] media: mediabus: Add an helper to convert a ext_pix format to an mbus_fmt Boris Brezillon
2019-04-04  8:16 ` [RFC PATCH v2 6/7] media: vivid: Convert the capture and output drivers to EXT_FMT/EXT_BUF Boris Brezillon
2019-04-04  8:17 ` [RFC PATCH v2 7/7] media: vimc: Implement the ext_fmt and ext_buf hooks Boris Brezillon
2019-09-23 11:41 ` [RFC PATCH v2 0/7] media: v4l2: Add extended fmt and buffer ioctls Hans Verkuil
2019-09-23 14:40   ` Boris Brezillon
2019-09-23 15:07     ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190412105755.42764170@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=Brian.Starkey@arm.com \
    --cc=hans.verkuil@cisco.com \
    --cc=hiroh@chromium.org \
    --cc=kernel@collabora.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=nicolas@ndufresne.ca \
    --cc=sakari.ailus@iki.fi \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.