[05:38] *** bingbu has quit IRC (Quit: Leaving)
[06:04] <tfiga> bbrezillon: hverkuil: What happened to the v4l2_ext_buffer work?
[06:33] <hverkuil> tfiga: on hold until I have a bit more bandwidth to seriously start looking at this. Which I expect to happen quite soon (i.e. this month).
[07:07] <tfiga> hverkuil: okay, looking forward
[07:07] <tfiga> I was wondering if there is some refresh needed
[07:10] <hverkuil> paulk-leonov: will you be at the ELCE?
[07:11] <paulk-leonov> hverkuil: yes, for sure
[07:11] <hverkuil> I assume you want to attend the media meetings as well?
[07:15] <hverkuil> paulk-leonov: I'll put you up on the attendee list anyway :-)
[07:15] <paulk-leonov> yes of course !
[07:15] <paulk-leonov> thanks :)
[07:41] <tfiga> bbrezillon: ezequielg: Have we decided on the expectations for V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX?
[08:01] <bbrezillon> tfiga: I guess you refer to Kwiboo's patch series
[08:06] <tfiga> bbrezillon: I couldn't find that actually
[08:06] <tfiga> but I remember there was some mention about the order of the matrix
[08:07] <bbrezillon> tfiga: it's being discussed right now
[08:07] <bbrezillon> tfiga: "media: hantro: H264 fixes and improvements"
[08:08] <tfiga> hmm, I guess I wasn't CCed there
[08:09] <tfiga> okay, found it on the list
[08:28] <Kwiboo> tfiga: sorry I missed to cc you :-), I also sent out a new mail ~30 minutes ago: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2094704.html, I am suggesting we use the same order for values as vaapi, and use the order of the lists according to the h264 spec (ffmpeg use different order for 8x8 lists)
[08:41] <tfiga> Kwiboo: no worries
[08:41] <tfiga> I think your proposal makes sense, but IMHO the most important thing is to actually agree on something :)
[12:41] *** rubdos has quit IRC (Ping timeout: 252 seconds)
[13:19] *** svarbanov has quit IRC (Remote host closed the connection)
[15:33] <dagmcr> Hi there, I'm trying to understand why it is needed to update this `node->enum_frame_interval_pad = pad;` in `v4l-utils`: `v4l2-compliance`. The function `testSubDevEnumFrameInterval` is executed two times: one for min and another for max. Then, for the max loop is getting the previous pad value. Is that okay?
[15:33] <dagmcr> Here the link:https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-test-subdevs.cpp?id=d11cca536b52960ebd7cce9c45dcc1538a6201b3#n58
[15:36] <dagmcr> I'm developing a driver for a kernel 4.14 (linaro/dragonboard) and I'm using latest `v4l-utils` which made me to modify a bit the kernel sources to match the tool. Still have some errors while executing the above function: `fail: ../../../../../../../../workspace/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-subdevs.cpp(59): node->enum_frame_interval_pad >= 0` which appears for the 2nd iteration.
[15:36] <dagmcr> any idea of what could it be?
[15:37] <dagmcr> thanks!
[15:48] <c0d1n61at3> hverkuil: hey Hans, Shuah suggested I create a macro for the ui commands 0x65, 0x66.  i noticed there is already the type_ui_cmd in cec_processing that could be used but perhaps something in cec.h is better.  is there a preference you would like?
[15:48] *** benjiG has left 
[15:49] <shuah> more like a define with some descriptive name that serves a self documenting
[16:02] <hverkuil> c0d1n61at3: it should really be added to include/uapi/linux/cec.h, right after #define CEC_MSG_USER_CONTROL_PRESSED.
[16:02] <hverkuil> I suspect I was too lazy to add all the UI_CMD ops.
[16:12] <c0d1n61at3> hverkuil: will do.  thanks.
[16:15] <hverkuil> c0d1n61at3: note that cec.h is used by the cec-ctl code generating script: so things will have to change a bit w.r.t. type_ui_cmd.
[16:25] <c0d1n61at3> hverkuil: okay--let me take a look.
[16:28] *** c0d1n61at3 has left 
[16:39] *** savoca has quit IRC (Quit: farewell)
[18:11] *** c0d1n61at3 has left 
[19:31] <Kwiboo> ezequielg: do you want me to rebase my hantro h264 improvements on top of your post-processor series, seems there will be some collisions? my initial thought is that field encoded streams may cause issues with post-processor, second the post-processor is limited to G1, any thought on how to also support the RK3399/RK3328 VPU2 post-processor ?
[19:53] <ezequielg> Kwiboo: at this point, I think we are still reviewing both series, not sure it makes sense to rebase anything. Thanks for checking.
[19:54] <ezequielg> I'm hoping we can merge your work before the post-proc.
[19:54] <ezequielg> I will think about how to deal with G1 and G2 later.
[20:08] <ezequielg> Kwiboo: your series is enhancing the uapi by adding more clarification, as well as fixing a few things, so it sounds we should try to get that sorted out first.
[20:09] <ezequielg> ...that said, feel free to test the post-processing as much as you want.
[20:22] *** tensa has quit IRC (Quit: Spline - https://spline.de)
[20:37] <Kwiboo> ezequielg: sounds reasonable, I will complete a v2 of my series before I start testing your post-proc work :-)