| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| montjoie | hello any idea of client for testing a v4l2(zoran) driver ? (apart mplayer/ffmpeg) | [08:17] |
| hverkuil | montjoie: I think qv4l2 can be used to test video capture (it should be able to decode the jpeg frames using libv4l). But it can't be used to test video output (no jpeg encoder support).
It would be nice if qv4l2 can encode to jpeg, but that would require some work. | [08:22] |
| montjoie | I have disabled output of zoran (temporarly) as it need some filter
so for the reintegration I target only capture I remember using xawtv 15years ago for zoran but it disappear from gentoo | [08:24] |
| ....................................... (idle for 3h12mn) | ||
| paulk-leonov | ezequielg: would it make sense to add media controller support for the RGA?
not so much for dynamic link configuration, but it'd be nice for dynamic function enumeration I guess it would since we do it for VPUs :) with about the same advantage | [11:39] |
| ezequielg | The vpu expose the mc mostly for the request api | [11:41] |
| paulk-leonov | ah right
that's a major requirement ezequielg: but how is userspace supposed to autodetect a m2m converter? besides driver name match | [11:41] |
| ezequielg | Good question. I should check what gstreamer does. | [11:42] |
| paulk-leonov | good point
I'll look | [11:42] |
| ezequielg | I don't think you have much choices
Just format enumeration on the queues You are asking how does it distinguish a codec from a color space converter? | [11:42] |
| paulk-leonov | ezequielg: basically yes
well, by converter I mean format,resize and colorspace indeed a picture "transformer" | [11:44] |
| ezequielg | Yeah. | [11:45] |
| paulk-leonov | there's gst_v4l2_is_transform
all about caps | [11:45] |
| ezequielg | Yup | [11:45] |
| paulk-leonov | not sure it's so relevant | [11:46] |
| ezequielg | If it has selection api , it can do cropping. If it has frame size enumeration it can do scaling, etc
Of course, feel free to extend the driver with MC api. | [11:46] |
| paulk-leonov | yeah I was about to ask if that'd be welcome or not | [11:47] |
| ezequielg | Patches are always welcome
:) | [11:47] |
| paulk-leonov | ezequielg: another thing, I noticed RGA is using the single-plane API
but it looks like regs can take different values for each plane RGA_SRC_Y_RGB_BASE_ADDR/RGA_SRC_CB_BASE_ADDR/RGA_SRC_CR_BASE_ADDR is there a motivation behind not using mplane in this case? (in cedrus we don't use mplane although there are different registers because it actually uses an internal offset from first plane on a limited number of bits, which overflows if the gap is too big) | [11:51] |
| ezequielg | Probably because the author didn't think about this. I don't think any new driver should use the non mplane api
Not that mplane api and planar formats are a totally different things *note | [11:54] |
| paulk-leonov | yeah I know you can represent planar formats with non-mplane
(single plane) mplane is about memory planes AFAIK not logical planes it's just that it makes dma-buf import more flexible | [11:55] |
| ezequielg | And the converse is true as well
That's why I believe mplane is a better api I'd be in favor of that change as well | [11:56] |
| paulk-leonov | one thing I'm not sure about
is if it's valid to use non-mplane formats with mplane API like NV12 (instead of NV12M) on mplane of course the other way around is not valid | [11:57] |
| ezequielg | Yes it is perfectly valid afaicr
Hantro for instance should be like this. Off the top of my head because I'm not on my office | [11:58] |
| paulk-leonov | ah true | [11:59] |
| ezequielg | In fact, hantro does packed formats | [11:59] |
| paulk-leonov | IIRC encoding only takes single-memory plane
but decoding takes multiple or the opposite | [11:59] |
| tfiga | the opposite :) | [11:59] |
| paulk-leonov | okay so basically we could have kept cedrus using mplane with non-M formats | [12:00] |
| ezequielg | Yes | [12:00] |
| paulk-leonov | good to know :)
thanks | [12:00] |
| ezequielg | I think I have told you this. Or I tried | [12:01] |
| paulk-leonov | quite possible | [12:01] |
| tfiga | but there is currently a little bit of an annoyance when dealing with M and non-M formats, because the drivers need to handle them separately
and that results in some inconsistency where some drivers advertise only M formats, while they could support non-M as well | [12:01] |
| ezequielg | Yes
Yes And separate helpers The world is far from perfect | [12:01] |
| paulk-leonov | maybe v4l2 could transparently provide non-M formats when M is supported?
(in theory) | [12:02] |
| tfiga | the extended fmt and buffer ioctls should solve this in theory | [12:02] |
| ezequielg | Iirc Boris tried that? | [12:02] |
| tfiga | although I haven't had a chance to take a look at the latest version yet | [12:03] |
| ezequielg | tfiga: any idea why we aren't covering release buffer ioctl on the ext buffer api? | [12:03] |
| tfiga | no idea
I haven't been following this too much lately | [12:03] |
| ezequielg | Sounds like now is the time to tackle that.
Trying not to scope creep | [12:04] |
| tfiga | paulk-leonov: for reference, https://patchwork.kernel.org/project/linux-media/list/?series=328929 is the series I was talking about | [12:04] |
| ezequielg | paulk-leonov: you are working on px30 or ...? | [12:04] |
| paulk-leonov | tfiga: thanks, I haven't been following that either
ezequielg: yeah still px30 | [12:05] |
| tfiga | I think release_buf could be just worked on in parallel
I suspect it wouldn't depend on the extended fmt and buffer API I also dropped some ideas in my recent reply about the stateless API | [12:05] |
| ezequielg | paulk-leonov: can you post support for that in hantro? I have some patches but nobody to test them, and I'm sure you have the same patches, plus testing | [12:06] |
| tfiga | like batch QBUF/DQBUF | [12:06] |
| paulk-leonov | ezequielg: oh yeah I had that around for a while but didn't get to cleaning them
ezequielg: nothing stands out though | [12:07] |
| tfiga | with the ability to poll on a request, batch DQBUF could be a thing
the kernel could return all available buffers at once | [12:07] |
| paulk-leonov | ezequielg: one thing is that it doesn't have rkvdec so I also brought patches from Kwiboo that enable h264 decoding in the hantro driver
ezequielg: not sure if that was merged for rk3399 but when I looked at it rk3399 only had mpeg-2 via hantro driver | [12:07] |
| tfiga | sadly I don't have much time to spend on video these days | [12:08] |
| paulk-leonov | (that's vdpu2 layout instead of traditional hantro) | [12:09] |
| tfiga | but hopefully our video team picks some of this topics | [12:09] |
| ezequielg | tfiga: I think the h264 uapi series is not entirely responsible of discussing a new qbuf api ;) | [12:10] |
| hverkuil | tfiga: can you review "[PATCH v11 22/28] media: platform: Change the call functions of getting/enable/disable the jpeg's clock"? It's the only one without your Reviewed-by in the series.
tfiga: I found some compiler warnings/errors, so there will be a v12. | [12:11] |
| tfiga | ezequielg: well, it is, because we need to make sure that we can solve the remaining problems later, if we want to stabilize the h264 api now | [12:12] |
| ezequielg | We want to stabilize those controls, not fix the world | [12:12] |
| tfiga | otherwise we would have to come up with a new h264 api in a couple of months | [12:12] |
| ezequielg | s/months/years? | [12:12] |
| tfiga | not necessarily
actually, any arbitrary time when people actually start use the API in production use cases | [12:13] |
| ezequielg | Are we aware of any vendor that can do batching, are we aware of any plans to submit new drivers for that? | [12:13] |
| tfiga | I think Cedrus can do already?
I don't know about any specific vendor work but we expect this to be used widely after we stabilize it | [12:14] |
| ezequielg | For cedrus I think the current api covers a well defined and useful use case | [12:15] |
| tfiga | and hardware batching is just a small part of the problem
I'm sure it is as I explained already, we don't need to fix all the problems right away we need a plan to fix them in the future | [12:15] |
| ezequielg | I think we have a plan
Proper support for dynamic arrays | [12:16] |
| paulk-leonov | tfiga: it's not really proper batching in cedrus, no | [12:16] |
| ezequielg | And an array like control | [12:16] |
| paulk-leonov | just that the hardware will keep processing appended slices apparently
but without a chance to update the slice header registers so if it works, it's "by chance" | [12:16] |
| tfiga | in any case, hardware batching is only 1 of the 4 problems I listed
another one was pointed out to be already solved by polling on the requests | [12:18] |
| paulk-leonov | I should get into the h264 uapi discussions, but my view is that we should limit slice mode to 1 slice | [12:18] |
| tfiga | ezequielg: so you mean we would extend the frame mode to describe the slices?
paulk-leonov: yes, I agreed with that already but V4L2 has problems preventing this mode from operating efficiently which I listed in my email and provided some ideas for improvement | [12:19] |
| paulk-leonov | mhh your points make sense yes
syscall overhead may be acceptable if per-slice helps with latency (e.g. in network streaming cases) but yeah, still valid | [12:20] |
| tfiga | what I'm looking for is the awareness of the problems and some discussion on how we could solve them in the future, not implementation
particularly, in terms of whether the controls as we stabilize them, wouldn't prevent fixing those problems it's very possible that they are fine | [12:22] |
| paulk-leonov | well there's the question of keeping the num_slices element
IMO a proper solution wouldn't need that anyway | [12:23] |
| tfiga | if we agree that the ideas I proposed are feasible, I think we could indeed solve them without changing the h264 controls proposed by ezequielg | [12:23] |
| paulk-leonov | dynamic array support looks like best idea to fix that
and it wouldn't conflict with the controls and could be dealt with later on | [12:24] |
| tfiga | hverkuil: will take a look. thanks for the heads up | [12:24] |
| ezequielg | That's my view. As well | [12:24] |
| tfiga | okay, so the intention is to bring back the slice array once V4L2 gains proper support for dynamic arrays
I think that solves all the problems I listed great, thanks :) Could you reply mentioning so in the thread? | [12:28] |
| ezequielg | I can, sure
I was getting back to this just this week | [12:30] |
| tfiga | thanks :) | [12:30] |
| .... (idle for 15mn) | ||
| paulk-leonov | back to the rga topic:
looks like 3 proc types would apply: MEDIA_ENT_F_PROC_VIDEO_SCALER/MEDIA_ENT_F_PROC_VIDEO_PIXEL_ENC_CONV/MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER should I make 3 proc entities linked to the same source/sink pads? | [12:45] |
| mhh I'd rather be able to use v4l2_m2m_register_media_controller
so I'll go with scaler for now | [12:57] | |
| ..... (idle for 20mn) | ||
| hverkuil | ezequielg: if you can create an RFC detailing the functionality of dynamic array controls, then that can be a starting point for discussion. When we all agree, then I can implement this. | [13:18] |
| ........ (idle for 37mn) | ||
| ezequielg | hverkuil: I'd like to post the h264 uapi controls v3, which may or may not be mergeable, and then would like to take a look at the array control api. | [13:55] |
| ............................ (idle for 2h16mn) | ||
| paulk-leonov: which application are you intending to see consume this MC API?
(for RGA) | [16:11] | |
| paulk-leonov | ezequielg: that's a linphone plugin I'm writing
our use case is px30 for linphone voip with camera if, hw encoder, hw decoder, rga and video in a plane it's just to do auto-detection of the video node since there are many at this point | [16:11] |
| ezequielg | hm...
as you know, a decoder can have an inline block for scaling and color convert i wonder how useful it is to choose a fix function. | [16:13] |
| paulk-leonov | yeah
mhh that's worth discussing and specifying | [16:14] |
| ezequielg | otoh, if you have VIDIOC_ENUM_FRAMESIZES and ENUM_FMT says it's a decoder, i'd say you have scaling caps.
similarly to SELECTION_API | [16:15] |
| paulk-leonov | yeah but not m2m scaling
like, you can't use the scaler out of the pipeline (since it's inline) so even if it was described in mc it'd be clear that it cannot be used for memory to memory scaling if that's your concern | [16:15] |
| ezequielg | well, similarly: if ENUM_FMT(SINK) doesn't include a coded format, then it's not a decoder.
if same goes to ENUM_FMT(SRC), it's not an encoder. | [16:16] |
| paulk-leonov | right
but what's wrong with the mc entity function? it's less logic to figure it out since it'ex explicit | [16:16] |
| ezequielg | have you implemented the userspace part? | [16:17] |
| paulk-leonov | yeah | [16:17] |
| ezequielg | is it really less logic? | [16:17] |
| paulk-leonov | okay no
it's not | [16:17] |
| ezequielg | :) | [16:17] |
| paulk-leonov | but
conceptually it is | [16:17] |
| ezequielg | well, you asked what's wrong: it's very cumbersome to consume.
and it can't expose multi function devices, can it? | [16:18] |
| paulk-leonov | to me that's legit, mc aims to represent complex pipelines so it takes some code to get there | [16:18] |
| ezequielg | if you can cleanly put a set of caps: SCALE, CSC, CROP, then that's OK | [16:18] |
| paulk-leonov | that's what I was asking earlier
maybe caps/flags would be more appropriate indeed instead of a single fixed function but multiple entities with the same sink/source would also make sense IMO less easy for userspace to manage, but meh | [16:18] |
| ezequielg | I know this might be not nice to say, but I think we should decide with patches on the table
if it looks good, it's good :) and if it's a pain to consume, maybe we need a library, but that's another topic no? | [16:19] |
| paulk-leonov | well currently I've just put a single entity for scaler
which is what I'll submit for RGA yeah sure, a library is always a good solution (I just like to do bare metal stuff, but it's a personal preference) anyway, bbl | [16:20] |
| .... (idle for 16mn) | ||
| ezequielg | +1 | [16:37] |
| headless | -1 | [16:48] |
| .... (idle for 19mn) | ||
| ezequielg | =0 :/ | [17:07] |
| ............. (idle for 1h1mn) | ||
| paulk-leonov: jernej: any idea what's the purpose of having both VE_H264_VLD_LEN and VE_H264_VLD_END?
i.e. what use-case would need that to be any different then end = start + len ? | [18:08] | |
| jernej | not sure to be honest, I was wondering same myself
I think that it doesn't hurt to set both values according to buffer size but I didn't test that thoroughly | [18:11] |
| ezequielg | jernej: can you confirm me this works? cedrus_write(dev, VE_H264_VLD_LEN, vb2_get_plane_payload(src_buf, 0)); --no hurries?
i think the size field in the slice-params should be dropped. | [18:13] |
| jernej | well, I can guarantee that won't work, you have to multiply it by 8 :) | [18:14] |
| ezequielg | haha lol
that's why i need to test things | [18:15] |
| jernej | ezequielg: main difference between them is that with vld_len you can address 64 MiB and with vld_end whole 4 GiB | [18:23] |
| ezequielg | in a way, it would be nice to use vb2_get_plane_payload consistently, and avoid depending on a field passed from userland. | [18:23] |
| jernej | is it plausible to have one slice bigger than 64 MiB? I think no | [18:26] |
| ezequielg | i am yet to see the spec talking about maximum sizes
i wonder what would result from encoding an 8K noisy frame, using IPCM on all MBs. That's the least compressed setup I can think of. it's fair to say no encoder will do that. | [18:30] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |