On 11/8/19 2:36 PM, Mirela Rabulea wrote: > Hi Hans, > > On Mi, 2019-11-06 at 17:52 +0100, Hans Verkuil wrote: >> test Scaling: OK >> The presence of a scaler is suspicious: is the encoder indeed >> capable of scaling? I suspect this is a bug. > > No, it's not capable of scaling. You suspect a bug in the driver or the > tests? Actually, I think that's an outstanding bug in v4l-utils. It doesn't correctly handle the m2m case with respect to scaling. I think. I'll look into this a bit more. > >> Codec ioctls: >>> test VIDIOC_(TRY_)ENCODER_CMD: OK >> The presence of this... >> >>> >>> test VIDIOC_G_ENC_INDEX: OK (Not Supported) >>> test VIDIOC_(TRY_)DECODER_CMD: OK >> ...and this is also strange for a JPEG codec. These ioctls are >> typically only >> needed for MPEG/H264/etc. codecs, and not for a simple JPEG codec. >> >> The same issues are found for the JPEG decoder. > > I implemented the CMD_STOP for both encoder & decoder, because it was > requested by our developer for gstreamer plugin for this codec. > The context in which this was requested was for playing MJPEG videos (a > concatenation of JPEG frames). This ioctl makes no sense for JPEG codecs, and in fact jpeg drivers like s5p-jpeg or mtk-jpeg do not implement this. This sounds like a gstreamer bug. Nicolas, do you know anything about this? > >> Streaming ioctls: >>> test read/write: OK (Not Supported) >>> test blocking wait: OK >>> fail: v4l2-test-buffers.cpp(254): g_field() == >>> V4L2_FIELD_ANY >> The driver shall never return FIELD_ANY. This needs to be FIELD_NONE. > > Is there a "good example" of a v4l m2m driver that passes these vim2m. Also drivers/media/platform/mtk-jpeg/ (although I'm not sure when it was last tested with v4l2-compliance, so it might be a bit out of date). > streaming tests? That would save some time on my side. > For the FIELD_ANY issue, I got inspired from your commit: > ab7afaf3 media: vim2m: add buf_out_validate callback > But there's a lot more to go... > > Thanks, > Mirela > Regards, Hans
