[07:20] <hverkuil> pinchartl: https://hverkuil.home.xs4all.nl/spec/uapi/v4l/pixfmt-meta-vsp1-hgo.html
[07:21] <hverkuil> It describes four different metadata formats, but they all use the same fourcc. I assume the specific format is selected by a control? If so, which control and shouldn't this documentation refer to that control?
[07:21] <hverkuil> I'm considering using 'VSP1 HGO Data - 64 Bins, Normal Mode (792 bytes)' as the metadata format for vivid.
[07:41] <bbrezillon> Kwiboo: Hi
[07:42] <bbrezillon> did you start working on a v4l2_request-based extension for VP8 in ffmpeg?
[08:10] <Kwiboo> bbrezillon: hello, no I did not look into VP8 yet, do you have the vp8 decoder working in any branch? :-)
[08:12] <Kwiboo> and how is the h264 work progressing? anything ready for testing? (I would like to try and generate some swreg code for rk3328/3399 vpu2 if you have something working for rk3288 vpu1)
[08:19] <bbrezillon> Kwiboo: yes, I have h264 dec working on rk3288, though I haven't tested all possible combinations
[08:20] <bbrezillon> Kwiboo: https://github.com/bbrezillon/FFmpeg/tree/rk-vpu-h264 and https://github.com/bbrezillon/FFmpeg/tree/rk-vpu-h264/
[08:23] <bbrezillon> Kwiboo: and I'm just starting to work on VP8, so I don't have anything to share yet
[08:34] <Kwiboo> bbrezillon: great and thanks, I am planing on doing some cedrus h264 + copied_timestamp debugging tonight, will do some h264 testing on rk also :-)
[08:40] <bbrezillon> Kwiboo: adding the start code and aligning output bufs the way I do it in ffmpeg is still wrong (it's rk specific)
[08:40] <bbrezillon> we found a bit that allows us to get rid of the start code
[08:40] <bbrezillon> and the size alignment should be taken care of by the driver
[09:11] <pinchartl> hverkuil: V4L2_CID_VSP1_HGO_MAX_RGB and V4L2_CID_VSP1_HGO_MAX_RGB
[09:11] <pinchartl> they're defined in drivers/media/platform/vsp1/vsp1_hgo.c
[09:24] <hverkuil> pinchartl: can you make a patch for the documentation of that format that refers to those controls? It might be a good idea actually to create a driver document in Documentation/media/v4l-drivers for vsp1 that documents the controls as well.
[09:27] <pinchartl> I'll try to do so, you may need to remind me :-)
[09:30] <paulk-leonov> hverkuil, do you want a rebased h264 version btw?
[09:30] <paulk-leonov> looks like your cedrus h264 branch doesn't rebase well on latest for-v5.3a
[09:36] <hverkuil> paulk-leonov: in that case a rebase will be useful. But I'd wait until 5.2-rc1 is released and merged into our master.
[09:37] <Kwiboo> bbrezillon: so the start_code_e=0 allows you to skip start code? (at least seems to be indicated by the hantro g1 ref code), having the start code in buffer may also work for cedrus as it seems to be using a start position offset, I will take a closer look at your ffmpeg changes later
[09:38] <paulk-leonov> hverkuil, understood
[09:40] <bbrezillon> Kwiboo: yep, start_code_e=0 and remove the code that manually the start bytes in ffmpeg and you should see it work
[09:40] <bbrezillon> at least it did work on the few tests I did
[09:41] <bbrezillon> I reverted it back because I was comparing regs with MPP, and MPP always keeps the start code
[09:43] <Kwiboo> cool, will test later, thanks for confirmation
[11:50] *** prabhakarlad has left 
[20:14] <ndufresne> paulk-leonov, I've hit an issue with VA on the rockchip driver, after a discussion with hverkuil, bbrezillon added code that basically prevent setting the capture format before the OUTPUT (encoded) format is set
[20:14] <paulk-leonov> ah yes, that's quite legit
[20:15] <paulk-leonov> ndufresne, I think bbrezillon's working with ffmpeg
[20:15] <ndufresne> paulk-leonov, the problem is that in VA you create a config (which is just the coded format), then create bunch of surfaces, and finally you connect all these together itno a contexdt
[20:15] <paulk-leonov> our libva basically doesn't follow the spec
[20:15] <paulk-leonov> ndufresne, the libva is one of the first things I did when I got started and I basically knew nothing about how decoding works
[20:16] <paulk-leonov> so there are major design issues
[20:16] <ndufresne> I'm fine with that, and I have the intention to fix it
[20:16] <paulk-leonov> ndufresne, I guess that's the path of least resistance for bringing v4l2 m2m-request support to gstreamer?
[20:17] <paulk-leonov> ndufresne, if so, which I understand, we should rewrite it from scratch
[20:17] <paulk-leonov> the current one was not really meant for serious usage
[20:17] <ndufresne> it's the shortest solution yet, the v4l2 stack needs serious rework to support this, and the code I need is only found in gstreamer-vaapi, and that part I'm not going to rewrite
[20:17] <paulk-leonov> more like a development companion
[20:17] <paulk-leonov> ndufresne, understood
[20:18] <ndufresne> so I'll start changing the design a bit
[20:18] <paulk-leonov> ndufresne, you're most welcome to :)
[20:18] <ndufresne> so instead of having the FD (the instance) in the driver_data, each Context will have it's own FD instance
[20:18] <paulk-leonov> ndufresne, also I'd like to rename it libva-v4l2-m2m-request
[20:18] <paulk-leonov> for better clarity
[20:18] <paulk-leonov> ndufresne, yes, makes better sense of course
[20:18] <paulk-leonov> go for it :)
[20:19] <paulk-leonov> and thanks in advance
[20:19] <ndufresne> now our drivers are all single instance, so the FD used to do format enumeration in driver_data cannot be kept I suppose is that right ?
[20:20] <ndufresne> (it's in our todo, but we are far from that)
[20:21] <ndufresne> paulk-leonov, anyway, so when the HWContext is created, I'll enumerate once the formats I need, and will just lookup these later (instead of calling into the driver over and over)
[20:21] <ndufresne> and will then close the FS
[20:21] <ndufresne> FD
[20:21] <ndufresne> for the Surfaces, I will simply just create the objects, and allocate in CreateContext
[20:22] <ndufresne> and I think that should do, it will reduce the number of ioctl, making it easier to follow when debugging
[20:23] <paulk-leonov> ahh right we have v4l2_find_format
[20:23] <paulk-leonov> I was looking where we have to do enumeration
[20:24] <paulk-leonov> maybe what we should do is keep the devnode path
[20:24] <paulk-leonov> in the driver
[20:24] <paulk-leonov> and yes, enumerating formats once makes total sense
[20:24] <paulk-leonov> so maybe grab devnode at driver init and enumerate then while checking caps
[20:25] <paulk-leonov> and just returned cached formats in RequestQueryConfigProfiles
[20:25] <paulk-leonov> and open for real in RequestCreateContext
[20:25] <paulk-leonov> should do
[20:25] <ndufresne> that's my idea yes, I'll baby step toward that, and just cache the enumerations I need for now
[20:25] <paulk-leonov> we could just as well have bools for each codec
[20:26] <ndufresne> btw, is it me of the cedrus driver does not expose it's H264 profiles ?
[20:26] <ndufresne> (and levels)
[20:26] <paulk-leonov> ndufresne, no, we don't do that yet
[20:26] <ndufresne> ok, noted
[20:26] <paulk-leonov> driver was merged before this was decided IIRC and we didn't update it
[20:26] <ndufresne> right, now most stateful codec have it
[20:27] <ndufresne> which reminds me I need to merge some related patch in 1.17 of GStreamer about that
[20:27] <paulk-leonov> hehe
[20:27] <ndufresne> on GstV4l2 side, I need to flattened the helpers, it was originally design in a way that the buffer pool manages the entire dev state
[20:28] <ndufresne> so it's basically a mess now (this code is like 20 years old)
[20:29] <ndufresne> but it knows how to do things that are pretty hard in V4L2
[20:29] <ndufresne> and abstract that in the gst way
[20:29] <ndufresne> so yeah, long term is to have an implementation based on that
[21:10] *** juvenal has quit IRC (Ping timeout: 245 seconds)