| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | Kwiboo has quit IRC (Ping timeout: 246 seconds) | [09:18] |
| ............. (idle for 1h2mn) | ||
| bbrezillon | hverkuil, tfiga: I have a question regarding dynamic resolution changes on codecs here in my reply to "media: hantro: Fix s_fmt for dynamic resolution changes"
looks like VP9 allows resolution changes to happen between key frames (don't know if it was the case for VP8) | [10:20] |
| ..... (idle for 20mn) | ||
| ndufresne | bbrezillon, was reading about this, interesting feature, each interframe can have different resolution
that quite a challenge question though, are the reference frame scaled seperatly, or is that transparent in the IP ? | [10:42] |
| bbrezillon | ndufresne: I think they are scaled separatly, but I'm not sure | [10:46] |
| ndufresne | question was toward if we need to allocate extra memory | [10:48] |
| bbrezillon | let me check the code | [10:48] |
| ndufresne | I wonder how we can support this in V4L2, the re-allocation model will kill the perf, so we really need in-flight multiple resolution buffer, unless we know the maximm ? | [10:48] |
| bbrezillon | ok, now I understand your question
the scaling is part of the decoding process there's no external scaler block AFAICT | [10:49] |
| ndufresne | ok, that's sane | [10:49] |
| bbrezillon | ndufresne: well, there's a limit on the diff between 2 frames IIUC (no more than 16x bigger and no less than 2x smaller) | [10:51] |
| ndufresne | so I guess for now, we can just model it around the current implementation, of course the decoder will have to hold on some allocated buffer from the previous pool (up to 3), which may have been allocated with a different resolution | [10:51] |
| bbrezillon | but it's not an absolute limit
it seems to be the diff between 2 frames (the ref frames and the 'to-be-decoded' one) | [10:51] |
| ndufresne | well, in practice this is meant for video conferencing, so the step should be relatively small
I read here that it's to guaranty a better bitrate response, which I guess with google predictive bandwidth algo is crucial | [10:52] |
| bbrezillon | actually, the ref pool is 8 on VP8
with at most 3 active refs for each frame s/VP8/VP9/ ndufresne: not sure I understand how this 'buffer pool' is supposed to work you would create different buffer queues or just have one with the max estimated buffer size? | [10:53] |
| ..... (idle for 20mn) | ||
| ndufresne | so basically there is 8 slots, and each one can have in theory a different resolution right ?
we can't model this around vb queues, that's broken I would basically assume that changes are rare for a first pass, then internally dissociate the reference storage from the vb queue and hold on reference buffers even if the vb queue has been re-allocated why this isn't ideal is that if you have a ramp-up or down, each frame will cause a queue re-allocation, so we will allocate buffers that we never used we'd need something that allow using large buffers for smaller decode to optimize this one | [11:17] |
| bbrezillon | ndufresne: yep -> 8 slots with potentially different resolutions | [11:20] |
| ndufresne | yes, so we need a data structure to support this (to remember what resolution each frame has) I suppose that's visible in the IP, as you likely have per reference resolution setting (for gold, alt, etc.) | [11:21] |
| bbrezillon | ndufresne: keeping the information about each capture buf ref should be doable | [11:23] |
| ndufresne | I guess one complexifier is that the references are application knowledge, but they need to be stored in the driver too | [11:24] |
| bbrezillon | yes, that's what I about to mention
keeping track of still valid refs is likely to be a problem we only pass the active refs to the driver the 8 slots valid ref thing is kept in userspace | [11:24] |
| ndufresne | maybe we can get away with 3 controls to pass the ref ?
or maybe passing a dmabuf FD isn't an option there ? | [11:25] |
| bbrezillon | that would work too | [11:26] |
| ndufresne | we can set controls in single ioctl, and we can make this atomic with the request, I wonder what hverkuil would thing about that though, it's a bit of a stretch on the V4L2 API | [11:27] |
| bbrezillon | in that case, we don't even have to change the resolution, assuming we pass this info through a control
that's definitely hack-ish :) | [11:27] |
| ndufresne | passing FDs are a control reminds me something ...
it's pretty much how DRM works, controls and buffers got into the same bundle | [11:28] |
| bbrezillon | they do
well, we don't call that a CTRL :) but that's the idea, yes | [11:28] |
| ndufresne | to me controls and properties are fairly similar
maybe worth an RFC ? | [11:29] |
| hverkuil | I don't think it is a problem to pass dma_fds in a control. | [11:30] |
| bbrezillon | that means userspace would manage its own buf queue | [11:30] |
| ndufresne | only side, we are putting mmap method asside, but to me this is not a big deal | [11:30] |
| hverkuil | but I am not sure if I fully understand the issue. An RFC would help. | [11:31] |
| bbrezillon | I'm not sure how I should allocate the dmabuf though
VIDIOC_CREATE_BUFS maybe? | [11:31] |
| ndufresne | refs are frame that had been decoded before, so they would be picked from previously (or currently) allocated queue
this will strictly depends on the new orphaning feature | [11:33] |
| bbrezillon | so I still need to stop the stream and reallocate buffers in the queue on a resolution change, right? | [11:35] |
| ndufresne | I don't have a better, so yes
I think we discussed that maybe a driver could accept a S_FMT to a lower sizeimage, but not sure how this would be synched (e.g. when will the new format apply) | [11:36] |
| bbrezillon | so the dmabuf trick would just be a way for us to keep the buffer around until the app decides it's no longer needed as a reference
I can try implementing it like that | [11:39] |
| hverkuil | What we really need is a VIDIOC_DELETE_BUF ioctl: that way you don't have to stop streaming: instead you create new, larger buffers, and delete the old buffers once they can be discarded.
It's quite a bit of work, but this is something on the TODO list for a long time. | [11:46] |
| bbrezillon | hm, or maybe REPLACE_BUF/REALLOCATE_BUF instead of DELETE_BUF, unless we want to allow resizing the buf queue dynamically
never mind I'll have a closer look at those 2 options hverkuil, ndufresne: thx | [11:50] |
| ....... (idle for 31mn) | ||
| hverkuil | sailus: I think the ipu3-abi.h warning is related to the gcc compiler version: I get it with my gcc-9.2 when simply compiling the kernel. No need for sparse/smatch. | [12:24] |
| ...... (idle for 29mn) | ||
| sailus | hverkuil: Ack. | [12:53] |
| ..... (idle for 21mn) | ||
| *** | LazyGrizzly has left | [13:14] |
| ................................................................................................................................. (idle for 10h41mn) | ||
| KitsuWhooa has quit IRC (Ping timeout: 240 seconds) | [23:55] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |