docs: Replace gst-omx with v4l2 in memory allocation example

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4976>
This commit is contained in:
Olivier Crête 2023-07-05 18:53:37 -06:00 committed by GStreamer Marge Bot
parent 48c43e5b7f
commit e8731f26de

View file

@ -650,13 +650,13 @@ to the consumer (dmabuf export) or import them from it (dmabuf import).
In this section we'll outline the steps for how the consumer can inform the
producer of its expected buffer layout for import and export use cases.
Let's consider `v4l2src` (the producer) feeding buffers to
`omxvideoenc` (the consumer) for encoding.
`v4l2h264enc` (the consumer) for encoding.
#### v4l2src importing buffers from omxvideoenc
#### v4l2src importing buffers from v4l2h264enc
1. *omxvideoenc*: query the hardware for its requirements and create a
1. *v4l2h264enc*: query the hardware for its requirements and create a
`GstVideoAlignment` accordingly.
2. *omxvideoenc*: in its buffer pool `alloc_buffer` implementation, call
2. *v4l2h264enc*: in its buffer pool `alloc_buffer` implementation, call
`gst_buffer_add_video_meta_full()` and then
`gst_video_meta_set_alignment()` on the returned meta with the
requested alignment. The alignment will be added to the meta, allowing
@ -668,11 +668,9 @@ Let's consider `v4l2src` (the producer) feeding buffers to
GST_VIDEO_INFO_HEIGHT (&pool->video_info),
GST_VIDEO_INFO_N_PLANES (&pool->video_info), offset, stride);
if (gst_omx_video_get_port_padding (pool->port, &pool->video_info,
&align))
gst_video_meta_set_alignment (meta, align);
gst_video_meta_set_alignment (meta, align);
```
3. *omxvideoenc*: propose its pool to the producer when replying to the
3. *v4l2h264enc*: propose its pool to the producer when replying to the
`ALLOCATION` query (`propose_allocation()`).
4. *v4l2src*: when receiving the reply from the `ALLOCATION` query
(`decide_allocation()`) acquire
@ -680,15 +678,15 @@ Let's consider `v4l2src` (the producer) feeding buffers to
using `GstVideoMeta.stride` and `gst_video_meta_get_plane_height()`.
5. *v4l2src*: configure its driver to produce data matching those requirements,
if possible, then try to import the buffer.
If not, `v4l2src` won't be able to import from `omxvideoenc` and so will
fallback to sending its own buffers to `omxvideoenc` which will
If not, `v4l2src` won't be able to import from `v4l2h264enc` and so will
fallback to sending its own buffers to `v4l2h264enc` which will
have to copy each input buffer to fit its requirements.
#### v4l2src exporting buffers to omxvideoenc
#### v4l2src exporting buffers to v4l2h264enc
1. *omxvideoenc*: query the hardware for its requirements and create a
1. *v4l2h264enc*: query the hardware for its requirements and create a
`GstVideoAlignment` accordingly.
2. *omxvideoenc*: create a `GstStructure` named `video-meta` serializing the alignment:
2. *v4l2h264enc*: create a `GstStructure` named `video-meta` serializing the alignment:
``` c
params = gst_structure_new ("video-meta",
"padding-top", G_TYPE_UINT, align.padding_top,
@ -697,7 +695,7 @@ params = gst_structure_new ("video-meta",
"padding-right", G_TYPE_UINT, align.padding_right,
NULL);
```
3. *omxvideoenc*: when handling the `ALLOCATION` query (`propose_allocation()`),
3. *v4l2h264enc*: when handling the `ALLOCATION` query (`propose_allocation()`),
pass this structure as parameter when adding the `GST_VIDEO_META_API_TYPE`
meta:
``` c
@ -735,5 +733,5 @@ if (gst_query_find_allocation_meta (query, GST_VIDEO_META_API_TYPE, &video_idx))
`GstVideoInfo.stride` and `GST_VIDEO_INFO_PLANE_HEIGHT()`.
6. *v4l2src*: configure its driver to produce data matching those requirements,
if possible.
If not, driver will produce buffers using its own layout but `omxvideoenc` will
If not, driver will produce buffers using its own layout but `v4l2h264enc` will
have to copy each input buffer to fit its requirements.