Groups > linux.kernel > #1381262 > unrolled thread

Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

Started by	tiffany lin <tiffany.lin@mediatek.com>
First post	2016-04-18 07:50 +0200
Last post	2016-04-19 08:50 +0200
Articles	5 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

  Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video  Decoder Driver tiffany lin <tiffany.lin@mediatek.com> - 2016-04-18 07:50 +0200
    Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video  Decoder Driver Hans Verkuil <hverkuil@xs4all.nl> - 2016-04-18 09:40 +0200
      Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video  Decoder Driver tiffany lin <tiffany.lin@mediatek.com> - 2016-04-18 10:30 +0200
        Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video  Decoder Driver Nicolas Dufresne <nicolas.dufresne@gmail.com> - 2016-04-18 19:50 +0200
          Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video  Decoder Driver tiffany lin <tiffany.lin@mediatek.com> - 2016-04-19 08:50 +0200

#1381262 — Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

From	tiffany lin <tiffany.lin@mediatek.com>
Date	2016-04-18 07:50 +0200
Subject	Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
Message-ID	<rpael-jl-1@gated-at.bofh.it>

snipped.

> > +
> > +void mtk_vcodec_dec_set_default_params(struct mtk_vcodec_ctx *ctx)
> > +{
> > +	struct mtk_q_data *q_data;
> > +
> > +	ctx->m2m_ctx->q_lock = &ctx->dev->dev_mutex;
> > +	ctx->fh.m2m_ctx = ctx->m2m_ctx;
> > +	ctx->fh.ctrl_handler = &ctx->ctrl_hdl;
> > +	INIT_WORK(&ctx->decode_work, mtk_vdec_worker);
> > +
> > +	q_data = &ctx->q_data[MTK_Q_DATA_SRC];
> > +	memset(q_data, 0, sizeof(struct mtk_q_data));
> > +	q_data->visible_width = DFT_CFG_WIDTH;
> > +	q_data->visible_height = DFT_CFG_HEIGHT;
> > +	q_data->fmt = &mtk_video_formats[OUT_FMT_IDX];
> > +	q_data->colorspace = V4L2_COLORSPACE_REC709;
> > +	q_data->field = V4L2_FIELD_NONE;
> > +	ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
> > +		DFT_CFG_WIDTH * DFT_CFG_HEIGHT;
> > +	ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = 0;
> > +
> > +
> > +	q_data = &ctx->q_data[MTK_Q_DATA_DST];
> > +	memset(q_data, 0, sizeof(struct mtk_q_data));
> > +	q_data->visible_width = DFT_CFG_WIDTH;
> > +	q_data->visible_height = DFT_CFG_HEIGHT;
> > +	q_data->coded_width = DFT_CFG_WIDTH;
> > +	q_data->coded_height = DFT_CFG_HEIGHT;
> > +	q_data->colorspace = V4L2_COLORSPACE_REC709;
> > +	q_data->field = V4L2_FIELD_NONE;
> > +
> > +	q_data->fmt = &mtk_video_formats[CAP_FMT_IDX];
> > +
> > +	v4l_bound_align_image(&q_data->coded_width,
> > +					MTK_VDEC_MIN_W,
> > +					MTK_VDEC_MAX_W, 4,
> > +					&q_data->coded_height,
> > +					MTK_VDEC_MIN_H,
> > +					MTK_VDEC_MAX_H, 5, 6);
> > +
> > +	q_data->sizeimage[0] = q_data->coded_width * q_data->coded_height;
> > +	q_data->bytesperline[0] = q_data->coded_width;
> > +	q_data->sizeimage[1] = q_data->sizeimage[0] / 2;
> > +	q_data->bytesperline[1] = q_data->coded_width;
> > +
> > +}
> > +
> > +static int vidioc_vdec_streamon(struct file *file, void *priv,
> > +				enum v4l2_buf_type type)
> > +{
> > +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> > +
> > +	mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
> > +
> > +	return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
> > +}
> > +
> > +static int vidioc_vdec_streamoff(struct file *file, void *priv,
> > +				 enum v4l2_buf_type type)
> > +{
> > +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> > +
> > +	mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
> > +	return v4l2_m2m_streamoff(file, ctx->m2m_ctx, type);
> > +}
> > +
> > +static int vidioc_vdec_reqbufs(struct file *file, void *priv,
> > +			       struct v4l2_requestbuffers *reqbufs)
> > +{
> > +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> > +	int ret;
> > +
> > +	mtk_v4l2_debug(3, "[%d] (%d) count=%d", ctx->idx,
> > +			 reqbufs->type, reqbufs->count);
> > +	ret = v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
> > +
> > +	return ret;
> > +}
> 
> Please use the v4l2_m2m_ioctl_* helper functions were applicable.
> 



