[06:26] <montjoie> ezequielg: the zoran driver is too complicated for being started from scratch, lot of part I dont understand (videocodec)
[07:44] <matthias_arch> Hello guys, I get a full crash after a certain amount of time (20sec - 40min) of my gstreamer pipeline which is using the v4l2h264dec element. Error is related to the buffer allocator. The output produced until then is perfectly fine. The error is related to buffer allocator of v4l2.: Pipeline: https://bpaste.net/UWBQ  Explicit error message: https://bpaste.net/UVJA  Full debug log: https://termbin.com/k8jjw
[11:36] <ezequielg> matthias_arch: any specific bitstream?
[11:37] <matthias_arch> ezequielg: can you please be more specific? I'm having an rtsp input stream
[11:37] <ezequielg> ah, matthias_arch that's a raspberrypi?
[11:37] <matthias_arch> yes
[11:37] <ezequielg> hm, i don't think that driver is upstream, is it?
[11:37] <matthias_arch> yes it was included by default, didn't have to install anything
[11:38] <ezequielg> hm, right. but it's not in upstream (aka mainline) linux.
[11:38] <ezequielg> it's something raspberry folks provide you.
[11:38] <ezequielg> so we can't really debug it, fix it or anything.
[11:39] <matthias_arch> uff that sounds bad, unfortunately
[11:39] <ezequielg> for gstreamer questions you might ask https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
[11:41] <matthias_arch> ezequielg: I've already been in their IRC but they don't seem to be very interested
[11:43] <matthias_arch> I guess I'll try the mailing list
[11:46] <ezequielg> have you tried some raspberry specific forum?
[11:53] <matthias_arch> ezequielg: yes I did, I'm on this problem since friday. I also tried omx as an hardware decoder but it is not even starting up
[11:54] <matthias_arch> the pure v4l pipeline is producing perfect results but it is sadly not stable with regards to this buffer issue
[12:35] <pinchartl> hverkuil: ping for "[PATCH v7 3/6] media: v4l2: Extend VIDIOC_ENUM_FMT to support MC-centric devices" :-)
[12:39] <hverkuil> pinchartl: that patch is fine.
[12:45] <pinchartl> \o/
[12:45] <pinchartl> thanks
[12:46] <hverkuil> I like that change, it makes a lot of sense.
[12:52] <hverkuil> tfiga: whether or not capabilities are known in v4l2_requestbuffers is driver dependent. There are still non-vb2 drivers and those won't set capabilities, regardless of the kernel version.
[13:56] <pinchartl> hverkuil: would you be able to reply with a Reviewed-by ?
[17:02] <tfiga> hverkuil: oh, I thought everything in V4L2 was converted to vb2
[17:02] <tfiga> still, I wonder if it isn't confusing to userspace developers
[18:25] <montjoie> hello what means the error v4l2-compliance.cpp(671): dcaps & output_caps
[18:37] <hverkuil> montjoie: device_caps as reported by QUERTCAP has both input and output capabilities. That should not happen.
[18:53] <ndufresne> hverkuil: if we broken a downstream driver with the ORPHANING, is that considered an ABI break ? https://github.com/raspberrypi/linux/issues/3560
[18:55] <montjoie> hverkuil: thanks
[18:59] <hverkuil> ndufresne: No. Out-of-tree drivers are on their own. Not our responsibility, and also the reason why you should upstream drivers :-)
[19:01] <ndufresne> hverkuil: ok, make sense, it's also dead simple to fix, just need to clear that flag right ?
[19:02] <ndufresne> I don't think RPi have any bad intention there though, they wrote all this while changing the firmware interface, and until the firmware is stable they were worried of upstreaming
[19:13] <pinchartl> ndufresne: what would it take to fix the problem while keeping the buffer orphaning flag ?
[19:14] <hverkuil> ndufresne: I doubt it is related to orphaned buffers: vb2 sets that flag since it is vb2 that takes care of that, not the driver.
[19:14] <pinchartl> I thought it was mostly a feature that drivers got for free from vb2
[19:14] <hverkuil> huh, great minds think alike :-)
[19:15] <hverkuil> It looks like stop_streaming doesn't properly call vb2_buffer_done for outstanding buffers. That's causing the trace.
[19:26] <larsc> is there a good way to indicate that more data was recieved for a frame than what fits into the frame memory?
[19:30] *** awalls has left 
[19:40] <hverkuil> larsc: there is a patch (https://patchwork.linuxtv.org/patch/60244/) that adds support for that, but only in the context of stateful encoders. For video receivers (i.e. for raw video) this does not make sense.
[19:43] <ndufresne> pinchartl: that's a question for the firmware engineer at RPi
[19:43] <ndufresne> the firmware is designed around d'OMX, and OMX is designed to have this limitation
[19:46] <ndufresne> hverkuil: dmabuf in that case are proxied on the firmware side, so I guess they have some OMX design around how to keep both side in sync
[19:52] <larsc> hverkuil: thanks