[00:06] *** koike has quit IRC (*.net *.split)
[12:10] <ezequielg> hverkuil_: any input in pwc's patch?
[13:17] <ezequielg> hm, v4l2_m2m_prepare_buf does not check for busy queue. Is that a bug?
[13:29] <hverkuil_> ezequielg: no. The vb2_queue_is_busy() function in videobuf2-v4l2.c is perhaps confusing (never really realized it): here is means: is someone else owner of the video device.
[13:29] <hverkuil_> Since for m2m each open gives you a new context, this cannot happen.
[13:52] <ezequielg> oh! yes, i confused that with vb2_is_busy.
[13:53] <ezequielg> very confusing, because vb2_is_busy takes a queue.
[14:23] <hverkuil_> perhaps vb2_queue_is_busy should be renamed to vb2_queue_is_taken()?
[14:25] <ezequielg> dunno, maybe yes, but maybe it's just bikeshedding.
[14:34] <tfiga> perhaps vb2_queue_has_different_owner()? ;)
[14:36] <tfiga> or one could invert the return value and call it vb2_queue_is_owned_by()
[14:36] <tfiga> but I guess it's just bikeshedding :)
[16:05] <zeenix_> hverkuil_, ndufresne: hi. I might have found a bug: the buffer.sequence in case of ALTERNATE interlacing, skips after every 3 fields: 0, 0, 1, 1, 2, 3, 3, 4, 5, 5, 6, 6, 7, 8, 8, 9
[16:06] <ndufresne> zeenix_, on vivid, or xlnx ?
[16:06] <zeenix_> vivid
[16:07] <ndufresne> hmm, so skipping or dropping ...
[16:07] <zeenix> msg NickServ identify
[16:07] <zeenix> errr.. sorry
[16:08] <zeenix> ndufresne, right, it could be dropping fields or it could just be getting the sequence wrong
[16:08] * zeenix checks..
[16:11] <zeenix> yup, it's droping the buffers actually
[16:11] <zeenix> maybe i asked for too hight a resolution :)
[16:11] <zeenix> 1920x1080
[16:13] <zeenix> same with 1024x768
[16:14] <zeenix> lowering fps to 15 doesn't help either
[16:14] <zeenix> also it skips an entire frame sometimes
[16:16] <ndufresne> zeenix, well, use that to test the frame detection code, but we'll need to figure-out why it's dropping, I didn't know it was possible in vivid
[16:17] <ndufresne> zeenix, we might need to double the number of allocated buffer all over the place, as right now, most of it is probably in frames
[16:17] <ndufresne> if you jus do v4l2src ! fakevideosink, does it stops dropping ?
[16:28] <ezequielg> hverkuil_: ping
[16:30] <zeenix> ndufresne, why would it matter what's connected to v4l2src?
[16:30] <zeenix> ah, nm
[16:30] <zeenix> i'll check..
[16:32] <zeenix> you're right! it makes a big diff
[16:32] <zeenix> consumer not consuming fast enough?
[16:36] <ezequielg> zeenix: exactly, that is why you sometimes need a queue leaky=1 filter
[16:37] <ezequielg> or that i've been told
[16:56] <ndufresne> ezequielg, leaky queue is a messy hack, but may work
[16:57] <ndufresne> but on our side, we've implement QoS on encoder input
[16:57] <ndufresne> zeenix, but in this case, it's probably starvation, and I'm pretty sure all the number of buffers we get from the VCU haven't been multiplied by two like they should
[16:58] <ndufresne> so the VCU keeps the source buffers too long, and vivid runs-out
[18:24] <zeenix> ndufresne, right