| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| gnurou | hverkuil: mchehab: I suspect there is a point in the current media tree where the kernel won't compile due to the H264 headers merge
"media: uapi: Add H264 low-level decoder API compound controls." includes media/h264-ctrls.h in v4l2-ctrls.h, but that file is added by the following patch ("media: pixfmt: Add H264 Slice format") so IIUC there is one commit where v4l2 will fail to build | [03:15] |
| .................................................................................. (idle for 6h45mn) | ||
| *** | benjiG has left | [10:02] |
| ............................ (idle for 2h16mn) | ||
| LazyGrizzly has left | [12:18] | |
| .............. (idle for 1h5mn) | ||
| hverkuil | pH5: ping
hfr: ping | [13:23] |
| hfr | hverkuil: pong | [13:23] |
| hverkuil | hfr: quick question: can the sti delta decoder handle midstream resolution changes while decoding?
hfr: ah, never mind, it only support JPEG. | [13:24] |
| hfr | yes
this use-case is usually supported by userland fwk, such as GStreamer ie in h264, we can have such a case but when this come, GStreamer close the current decoding session and restart a new one with the sps/pps set with the new resolution so for the kernel driver it should be seen as a new decoding session does it helps ? | [13:25] |
| hverkuil | the delta HW is a stateless decoder, if memory serves, and this question is for stateful codecs only.
For stateless decoders it is indeed userspace that has to take care of this. | [13:28] |
| hfr | on my opinion this do not change anything
as frame memory allocation is controlled by userspace | [13:28] |
| hverkuil | The stateful decoder API describes how to handle this cleanly without having to close a decoding session. | [13:31] |
| hfr | could you point me out a link where I can read this ?
(I've not followed the very details of recent discussion on codecs) | [13:32] |
| hverkuil | https://patchwork.linuxtv.org/patch/56545/ and https://patchwork.linuxtv.org/patch/56546/
Or read https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-mem2mem.html (documentation build with those two patches) | [13:33] |
| hfr | OK I see V4L2_EVENT_SOURCE_CHANGE
in case of resolution changed isn't it ? Then userspace is informed of format change | [13:39] |
| hverkuil | right | [13:40] |
| hfr | then new number of buffers needed on capture and resolution and format are to be get from userspace by calling REQBUFS and S_FMT I suppose ?
so this reconfigure capture side regarding new sequence | [13:41] |
| hverkuil | Yes. After the event was received you can call G_FMT and get the new format. | [13:42] |
| hfr | ok, right, we've done also that way in the past
Anyway we never implemented the "dynamic resolution change" that way Because GStreamer is doing this for us ! | [13:42] |
| pH5 | hverkuil: pong, I don't think coda firmware supports mid-stream resolution changes. At least I don't know of any interrupts or picture run return values that could report header changes. We lean on GStreamer for this as well. | [13:44] |
| hfr | GStreamer h264parse, a parser element is parsing bitstream | [13:44] |
| hverkuil | pH5: thanks, that confirms what I saw in the driver. | [13:44] |
| hfr | and is a new sps/pps is detected with a change related to format/resolution or whatever affects what have been negotiated at GStreamer dei
side a reconfiguration occurs leading GStreamer v4l2videodecoder element to close the kernel driver and reopens a new fresh one first buffers being given are the sps/pps, so reconfiguration occurs silently, as if we have done a completely new decoding session | [13:44] |
| hverkuil | hfr: but isn't the delta driver a stateless codec anyway? That was the reason at the time the h264 code wasn't merged.
For stateless codecs this doesn't apply, you always need to do it in userspace. | [13:46] |
| hfr | our proprietary implementation was a statefull decoder | [13:47] |
| hverkuil | and the actual hardware? | [13:47] |
| hfr | but as we've discussed together long time ago, the parsing code was not upstreamable
as the hardware don't have the "parsing part" we have to do it in software in kernel or in userspace when in kernel we act as "statefull" when in userspace, as a "stateless" but for GStreamer it was the same because we hide this in libv4l | [13:47] |
| hverkuil | It should now be possible to use the stateless decoder API for this hardware. Should be a much cleaner implementation. | [13:50] |
| hfr | yes of course, but it comes several years too late...
anyway this work is great and I have no doubt that codecs support will be far better now to come back to "dynamic resolution change", I don't think kernel have to deal with, or maybe very limited to "signal userspace that something have changed" and reconfiguration must be done. | [13:52] |
| mjourdan | hverkuil: I agree with your points. This would mean however that all current mainlined stateful decoders need to be adapted to add this flag if supported. the reason I went with FIXED_RESOLUTION is because it seems to be the exception rather than the norm, at least for decoders. But I didn't have encoders in mind at the time .. | [14:01] |
| hverkuil | Well, it's only s5p-mfc, venus, mediatek and vicodec. So just four.
There are also compressed codec formats that do not support this at all (e.g. MPEG if I remember correctly), and you don't want to have to set this flag for all those formats. It makes more sense to have fixed resolution be the default and signal dynamic resolution explicitly for those formats where the HW can support it. It's also easier to document it and refer to it in the codec API specs. mjourdan: can you make a v8? Sorry about this late comment, but I realized this issue while working on the v4 of the stateful codec API. | [14:02] |
| mjourdan | fair points! | [14:06] |
| hverkuil | You probably also have to rebase to the latest media master. | [14:07] |
| mjourdan | hverkuil: sure, I'll drop the patch adding the flag from the serie since it's no longer needed | [14:08] |
| hverkuil | vidioc_enum_fmt_vid_cap/out_mplane no longer exists after Boris' patch was merged today. | [14:08] |
| mjourdan | hverkuil: would you like me to prepare patches that add DYN_RESOLUTION to s5p-mfc, venus, mediatek and vicodec ? Even if they don't end up merged or anything, just to see what it looks like
hverkuil: yep I caught that in one of your latest pull request, I'll rebase | [14:09] |
| hverkuil | Yes please! I think it is very useful. Applications do need to know if this is supported or not, I think. | [14:09] |
| mjourdan | hverkuil: I agree, and ack. | [14:12] |
| hverkuil | mjourdan: looking forward to merging this! Hopefully v8 will be the winning version. | [14:18] |
| ...... (idle for 26mn) | ||
| mchehab | b-rad: and news with regards to your PR? | [14:44] |
| b-rad | have to sort other peoples emergencies first, will try send tomorrow | [14:55] |
| mchehab | ok | [14:57] |
| ezequielg | hverkuil: ping | [15:03] |
| mjourdan | hverkuil: I hope so too :) .
bbrezillon: it seems like the patch that removes the enum_fmt_mplane variants makes checks on device_caps having V4L2_CAP_VIDEO_CAPTURE_MPLANE or V4L2_CAP_VIDEO_OUTPUT_MPLANE. However all mplane decoders use V4L2_CAP_VIDEO_M2M_MPLANE which does not include either, it's a separate cap. At least in my case this makes enum_fmt fail with -EINVAL. A fix is to add both caps to my device_caps, but I don't see other drivers having been updated f that ? | [15:15] |
| ndufresne | hmm, I was sure I had raised this one already ....
ndufresne been inattentive to these patches lately | [15:19] |
| mjourdan | (or, rather than modifying the driver's device_caps, the core code for enum_fmt should also check for V4L2_CAP_VIDEO_M2M_MPLANE) | [15:27] |
| .... (idle for 15mn) | ||
| hverkuil | mjourdan: true. But why didn't v4l2-compliance catch that? I'll have to dig into that.
bbrezillon: can you post a patch to fix this? | [15:42] |
| *** | prabhakarlad has left | [15:47] |
| hverkuil | argh, vicodec isn't tested yet in the test-media script :-(
enum_fmt does fail with multiplanar vicodec. | [15:51] |
| ...... (idle for 25mn) | ||
| bbrezillon | hverkuil: will do | [16:16] |
| ....... (idle for 31mn) | ||
| hverkuil, ndufresne, mjourdan: fix sent, and sorry for the mess | [16:47] | |
| *** | _abbenormal has quit IRC (Quit: Leaving) | [16:54] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |