Re: [PATCH 00/30] Initial CODA960 (i.MX6 VPU) support

[Philipp Zabel <p.zabel@pengutronix.de>]

Hi Hans,

Am Montag, den 16.06.2014, 10:35 +0200 schrieb Hans Verkuil:
> Hi Philipp,
> 
> I went through this patch series and replied with some comments.

thank you for the comments. I have dropped the force IDR patch in
v2 and will send a separate RFC for the VFU / forced keyframe
support.
I have also dropped the enum_framesizes patch for now.

> I have two more general questions:
> 
> 1) can you post the output of 'v4l2-compliance'?

This is for the v2 series, the previously posted patches still had
one TRY_FMT(G_FMT) != G_FMT error introduced by the "[media] coda:
add bytesperline to queue data" patch:

$ v4l2-compliance -d /dev/video8
Driver Info:
	Driver name   : coda
	Card type     : CODA960
	Bus info      : platform:coda
	Driver version: 3.16.0
	Capabilities  : 0x84008003
		Video Capture
		Video Output
		Video Memory-to-Memory
		Streaming
		Device Capabilities
	Device Caps   : 0x04008003
		Video Capture
		Video Output
		Video Memory-to-Memory
		Streaming

Compliance test for device /dev/video8 (not using libv4l2):

Required ioctls:
		warn: v4l2-compliance.cpp(366): VIDIOC_QUERYCAP: m2m with video input and output caps
	test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
	test second video open: OK
		warn: v4l2-compliance.cpp(366): VIDIOC_QUERYCAP: m2m with video input and output caps
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

	Control ioctls:
		test VIDIOC_QUERYCTRL/MENU: OK
		test VIDIOC_G/S_CTRL: OK
		test VIDIOC_G/S/TRY_EXT_CTRLS: OK
		test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
		test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
		Standard Controls: 19 Private Controls: 0

	Format ioctls:
		test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
		test VIDIOC_G/S_PARM: OK (Not Supported)
		test VIDIOC_G_FBUF: OK (Not Supported)
		test VIDIOC_G_FMT: OK
		test VIDIOC_TRY_FMT: OK
		test VIDIOC_S_FMT: OK
		test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)

	Codec ioctls:
		test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
		test VIDIOC_G_ENC_INDEX: OK (Not Supported)
		test VIDIOC_(TRY_)DECODER_CMD: OK

Buffer ioctls:
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
	test VIDIOC_EXPBUF: OK

Total: 38, Succeeded: 38, Failed: 0, Warnings: 2

> 2) what would be needed for 'v4l2-compliance -s' to work?

I haven't looked at this in detail yet. v4l2-compliance -s curently fails:

Buffer ioctls:
		info: test buftype Video Capture
		info: test buftype Video Output
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
	test VIDIOC_EXPBUF: OK
	test read/write: OK (Not Supported)
		fail: v4l2-test-buffers.cpp(859): ret != EINVAL
	test MMAP: FAIL
		fail: v4l2-test-buffers.cpp(936): buf.qbuf(q)
		fail: v4l2-test-buffers.cpp(976): setupUserPtr(node, q)
	test USERPTR: FAIL
	test DMABUF: Cannot test, specify --expbuf-device

In principle the h.264 encoder should work, as you can just feed it
one frame at a time and then pick up the encoded result on the capture
side.

> For the encoder 'v4l2-compliance -s' will probably work OK, but for
> the decoder you need to feed v4l2-compliance -s some compressed
> stream. I assume each buffer should contain a single P/B/I frame?

Yes, for h.264 we currently expect all NAL units for a complete frame
in the source buffers.

> The v4l2-ctl utility has already support for writing captured data
> to a file, but it has no support to store the image sizes as well.
> So if the captured buffers do not all have the same size you cannot
> 'index' the captured file. If I would add support for that, then I
> can add support for it to v4l2-compliance as well, allowing you to
> playback an earlier captured compressed video stream and use that
> as the compliance test input.
> 
> Does this makes sense?

Wouldn't that mean that you had to add a stream parser for every
supported compressed format? Or are you planning to store an index
separately?

regards
Philipp