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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