snipped.
> > +static unsigned int fops_vcodec_poll(struct file *file,
> > +				     struct poll_table_struct *wait)
> > +{
> > +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
> > +	struct mtk_vcodec_dev *dev = ctx->dev;
> > +	int ret;
> > +
> > +	mutex_lock(&dev->dev_mutex);
> > +	ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait);
> > +	mutex_unlock(&dev->dev_mutex);
> > +
> > +	return ret;
> > +}
> > +
> > +static int fops_vcodec_mmap(struct file *file, struct vm_area_struct *vma)
> > +{
> > +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
> > +
> > +	return v4l2_m2m_mmap(file, ctx->m2m_ctx, vma);
> > +}
> > +
> > +static const struct v4l2_file_operations mtk_vcodec_fops = {
> > +	.owner				= THIS_MODULE,
> > +	.open				= fops_vcodec_open,
> > +	.release			= fops_vcodec_release,
> > +	.poll				= fops_vcodec_poll,
> > +	.unlocked_ioctl			= video_ioctl2,
> > +	.mmap				= fops_vcodec_mmap,
> 
> You should be able to use the v4l2_m2m_fop helper functions for poll and mmap.
> 

Hi Hans,

We are plaining to remove m2m framework in th feature, although we think
it is easy to use and could save a lot of code similar to what m2m
framework implemented and reduce code size.
The main reason is that in v4l2_m2m_try_schedule, it required that at
least one output buffer and one capture buffer to run device_run.
We want to start device_run without capture buffer queued.
Is there any suggestion that we could use m2m framework but trigger
device_run with only output buffer.
Or we need to remove m2m and write our own implementation.



snipped.


best regards,
Tiffany

[toc] | [next] | [standalone]

#1381336

From	Hans Verkuil <hverkuil@xs4all.nl>
Date	2016-04-18 09:40 +0200
Message-ID	<rpbWO-1C9-9@gated-at.bofh.it>
In reply to	#1381262

On 04/18/2016 07:40 AM, tiffany lin wrote:
> 
> snipped.
> 
>>> +
>>> +void mtk_vcodec_dec_set_default_params(struct mtk_vcodec_ctx *ctx)
>>> +{
>>> +	struct mtk_q_data *q_data;
>>> +
>>> +	ctx->m2m_ctx->q_lock = &ctx->dev->dev_mutex;
>>> +	ctx->fh.m2m_ctx = ctx->m2m_ctx;
>>> +	ctx->fh.ctrl_handler = &ctx->ctrl_hdl;
>>> +	INIT_WORK(&ctx->decode_work, mtk_vdec_worker);
>>> +
>>> +	q_data = &ctx->q_data[MTK_Q_DATA_SRC];
>>> +	memset(q_data, 0, sizeof(struct mtk_q_data));
>>> +	q_data->visible_width = DFT_CFG_WIDTH;
>>> +	q_data->visible_height = DFT_CFG_HEIGHT;
>>> +	q_data->fmt = &mtk_video_formats[OUT_FMT_IDX];
>>> +	q_data->colorspace = V4L2_COLORSPACE_REC709;
>>> +	q_data->field = V4L2_FIELD_NONE;
>>> +	ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
>>> +		DFT_CFG_WIDTH * DFT_CFG_HEIGHT;
>>> +	ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = 0;
>>> +
>>> +
>>> +	q_data = &ctx->q_data[MTK_Q_DATA_DST];
>>> +	memset(q_data, 0, sizeof(struct mtk_q_data));
>>> +	q_data->visible_width = DFT_CFG_WIDTH;
>>> +	q_data->visible_height = DFT_CFG_HEIGHT;
>>> +	q_data->coded_width = DFT_CFG_WIDTH;
>>> +	q_data->coded_height = DFT_CFG_HEIGHT;
>>> +	q_data->colorspace = V4L2_COLORSPACE_REC709;
>>> +	q_data->field = V4L2_FIELD_NONE;
>>> +
>>> +	q_data->fmt = &mtk_video_formats[CAP_FMT_IDX];
>>> +
>>> +	v4l_bound_align_image(&q_data->coded_width,
>>> +					MTK_VDEC_MIN_W,
>>> +					MTK_VDEC_MAX_W, 4,
>>> +					&q_data->coded_height,
>>> +					MTK_VDEC_MIN_H,
>>> +					MTK_VDEC_MAX_H, 5, 6);
>>> +
>>> +	q_data->sizeimage[0] = q_data->coded_width * q_data->coded_height;
>>> +	q_data->bytesperline[0] = q_data->coded_width;
>>> +	q_data->sizeimage[1] = q_data->sizeimage[0] / 2;
>>> +	q_data->bytesperline[1] = q_data->coded_width;
>>> +
>>> +}
>>> +
>>> +static int vidioc_vdec_streamon(struct file *file, void *priv,
>>> +				enum v4l2_buf_type type)
>>> +{
>>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +
>>> +	mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
>>> +
>>> +	return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
>>> +}
>>> +
>>> +static int vidioc_vdec_streamoff(struct file *file, void *priv,
>>> +				 enum v4l2_buf_type type)
>>> +{
>>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +
>>> +	mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
>>> +	return v4l2_m2m_streamoff(file, ctx->m2m_ctx, type);
>>> +}
>>> +
>>> +static int vidioc_vdec_reqbufs(struct file *file, void *priv,
>>> +			       struct v4l2_requestbuffers *reqbufs)
>>> +{
>>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +	int ret;
>>> +
>>> +	mtk_v4l2_debug(3, "[%d] (%d) count=%d", ctx->idx,
>>> +			 reqbufs->type, reqbufs->count);
>>> +	ret = v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
>>> +
>>> +	return ret;
>>> +}
>>
>> Please use the v4l2_m2m_ioctl_* helper functions were applicable.
>>
> 
> 
> 
> snipped.
>>> +static unsigned int fops_vcodec_poll(struct file *file,
>>> +				     struct poll_table_struct *wait)
>>> +{
>>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
>>> +	struct mtk_vcodec_dev *dev = ctx->dev;
>>> +	int ret;
>>> +
>>> +	mutex_lock(&dev->dev_mutex);
>>> +	ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait);
>>> +	mutex_unlock(&dev->dev_mutex);
>>> +
>>> +	return ret;
>>> +}
>>> +
>>> +static int fops_vcodec_mmap(struct file *file, struct vm_area_struct *vma)
>>> +{
>>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
>>> +
>>> +	return v4l2_m2m_mmap(file, ctx->m2m_ctx, vma);
>>> +}
>>> +
>>> +static const struct v4l2_file_operations mtk_vcodec_fops = {
>>> +	.owner				= THIS_MODULE,
>>> +	.open				= fops_vcodec_open,
>>> +	.release			= fops_vcodec_release,
>>> +	.poll				= fops_vcodec_poll,
>>> +	.unlocked_ioctl			= video_ioctl2,
>>> +	.mmap				= fops_vcodec_mmap,
>>
>> You should be able to use the v4l2_m2m_fop helper functions for poll and mmap.
>>
> 
> Hi Hans,
> 
> We are plaining to remove m2m framework in th feature, although we think

Remove it for just the decoder driver or both encoder and decoder?

> it is easy to use and could save a lot of code similar to what m2m
> framework implemented and reduce code size.
> The main reason is that in v4l2_m2m_try_schedule, it required that at
> least one output buffer and one capture buffer to run device_run.
> We want to start device_run without capture buffer queued.

I assume the reason is that you need to get the resolution etc. information
from the encoded stream? Without a capture buffer you can't actually decode
a frame, but that's probably not what this is about.

> Is there any suggestion that we could use m2m framework but trigger
> device_run with only output buffer.
> Or we need to remove m2m and write our own implementation.

I am assuming that not using the m2m framework is for the decoder only and
that its purpose is to obtain data about the encoded stream early.

This is something that was discussed with Pawel in the past. I don't have a
problem if you do it yourself (without the m2m framework), but it might also
be an idea to adapt the framework for this.

Pawel, do you have any thoughts on that?

Regards,

	Hans

[toc] | [prev] | [next] | [standalone]

#1381365

From	tiffany lin <tiffany.lin@mediatek.com>
Date	2016-04-18 10:30 +0200
Message-ID	<rpcJb-2fT-5@gated-at.bofh.it>
In reply to	#1381336

Hi Hans,

On Mon, 2016-04-18 at 09:32 +0200, Hans Verkuil wrote:
> On 04/18/2016 07:40 AM, tiffany lin wrote:
> > 
> > snipped.
> > 
> >>> +
> >>> +void mtk_vcodec_dec_set_default_params(struct mtk_vcodec_ctx *ctx)
> >>> +{
> >>> +	struct mtk_q_data *q_data;
> >>> +
> >>> +	ctx->m2m_ctx->q_lock = &ctx->dev->dev_mutex;
> >>> +	ctx->fh.m2m_ctx = ctx->m2m_ctx;
> >>> +	ctx->fh.ctrl_handler = &ctx->ctrl_hdl;
> >>> +	INIT_WORK(&ctx->decode_work, mtk_vdec_worker);
> >>> +
> >>> +	q_data = &ctx->q_data[MTK_Q_DATA_SRC];
> >>> +	memset(q_data, 0, sizeof(struct mtk_q_data));
> >>> +	q_data->visible_width = DFT_CFG_WIDTH;
> >>> +	q_data->visible_height = DFT_CFG_HEIGHT;
> >>> +	q_data->fmt = &mtk_video_formats[OUT_FMT_IDX];
> >>> +	q_data->colorspace = V4L2_COLORSPACE_REC709;
> >>> +	q_data->field = V4L2_FIELD_NONE;
> >>> +	ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
> >>> +		DFT_CFG_WIDTH * DFT_CFG_HEIGHT;
> >>> +	ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = 0;
> >>> +
> >>> +
> >>> +	q_data = &ctx->q_data[MTK_Q_DATA_DST];
> >>> +	memset(q_data, 0, sizeof(struct mtk_q_data));
> >>> +	q_data->visible_width = DFT_CFG_WIDTH;
> >>> +	q_data->visible_height = DFT_CFG_HEIGHT;
> >>> +	q_data->coded_width = DFT_CFG_WIDTH;
> >>> +	q_data->coded_height = DFT_CFG_HEIGHT;
> >>> +	q_data->colorspace = V4L2_COLORSPACE_REC709;
> >>> +	q_data->field = V4L2_FIELD_NONE;
> >>> +
> >>> +	q_data->fmt = &mtk_video_formats[CAP_FMT_IDX];
> >>> +
> >>> +	v4l_bound_align_image(&q_data->coded_width,
> >>> +					MTK_VDEC_MIN_W,
> >>> +					MTK_VDEC_MAX_W, 4,
> >>> +					&q_data->coded_height,
> >>> +					MTK_VDEC_MIN_H,
> >>> +					MTK_VDEC_MAX_H, 5, 6);
> >>> +
> >>> +	q_data->sizeimage[0] = q_data->coded_width * q_data->coded_height;
> >>> +	q_data->bytesperline[0] = q_data->coded_width;
> >>> +	q_data->sizeimage[1] = q_data->sizeimage[0] / 2;
> >>> +	q_data->bytesperline[1] = q_data->coded_width;
> >>> +
> >>> +}
> >>> +
> >>> +static int vidioc_vdec_streamon(struct file *file, void *priv,
> >>> +				enum v4l2_buf_type type)
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +
> >>> +	mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
> >>> +
> >>> +	return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
> >>> +}
> >>> +
> >>> +static int vidioc_vdec_streamoff(struct file *file, void *priv,
> >>> +				 enum v4l2_buf_type type)
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +
> >>> +	mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
> >>> +	return v4l2_m2m_streamoff(file, ctx->m2m_ctx, type);
> >>> +}
> >>> +
> >>> +static int vidioc_vdec_reqbufs(struct file *file, void *priv,
> >>> +			       struct v4l2_requestbuffers *reqbufs)
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +	int ret;
> >>> +
> >>> +	mtk_v4l2_debug(3, "[%d] (%d) count=%d", ctx->idx,
> >>> +			 reqbufs->type, reqbufs->count);
> >>> +	ret = v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
> >>> +
> >>> +	return ret;
> >>> +}
> >>
> >> Please use the v4l2_m2m_ioctl_* helper functions were applicable.
> >>
> > 
> > 
> > 
> > snipped.
> >>> +static unsigned int fops_vcodec_poll(struct file *file,
> >>> +				     struct poll_table_struct *wait)
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
> >>> +	struct mtk_vcodec_dev *dev = ctx->dev;
> >>> +	int ret;
> >>> +
> >>> +	mutex_lock(&dev->dev_mutex);
> >>> +	ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait);
> >>> +	mutex_unlock(&dev->dev_mutex);
> >>> +
> >>> +	return ret;
> >>> +}
> >>> +
> >>> +static int fops_vcodec_mmap(struct file *file, struct vm_area_struct *vma)
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
> >>> +
> >>> +	return v4l2_m2m_mmap(file, ctx->m2m_ctx, vma);
> >>> +}
> >>> +
> >>> +static const struct v4l2_file_operations mtk_vcodec_fops = {
> >>> +	.owner				= THIS_MODULE,
> >>> +	.open				= fops_vcodec_open,
> >>> +	.release			= fops_vcodec_release,
> >>> +	.poll				= fops_vcodec_poll,
> >>> +	.unlocked_ioctl			= video_ioctl2,
> >>> +	.mmap				= fops_vcodec_mmap,
> >>
> >> You should be able to use the v4l2_m2m_fop helper functions for poll and mmap.
> >>
> > 
> > Hi Hans,
> > 
> > We are plaining to remove m2m framework in th feature, although we think
> 
> Remove it for just the decoder driver or both encoder and decoder?
> 
Remove it from decoder driver.

> > it is easy to use and could save a lot of code similar to what m2m
> > framework implemented and reduce code size.
> > The main reason is that in v4l2_m2m_try_schedule, it required that at
> > least one output buffer and one capture buffer to run device_run.
> > We want to start device_run without capture buffer queued.
> 
> I assume the reason is that you need to get the resolution etc. information
> from the encoded stream? Without a capture buffer you can't actually decode
> a frame, but that's probably not what this is about.
Yes, it could start parsing without waiting CAPTURE ready and get
CAPTURE buffer from vb2 when it really need it.


> > Is there any suggestion that we could use m2m framework but trigger
> > device_run with only output buffer.
> > Or we need to remove m2m and write our own implementation.
> 
> I am assuming that not using the m2m framework is for the decoder only and
> that its purpose is to obtain data about the encoded stream early.
> 
yes. it's for decode only.


> This is something that was discussed with Pawel in the past. I don't have a
> problem if you do it yourself (without the m2m framework), but it might also
> be an idea to adapt the framework for this.
> 
> Pawel, do you have any thoughts on that?
> 
> Regards,
> 
> 	Hans

[toc] | [prev] | [next] | [standalone]

#1381943

From	Nicolas Dufresne <nicolas.dufresne@gmail.com>
Date	2016-04-18 19:50 +0200
Message-ID	<rplt7-13z-3@gated-at.bofh.it>
In reply to	#1381365

Le lundi 18 avril 2016 à 16:22 +0800, tiffany lin a écrit :
> > > We are plaining to remove m2m framework in th feature, although
> we think
> > 
> > Remove it for just the decoder driver or both encoder and decoder?
> > 
> Remove it from decoder driver.

Did you look at how CODA handle it (drivers/media/platform/coda/coda-
common.c) ? I don't know any detail, but they do have the same issue
and use both v4l2_m2m_fop_poll and v4l2_m2m_fop_mmap.

cheers,
Nicolas

[toc] | [prev] | [next] | [standalone]

#1382206

From	tiffany lin <tiffany.lin@mediatek.com>
Date	2016-04-19 08:50 +0200
Message-ID	<rpxDX-2sD-5@gated-at.bofh.it>
In reply to	#1381943

Hi Nicolas,

On Mon, 2016-04-18 at 13:48 -0400, Nicolas Dufresne wrote:
> Le lundi 18 avril 2016 à 16:22 +0800, tiffany lin a écrit :
> > > > We are plaining to remove m2m framework in th feature, although
> > we think
> > > 
> > > Remove it for just the decoder driver or both encoder and decoder?
> > > 
> > Remove it from decoder driver.
> 
> Did you look at how CODA handle it (drivers/media/platform/coda/coda-
> common.c) ? I don't know any detail, but they do have the same issue
> and use both v4l2_m2m_fop_poll and v4l2_m2m_fop_mmap.
> 
I check coda-common.c, it use v4l2_m2m_set_src_buffered to allow
device_run be triggered without OUTPUT buffer.

Double check the patch "[media] mem2mem: add support for hardware
buffered queue".
This patch make m2m framework could support that
1. out-of-order frames, causing a few mem2mem device runs in the
beginning, that don't produce any decompressed buffer at the v4l2
capture side.
2. the last few frames can be decoded from the bitstream with mem2mem
device runs that don't need a new input buffer at the v4l2 output side.

This is similar our requirement that we want start decode without
CAPTURE buffer.
Is there any restriction that when v4l2_m2m_set_src_buffered can be
used?

best regards,
Tiffany

> cheers,
> Nicolas

[toc] | [prev] | [standalone]

csiph-web

Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

Contents

#1381262 — Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

#1381336

#1381365

#1381943

#1382206