| Message ID | 20230317030833.16836-1-yunfei.dong@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v4,1/2] media: mediatek: vcodec: Force capture queue format to MM21 | expand |
On Fri, Mar 17, 2023 at 11:08:32AM +0800, Yunfei Dong wrote: > While the decoder can produce frames in both MM21 and MT21C formats, only MM21 > is currently supported by userspace tools (like gstreamer and libyuv). In order > to ensure userspace keeps working after the SCP firmware is updated to support > both MM21 and MT21C formats, force the MM21 format for the capture queue. > > This is meant as a stopgap solution while dynamic format switching between > MM21 and MT21C isn't implemented in the driver. > > Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format") > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> With this patch and the new firmware [1], I was able to run fluster using the VP8, VP9 and H.264 codecs on both MT8192 and MT8195: MT8192: VP8: 59/61 VP9: 250/303 0/6 (HIGH) H.264: 92/135 27/69 (JVT-FR-EXT) MT8195: VP8: 59/61 VP9: 276/303 0/6 (HIGH) H.264: 95/135 27/69 (JVT-FR-EXT) [1] https://lore.kernel.org/linux-firmware/a43524a089a783f70adbe89b83eeb01fbd405d04.camel@mediatek.com/T/#mb0591267d7921bbfada7c06ee2bda128db554648 Thanks, Nícolas
diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c index 641f533c417f..c99705681a03 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c @@ -39,10 +39,9 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) { const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata; const struct mtk_video_fmt *fmt; - struct mtk_q_data *q_data; int num_frame_count = 0, i; - bool ret = true; + fmt = &dec_pdata->vdec_formats[format_index]; for (i = 0; i < *dec_pdata->num_formats; i++) { if (dec_pdata->vdec_formats[i].type != MTK_FMT_FRAME) continue; @@ -50,27 +49,10 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) num_frame_count++; } - if (num_frame_count == 1) + if (num_frame_count == 1 || fmt->fourcc == V4L2_PIX_FMT_MM21) return true; - fmt = &dec_pdata->vdec_formats[format_index]; - q_data = &ctx->q_data[MTK_Q_DATA_SRC]; - switch (q_data->fmt->fourcc) { - case V4L2_PIX_FMT_VP8_FRAME: - if (fmt->fourcc == V4L2_PIX_FMT_MM21) - ret = true; - break; - case V4L2_PIX_FMT_H264_SLICE: - case V4L2_PIX_FMT_VP9_FRAME: - if (fmt->fourcc == V4L2_PIX_FMT_MM21) - ret = false; - break; - default: - ret = true; - break; - } - - return ret; + return false; } static struct mtk_q_data *mtk_vdec_get_q_data(struct mtk_vcodec_ctx *ctx,
While the decoder can produce frames in both MM21 and MT21C formats, only MM21 is currently supported by userspace tools (like gstreamer and libyuv). In order to ensure userspace keeps working after the SCP firmware is updated to support both MM21 and MT21C formats, force the MM21 format for the capture queue. This is meant as a stopgap solution while dynamic format switching between MM21 and MT21C isn't implemented in the driver. Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> --- changed with v3: - re-write commit message. - add one new patch to fix v4l2-compliance fail. changed with v2: - re-write commit message. - change the driver flow. changed with v1: - add Fixes tag. --- .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 24 +++---------------- 1 file changed, 3 insertions(+), 21 deletions(-)