<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
***: svarbanov has quit IRC (Ping timeout: 268 seconds)
<br> dagmcr has quit IRC (Read error: Connection reset by peer)
<br> ldts has quit IRC (Read error: Connection reset by peer)
<br> snawrocki has quit IRC (Quit: Leaving)
svarbanov: hverkuil, please take a look https://patchwork.linuxtv.org/patch/55607/
bbrezillon: <u>hverkuil</u>: oops, brain fart. Of course adding flags in ->querycap() is not sufficient since I'm checking vdev->device_caps
<br> <u>hverkuil</u>: should I wait a bit before sending a v4?
hverkuil: <u>bbrezillon</u>: yeah, wait a bit.
<br> <u>svarbanov</u>: replied
bbrezillon: <u>hverkuil</u>: I have a technical solution to snawrocki's concern
<br> not saying it's the right solution, but it should allow us to get rid of the enum_fmt_mplane() hook without changing the fimc-lite and fimc-isp-video drivers
<br> how about clearing the _MPLANE cap bit in the ->querycap() hook
<br> and setting it in vdev->device_caps
ndufresne: mripard, paulk-leonov: How does the allwinner codec handles having multiple slice per frame ?
<br> I'm trying to see if my understanding of the SLICE_RAW format is right
<br> and I remember it says you need 1 v4l2_buffer per frame, so I'm wondering how do you manage to figure-out the offset of each slices if they have no headers ?
<br> I can provide streams if you don't know what I'm talking about
<br> (they are pretty common with webrtc)
hverkuil: <u>bbrezillon</u>: that will work.
paulk-leonov: ndufresne, we don't handle it at all for now
<br> ndufresne, that's one of the major reasons we need to rework the controls
<br> I would suggesting having H264_SLICES formats, which take an array of slices either in annex-b in the buffer directly or with controls and only the compressed data in the buffer
<br> but for H265 our decoder needs parsed values from the slice nal unit header
<br> but we can maybe add that to the slice control instead and taking only compressed data
<br> in any case, we can always manage adding an offset to our data, so annex-b with a bit offset to the compressed data would always work for us
<br> but I guess it's good to have a format that doesn't require the full annex-b too
<br> having a bit offset associated with annex-b would be quite useful in any case
<br> so maybe we should have an extra control for annex-b to specify that
<br> which would be specified instead of slice_params
<br> but I wonder how to handle the case where the decoder would be wired to take data in annex-b format but would still required parsed slice data
<br> in that case maybe we can have another format for annex-b + parsed slice data in the control, and also have the extra control for annex-b that I'm thinking about for the bit offset to the data
<br> so that would be 3 pixfmts:
<br> - compressed data only (with slice_params array)
<br> - annex-b only (with annex-b params only)
<br> - annex-b + parsed slice header (with annex-b params and slice_params array)
<br> ndufresne, would that work for you?
<br> IIRC the rockchip and tegra decoder would fall in that third case
<br> in cedrus we can support 1 and 2
<br> 1 and 3*
<br> so an userspace implementation could try to go for pixfmt 3 (most likely to be supported) and then try 1 or 2
<br> mhh we probably also need a bit offset for case 1, so that the same buffer can be reused
<br> since ffmpeg will have both the raw slice and the parsed data available
<br> (raw slice including slice header)
bbrezillon: <u>hverkuil</u>: ok, if you're okay with this hack I'll do that, and let you and snawrocki work on a future-proof solution ;)
ndufresne: paulk-leonov, an array of slices completely break the point why multi slice frames exist in the first place
paulk-leonov: oh right
hverkuil: <u>bbrezillon</u>: yeah, let's do that.
paulk-leonov: ndufresne, I forgot that point
<br> that's how it's exposed for the downstream rockchip vpu decoder in chromeos
<br> but yeah, better if we can pass slices individually and render each slice separately
ndufresne: the decoder can start working on a single slice, and that result in much lower latency, as you don't idle your driver as long
paulk-leonov: yeah
ndufresne: Ok, I'm trying to catch-up, I'm really late to the show here
paulk-leonov: it's good to have userspace handle that anyway for multi-slice cases
ndufresne: imho, the more you leave on userspace, the fastest and most stable we'll get codec support on Linux
paulk-leonov: agreed
ndufresne: I'm not done reading the backlog (I'm slow reader ;-D)
paulk-leonov: IIRC we thought about that a while back and there should be no API issue for decoding on a per-slice basis instead of per-frame
<br> with a bit offset to specify where the slice data is in the current buffer, we should be good
<br> then we can either pass different output buffers for each slice or reuse the same one and update its offset
ndufresne: ok, that was exactly my next question
<br> paulk-leonov, how to we tell the codec which output buffer to use ?
<br> in VAAPI it's explicit, so the accelerator does not need to worry about anything
paulk-leonov: ndufresne, output (source) is part of the request
ndufresne: sorry the capture buffer
paulk-leonov: but capture will get picked up by the core
ndufresne: this output/capture is just worst naming for that
paulk-leonov: :)
<br> we just re-queue the capture buffer
<br> it would have to be the only one queued
ndufresne: ok, but do we really want all our drivers to implement H.264 new frame detection ?
paulk-leonov: to make sure it's picked
<br> why do we need to do that?
ndufresne: it's the only way the driver can manage to decide to pick a new capture buffer, or reuse the same one
paulk-leonov: I'm not sure there is any notion of "the same one"
ndufresne: and because of buggy encoders, you don't just implement the spec
paulk-leonov: it's a different request being handle
<br> and the core will give it the next available queued capture buffer
ndufresne: if you have two slice in one frame, you will have to decode them into the same capture buffer
paulk-leonov: so if it's the same buffer as long as it's the same frame, it should work
<br> yes, but userspace should handle that
<br> not the driver
ndufresne: ah ok, so we don't pool all the buffer, we only pool the next buffer, the one to use ?
paulk-leonov: in that case I don't see any other choice
ndufresne: ok, but is it how we do it now, or a modification ?
paulk-leonov: it's already what is done now
ndufresne: ok, good thing
paulk-leonov: maybe we could explicitly select the buffer with its timestamp to allow queueing more capture buffers
<br> I don't see an obvious use case for it
ndufresne: the problem is in v4l2, you cannot queue twice the same buffer
paulk-leonov: well, you need to dequeue it first
ndufresne: so you won't be able to pipeline the slices
<br> the driver will go to sleep meanwhile and performance will suck
paulk-leonov: mhh yes, that would require userspace to re-schedule a request at each decoded slice
<br> and not submit the batch in one go
ndufresne: hverkuil, ^ that one is a bit of a blocker in my opinion, unless we know we can extend that later
paulk-leonov: We could use the timestamp for that
ndufresne: hverkuil, basically if we have two slices for 1 capture frame, how can we pipeline the decode of the two slices ?
<br> paulk-leonov, that's the other option, the driver is not really implicated in DPB eviction right ?
paulk-leonov: no, that's up to userspace
ndufresne: by eviction I mean the moment we produce a RW capture buffer
paulk-leonov: ah not sure I followed
<br> what't the relation with the DPB?
ndufresne: buffers are kept in a data structure we call DPB
<br> in usespace, and when following the spec
<br> A decoder will only produce a buffer when it get evicted from the DPB, which means it will no longer be used in any decoding further ahead
paulk-leonov: right, in v4l2 the dpb entries are associated with capture buffers with their timestamp and it's fully up to userspace to maintain the dpb
ndufresne: the reason is that it's only at this moment that you can produce a RW buffer
<br> of course you can cheat and lower latency, but anything writing into the produce buffer could corrupt the folling frames
paulk-leonov: so yeah, userspace removes the next capture buffer from the dpb
<br> that's already handled
ndufresne: but I understand that there is some mapping in the driver, to match timestamps
<br> but I don't know how that part works
paulk-leonov: the timestamp is copied from the output buffer to the capture buffer
ndufresne: I wonder how does this mapping get updated ?
paulk-leonov: and it's used later in following frames in the dpb array
<br> dpb is fully explicit in the controls
<br> so it's updated with every new request submitted
ndufresne: ok, so assigning a new TS to a capture buffer is done by queueing that buffer ?
<br> queueing is basically telling the driver of the next free buffer ?
paulk-leonov: not exactly, ts is only assigned to output
<br> and capture gets the ts from output when rendering to that capture buffer is done
<br> so it has to be queued first, but also rendered
<br> s/rendered/decoded/
ndufresne: but when you get the ref list from output, where do you pick the output reference frames from ?
<br> do all reference frames need to be queued ?
paulk-leonov: no, they only need to be kept alive by userspace
ndufresne: that's kind of easy, it's really hard to free a single buffer in v4l2 (I mean impossible)
paulk-leonov: and the capture ts is set back to 0 when the capture buffer is queued or picked for decoding (not sure which it is)
ndufresne: ah, that's what I wanted to know
paulk-leonov: ndufresne, I mean, userspace needs to not re-queue them while they are still used as reference
<br> either no re-queue or not re-render
<br> let me check
ndufresne: ok, so that should work, since the slices will all have the same TS
<br> the driver should only go visit the queue, if it has a unknown TS in hand
<br> so to pipeline slices, you simply queue the second, and following slice, with same TS, without queuing a new capture buffer
<br> or even, you could queue any free capture buffer, to keep the driver list small, but these won't be picked if the timestamp is known
paulk-leonov: that would only work if we don't set the ts to 0 when queuing the buffer though
ndufresne: well, you won't queue twice the same buffer
<br> e.g. a new slice should not automatically imply picking a new capture buffer
paulk-leonov: and I'm not sure we should require that all slice output buffers have the same ts
ndufresne: the driver need to check if the timestamp is known already
paulk-leonov: well, no, actually I think we should require that all the output buffer for the same capture buffer have the same ts
ndufresne: well, a frame cannot have multiple timestamp
<br> we must require that
paulk-leonov: agreed
ndufresne: (it is required in RTP spec and other specs like ISOMP4, MPEG TS, etc.)
paulk-leonov: so yeah, it can just check if we already have a matching timestamp in the capture queue and pick the next avail buffer if not
ndufresne: I haven't checked the timestamp SEI, but it might be specified there too
paulk-leonov: that would work fine
ndufresne: and if it picks the wrong buffer, it's userspace fault, it will just make a weird frame as requested by userspace
paulk-leonov: yep :)
ndufresne: now the fun part will be to understand what Rockchip support
<br> the Allwinner API is the sane way imho
paulk-leonov: so rockchip needs annex-b slice data but also the parsed slice control
ndufresne: that's fine to me
paulk-leonov: allwinner only needs compressed data + parsed slice control
ndufresne: basically if you hardware uses a wring buffer to pipeline the slices
<br> you need something to then split them up later
paulk-leonov: ah you mean the rockchip schedulnig thing
ndufresne: but I'm being told that rockchip IP is a slice of an ancient statefull IP
<br> and they kept some of the work on their side
paulk-leonov: I see
ndufresne: so the order of reflist isn't processed or something
<br> basically, before sending slice to VAAPI or Allwinner VPE, we reorder the list with a specific algo (pseudo code in the spec)
<br> This order is what an accelerator needs to be able to only execute the decoding, without branches
<br> when I look at FFMPEG and GStreame VAAAPI, you can see that flow, we extract a list from the DPB (in DPB order) and then process that list
<br> so I'll instrument the vendor stack to figure-out what order they really pass there
paulk-leonov: do you think the order needs to be different for rockchip?
ndufresne: yes, that's what we think
<br> and that means two type of ref-list
paulk-leonov: can't the driver just re-arrange the dpb order if it needs to?
ndufresne: I tried to get the info from ayaka, but most of the time I cannot parse the answer, and he's always frustrated
paulk-leonov: ah but that's not submission order
<br> ndufresne, IIRC hverkuil met with him at FOSDEM, maybe that's one of the things they discussed
ndufresne: maybe, but the "ref_list_execution" algo is not trivial, so that seems error prone
paulk-leonov: I would like to see source code about what's really going on there
ndufresne: then I'll share my investigation, this is what I'll be doing next week
paulk-leonov: great
ndufresne: the userspace source code is open source fortunatly, https://github.com/rockchip-linux/mpp
paulk-leonov: are you working on the rockchip hw yourself?
<br> for the cros part it's at https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/media/gpu/v4l2/
<br> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/media/gpu/v4l2/v4l2_h264_accelerator.cc#52
ndufresne: I'm joining ezequielg on this
paulk-leonov: great
ndufresne: so our goal is to find out what this weird HW really wants, and figure-out the right kernel API to support it
paulk-leonov: we should definitely coordinate about that
<br> sofar we have already discussed most of the things I want to rework
ndufresne: but that's also why we pushed SLICE_RAW vs SLICE_ANNEXB lately
paulk-leonov: (pixfmts and per-slice decoding)
<br> ndufresne, note that the pixfmt is not public now
<br> I think it was too early to have this discussion
ndufresne: yeah I know, which is good
paulk-leonov: I'll go the same path for H265, with what works for allwinner so far
<br> and then we can improve and rework that when adding another codec
ndufresne: btw, if you need any kind of streams, I can help with that
paulk-leonov: streams as in video stream for testing?
ndufresne: yes, and also if you want to know how to create some specific streams, like multi slice er frame using x264/5 or openh264 I can help
paulk-leonov: ndufresne, neat, that would definitely be helpful yes
<br> ndufresne, the main problem I'm working on solving is having proper software to pipe ffmpeg decoding to drm without any gpu backing
ndufresne: same for ezequielg
paulk-leonov: I spent too much time trying to debug kodi/mpv/gstreamer so I'm working from scratch
ndufresne: so our plan was to work on ffmpeg first, as a test, because it supports full parsing and has no deps
paulk-leonov: it's part of a larger project too, I also want to resurrect 2D DRM rendering and stuff
<br> yep I think that's the way to go
<br> libreelec folks did some early work there
ndufresne: but our target is chrome on our side, so I'm not sure how far I'll go in upstreaming the ffmpeg work
paulk-leonov: (you probably know already)
ndufresne: the FFMPEG community is toxic with GStreamer devs
<br> yes, I'm super amazed by the work they do
paulk-leonov: well, maybe you can find people form libreelec/kodi to do the upstreaming part
ndufresne: I think if it's not me, it's better
paulk-leonov: and I think what we need above all now is to stabilize the kernel uapi
ndufresne: that being said, all VAAPI stuff was done by Benjamin Gaignard, who was also a gst dev
paulk-leonov: heh
<br> it's in a good shape in ffmpeg
ndufresne: it's funny, because it's really the strict minimum
paulk-leonov: even supports exporting to DRM prime, which is cool
ndufresne: yeah, but the trick is that it's done by the VAAPI driver
<br> the memory layer in VAAPI is really high level
paulk-leonov: yeah it sure is
<br> it's mostly boilerplate
ndufresne: it's also opaque
<br> it's very unlike dmabuf
paulk-leonov: heh
<br> anyway for now I'm aiming at using vaapi with ffmpeg
<br> and our libva
<br> I don't think it covers all h264 but already a good part of it
<br> fine testing would be best with native ffmpeg support though
<br> but I think that can wait for now
ndufresne: paulk-leonov, I believe what's missing is SVC layer support, but it will kindly skip that for you
<br> and it's able to play one eye of MVC iirc
paulk-leonov: ndufresne, so I checked and vb2 core currently sets timestamp to 0 on non-output buffers (so including capture)
<br> hverkuil, can we change that to when the buffer is picked from the queue?
<br> so that we can use the timestamp to pick the buffer
<br> in m2m
ndufresne: but if we don't requeue capture buffers, that behaviour is fine no ?
paulk-leonov: currently, when the capture buffer is queued*
<br> ndufresne, well, you always need an explicit capture buffer
ndufresne: it's explicit by the timestamp
paulk-leonov: or rather, we should not dequeue it
<br> mhh we should check if a buffer is still considered prepared once the job is done
ndufresne: paulk-leonov, what would be the difference between keeping it queued, or not ?
paulk-leonov: ndufresne, v4l2 will only allow queued buffers to be used for decoding
<br> I think that's sane and we probably don't want to change that
ndufresne: ok, so right now all reference frames are queued ?
<br> that's was gray thing to me
paulk-leonov: no, that's the exception
ndufresne: ok, but then it's not a limitation of the vb2
paulk-leonov: well, it's more that decoding requires capture and output (grabbed from the queue)
<br> reference frames handling is parallel to that
ndufresne: so that's my point, to handle multi-slice frames, you have to lookup for an existing buffer with the timestamp first
<br> and if that is not found, then you pick from the capture queue a new one
paulk-leonov: yes indeed, but it's different from doing that for the references
<br> for capture buffer, we can only pick it from the queue
<br> mhh, so you'd bypass the entire queuing system if we have a timestamp?
ndufresne: the decoder will need the decoded buffer reference too, so why it's different ?
paulk-leonov: in one case it's reading, in the other one it's writing
<br> we shouldn't write to buffers that are not in the queue
<br> basically, not in the queue means that v4l2 should keep its hand off it
ndufresne: ok, so it's just a concept you'd like to enforce
paulk-leonov: for reference we made an exception because it's only ready
hverkuil: sorry guys, this discussion is bad timing for me. Perhaps someone can summarize in an email?
paulk-leonov: only reading*
<br> hverkuil, yes we will definitely do that
<br> ndufresne, it's not just a random limitation
<br> write access to buffers implies preparation, etc
<br> might also involved fencing in the future
<br> so you can't really just bypass all that
ndufresne: right, which is in the queuing mechanism, unlike DMABuf and DRM
paulk-leonov: yes
hverkuil: Note that I have vacation from, well, now until April 22. Back on the 23rd. If time permits I'll try to dig into this, but no guarantees (as I said, bad timing!).
ndufresne: but I'll leave the memory coherency on the side, that's massively broken in vb2 atm
<br> hverkuil, hehe, we'll have to live without you, hard ;-D
<br> paulk-leonov, ok, bug leaving it queued is not a problem
paulk-leonov: ndufresne, either way, the point of multi-slice would also be not to have to re-queue between each slice :p
ndufresne: userspace knows when a frame is complete and so should know when to dequeue it
paulk-leonov: so yeah, we should leave it queued
<br> yes
ndufresne: make sense
paulk-leonov: so bottomline is that it should work as is
<br> for this part
ndufresne: ok, one curiosity
paulk-leonov: by just keeping the buffer queued
ndufresne: does it pop that buffer from the queue, or who does that work ?
paulk-leonov: I'm pretty sure it's up to userspace
ndufresne: no, I mean internally, the driver will access a queued buffer
paulk-leonov: yeah so m2m will associate 1 output and 1 capture buffer per decoding context
ndufresne: so do we peak the buffer, or do we pop that buffer, I don't know if there is vb2 complication
paulk-leonov: I'm not really sure of the details here
<br> there is probably a buffer state that evolves
<br> besides from being queued or not
ndufresne: ah ok, anyway ezequielg will tell me if he hits a wall on hist side
<br> oh right, it's a state
<br> ok, I just tend to worry about everything I don't know
paulk-leonov: yeah, it's definitely good to have that input
<br> lots of pitfalls around :)
***: prabhakarlad has left
ndufresne: just a stronger argument to keep things are stable
paulk-leonov: mhh so I think we might still run into trouble trying to re-use a buffer without de-queing/queueing it, but it'll probably be manageable
ndufresne: I think it's manageable by userspace
paulk-leonov: (in terms of v4l2 core integration)
<br> yeah for userspace it's definitely straightforward
***: benjiG has left
Kwiboo: <u>ndufresne</u>: paulk-leonov: I sent out a RFC of my ffmpeg v4l2 request api hwaccel to ffmpeg-devel list earlier this week, see https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242316.html
<br> regarding slice decoding me and jernej already do slice decoding for h264/hevc in cedrus by reusing buffers and only sending bitstream data for one slice
***: harrow` has quit IRC (Quit: Leaving)
ndufresne: Kwiboo, ok, so that kind of work, when you say re-using can you clarify the call flow ?
Kwiboo: <u>ndufresne</u>: we queue the same capture+output buffer when ffmpeg sees a new slice for the same frame: see https://github.com/Kwiboo/FFmpeg/blob/v4l2-request-hwaccel/libavcodec/v4l2_request_h264.c#L262-L266
ndufresne: Kwiboo, but that will be pretty inefficient, since you run your HW in lock steps
<br> that was the point of today's discussion
<br> we need to be able to leave the buffer queued
<br> with a cycle of q/dq
<br> * without
Kwiboo: yep, but still efficient enough to decode videos at full speed
ndufresne: well, that is strictly related to your definition of fullspeed, and your HW
<br> you should be able to push the next slice before the previous one is done
<br> some decoder I know can even run this in parallel
Kwiboo: sure but even today we do similar with rkmpp decoder, send one packet and wait on a frame, and sure at 4k@60hz using the LG Chess sample we can only reach 57-58fps
ndufresne: that's good to know, but in term of the kernel API we don't want to enforce this
<br> Kwiboo, the entire point of the discussion was about that, I believe your way will keep working
<br> playing things to screen is not the only thing you do with a codec also, you might be doing offline transcoding as an example
Kwiboo: I can understand that and I hope to be able to queue multiple buffers/slices in ffmpeg hwaccel, mainly just wanted to point out that it is possible using today api to get multi slice videos decoded even if it is not optimal
ndufresne: great
<br> Kwiboo, so I guess later own if I need help you'll be able to guide me through your code ?
<br> we'll need to make that work on the upcoming RK driver too, but the bitstream / format is different, and we think there is a catch in the ref list order, that last bit I'll investigate next week
<br> Kwiboo, doing that on your own time or are you active daily on that effort ?
Kwiboo: sure just give me a ping and I will try to help, the mpeg-2 part already work for rk vpu driver, I am doing it on my own time
ndufresne: thanks, and yes, that's what ezequielg told me
<br> but mpeg2 is the easy one
Kwiboo: yep, mpeg-2 was an easy one, I never got fully into the h264 parts other then generating a base template for vpu1/vpu2 decoding of h264 using https://github.com/Kwiboo/rockchip-vpu-regtool, never really tested the code that got generated
ndufresne: oh, ok, It think I see the problem, you might be able to confirm
<br> So basically you push a slice, and a capture buffer, want poll, it will unblock when the buffer state change to DONE inside the kernel (or an error)
<br> if you don't want to do that in lock step, you'd leave the buffer queued, but you are left without a way to know when the frame is complete
<br> at least it's racy
<br> paulk-leonov, ^ we should raise that in a mail to hverkuil
Kwiboo: yep, sounds correct, I would like to just skip the poll/select and just return early and have a tail job that checks/wait on the buffer to complete when an avframe is to be returned to application
paulk-leonov: Kwiboo we should use fences for that
<br> but that's not in v4l2 yet
<br> IIRC ezequielg was working on it
<br> this we way we could fence with display
ndufresne: paulk-leonov, there is one place where fence are not usable, it is for AV sync
<br> because of the lack of an API to pass a fence, a buffer but also the time at which this frame should be renderered
<br> and we didn't go visit back drm last time, so that's why that worked stopped
<br> the benefit of the fence is that you'd have a fence per slice, and could wait on this, but the RFC that was sent isn't able to signal twice the same buffer without requeue, so no progress there
<br> A workaround is simply to not let the v4l2 codec driver allocate
<br> because v4l2 do let you queue the same dmabuf twice with different v4l2 buffer id, not sure if that is a bug
Kwiboo: paulk-leonov: using fences sounds good, something for the future, for now waiting on decode to finish seems to work for current libreelec/kodi use case
ndufresne: but I believe it I understand why ayaka (or Rockchip) folks are pissed, because they see inefficiencies in the userspace ... and probably thinks that's the only way to use the new kernel API
<br> at least for single slice decoding that is not a problem
Kwiboo: another inefficiency in kernel api may be that there is no obvious hook in driver to pre-generate a buffer of the hw reg state to set when a request is submitted (to me at least, but I am a novice v4l2 api user), if I understand correctly in kernel there will only be one request job running at one time: load ctrls from request, prepare data structs and set hw regs, enable, wait on hw to finish,
<br> start next job and repeat
ezequielg: <u>Kwiboo</u>: I don't think that limit is in the API.
<br> the m2m framework serializes its jobs, yes.
<br> but that's just internal.
<br> i can be wrong though.
Kwiboo: one thing they do in rk mpp lib in "fast" mode is to just prepare hw regs and structs in memory, and when hw is done do a quick write of hw regs and wait + repeat
ezequielg: how do you prepare hw regs in memory, without writing hw regs?
Kwiboo: they just write what they want to write to hwreg into regular malloc memory, and then when hw is ready for accepting next job is just loop from memory struct and write to regs
<br> from my understanting cedrus and rk vpu driver seems to work in a way that when the job start the ctrls for the current request is retreived, some processing of ctrls is done and then hw regs is written
<br> so there is a very tiny window where vpu hw wait on cpu to process ctrl data
ezequielg: right.
<br> i guess in due time, we might add a hook to prepare a request to hw first?
Kwiboo: yep, that is the main part I think that is missing from request api compared to rk vcodec driver, since the rk vcodec driver gets the hwregs state to set from userspace all it needs to do is: write hwregs, wait on hw, repeat
koike: <u>hverkuil</u>: o/ quick question, why v4l2-ioctl.c allows ioctls type V4L2_BUF_TYPE_VIDEO_{CAPTURE,OUTPUT} be implemented with only the ops of the mplane version? https://git.linuxtv.org/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n954
<br> I thought that V4L2_BUF_TYPE_VIDEO_{CAPTURE,OUTPUT} was for single planar only, and V4L2_BUF_TYPE_VIDEO_{CAPTURE,OUTPUT}_MPLANE was the right one to be used for multi-planar
<br> <u>hverkuil</u>: mchehab: Hi, I see that the patches I submit are being applied as Helen Fornazier, and not Helen Koike (which is the one I would like to use), I believe the reason is due to my profile in patchwork.linuxtv.org, but I couldn't find where to change it. Could you change it? or let me know where to change it please?