[06:36] <hverkuil> mjourdan: ping
[11:11] <hverkuil> "sending too many recipients in a short time." @#%$@#$%!!!!
[11:11] <hverkuil> I'll wait an hour and try again.
[11:12] <jmondi> harrow: sorry Hans, no luck so far with ecovec
[11:19] <sailus> hverkuil: Where does that happen?
[11:20] <sailus> Lazy mail server? :-)
[11:20] <hverkuil> No, overly strict detection against spammers :-(
[11:22] <sailus> :\
[11:22] <jmondi> hverkuil: sorry, I pinged harrow instead of hverkuil... bad autocompletion...
[11:23] <jmondi> anyway, no luck with ecovec so far :(
[11:23] <hverkuil> jmondi: OK, then I won't work on that patch any further.
[11:24] <jmondi> hverkuil: I'll try again in next days, but those SH board are ancient and jumping on latest mainline is always a bit a pain
[11:28] <hverkuil> mjourdan: trying to send the patch series again, in batches of 5 patches with one minutes in between. Hopefully the whole series will now go through.
[11:29] <hverkuil> Yeah! It's complete.
[11:43] <mjourdan> hverkuil: thank you for that!
[11:46] <mjourdan> What prompted you to add V4L2_FMT_FLAG_HAS_BITSTREAM_PARSER ? I'm guessing it's to explicitely flag drivers where userspace can just fill the OUTPUT buffers full with bitstream ?
[12:05] <hverkuil> mjourdan: right.
[13:04] <svarbanov> hverkuil, what is your feeling about Venus stateful codec patchset v2, is it good enough to go in
[13:09] <hverkuil> svarbanov: I'll look at it later today.
[13:32] <hverkuil> svarbanov: the series should be fine.
[13:34] <hverkuil> svarbanov: Note that the "[PATCH 00/14] Stateful/stateless codec core support (resend)" series I posted today contains one change that might be relevant:
[13:35] <hverkuil> In the Decoding section change "multiple ``OUTPUT`` buffers generate one ``CAPTURE`` buffer: timestamp of the ``OUTPUT`` buffer queued last will be copied." to "queued first" since this corresponds to existing implementations.
[13:37] <hverkuil> I'm not even sure if this situation can happen with the venus driver, but if it does, then this will mean that the capture buffer should get the timestamp of the first output buffer that was used to fill the capture buffer, and not the last.
[13:56] <svarbanov> hverkuil, sure, thanks. I'll check does something needs rework
[13:57] <svarbanov> hverkuil, the thing which bothers me is the v4l2-compliance streaming test (the hack which I made to make it work)
[14:13] <hverkuil> svarbanov: what is missing in v4l2-compliance is a way to setup the initial output format for m2m devices. By default v4l2-compliance just takes whatever is the current format when it starts to do the streaming test.
[14:15] <hverkuil> So we need a new option that sets the pixelformat and width/height to be used as the output format.
[14:15] <hverkuil> That should do the trick when using v4l2-compliance with test streams.
[14:16] <svarbanov> hverkuil, yes, I guess that should be enough to calculate properly sizeimage for OUTPUT buffers
[14:17] <hverkuil> patch is welcome :-)
[15:13] <bernardoaraujo> I am calling an ioctl for VIDIOC_ENUMINPUT and the result is 0x10001, which I guess means V4L2_IN_ST_NO_POWER | V4L2_IN_ST_NO_SYNC... however I'm relatively new to v4l2 and I'm not sure how to interpret this information... can anyone help me understand what this means?
[15:15] <hverkuil> bernardoaraujo: https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-enuminput.html
[15:27] <bernardoaraujo> hey hverkuil... yes I have looked at this page... however I'm confused because the code V4L2_IN_ST_NO_POWER means "Attached device is off.", which makes no sense because the cameras are attached and I am able to get images from them... so I was wondering if maybe that means its "off" in some other sense
[15:35] *** benjiG has left 
[17:13] <hverkuil> bernardoaraujo: what driver are you using?
[17:19] <ezequielg> hverkuil: i've just submitted VP8 decoding for RK3399. Our next plan is to pick-up the H264 work. FWIW, and if possible, it would be good to sort this one before the H264.
[17:19] <ezequielg> And of course, VP9 is also in-progress :-)
[17:29] <hverkuil> ezequielg: will look at it tomorrow.
[17:34] <ezequielg> thanks!
[20:38] <jernej> ezequielg: is VP9 decoder on RK3399 similar to that on imx8 and h6?
[20:59] <ndufresne> jernej, I believe VP9 is sharing the same IP as HEVC, which on RK3399 is different