<!-- 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>
***: BrianG61UK has joined #linux-media
<br> eelstrebor has quit IRC (Quit: Ex-Chat)
<br> wens has joined #linux-media
<br> wens has quit IRC (Quit: leaving)
<br> wens has joined #linux-media
<br> xroumegue has quit IRC (Ping timeout: 480 seconds)
<br> xroumegue has joined #linux-media
<br> jm_h has joined #linux-media
<br> fleebs has quit IRC (Remote host closed the connection)
<br> fleebs has joined #linux-media
<br> Whoopie has quit IRC (Quit: ZNC - http://znc.in)
<br> svarbanov has quit IRC (Ping timeout: 480 seconds)
<br> paulk has joined #linux-media
<br> svarbanov has joined #linux-media
mort_: I sent https://lore.kernel.org/linux-media/20210726135009.140168-1-martid0311@gmail.com/ a while ago but it seems to have gotten forgotten
***: djrscally has joined #linux-media
<br> svarbanov has quit IRC (Ping timeout: 480 seconds)
<br> svarbanov has joined #linux-media
<br> svarbanov has quit IRC (Remote host closed the connection)
<br> camus has quit IRC (Ping timeout: 480 seconds)
andrzej_p: ezequielg I understand your idea of avoiding writing the values from uAPI directly into the hardware. I have two questions: I've gone through rkvdec and hantro and can hardly find such values being written directly into the hardware. Can you provide an example? (V4L2_VP9_SEG_LVL_ALT_Q IMO is _not_ written directly to the hardware). If we identify
<br> values which _are_ written directly to the hardware, what if we end up with an abstraction layer which does nothing but a 1:1 translation?
ezequielg: <u>andrzej_p</u>: in drivers/staging/media/hantro/hantro_g2_vp9_dec.c
andrzej_p: ezequielg introducing an abstraction layer makes sense to me for example with hantro_interp_filter_from_v4l2() which _is not_ a 1:1 translation
ezequielg: check update_feat_and_flag
<br> ah, so it's not passed to hw, is it?
<br> but used as index in the driver array.
andrzej_p: <u>ezequielg</u>: and?
ezequielg: well, if it's not passed to hw, i was wrong. so all good.
<br> so my next question is why (from the API pov) is v4l2_vp9_segment_feature not a bitmap.
<br> i mean, does that make sense?
<br> <u>andrzej_p</u>: to make my question more clear...
<br> in struct v4l2_vp9_segmentation, there's a field called feature_enabled.
<br> what is that supposed to contain?
<br> i can't see it documented.
<br> documenting this is probably the answer to figure out how v4l2_vp9_segment_feature should look like from an API standpoint.
***: wwilly has joined #linux-media
andrzej_p: There's doc comment in include/uapi/linux/v4l2-controls.h
<br> \@feature_enabled: bitmask defining which features are enabled in each segment
ezequielg: well, but it's not really clear i think.
<br> i can only assume that feature_enabled is a bitmask of 1 << (v4l2_vp9_segment_feature) ?
<br> for instance, v4l2_ctrl_vp9_frame.reference_mode is documented as "See &v4l2_vp9_reference_mode for more details". Which is a bit better, but should probably be more clear.
<br> see struct v4l2_h264_reference docs for instance, which are trying to be more clear.
<br> <u>andrzej_p</u>: another example, see struct v4l2_pix_format_mplane docs./
***: camus has joined #linux-media
ezequielg: <u>hverkuil</u>: ping
andrzej_p: <u>ezequielg</u>: interestingly enough, @field: enum v4l2_field; field order (for interlaced video)
ezequielg: exactly.
andrzej_p: and several other _enum_ fields
ezequielg: and the doc is clear about what that field should be.
andrzej_p: <u>ezequielg</u>: so is your concern that v4l2_vp9_segment_feature should be a bitmap or that the way how to use it is documented in an unsatisfactory manner?
hverkuil: <u>ezequielg</u>: pong
ezequielg: i only asked "why it's not a bitmap"
<br> <u>hverkuil</u>: hey there -- would you mind reminding me the rules for staging?
andrzej_p: <u>ezequielg</u>: which to me means you wish it were
ezequielg: <u>andrzej_p</u>: no, it only means "why" :)
hverkuil: <u>ezequielg</u>: you mean what decides whether something goes to staging first, or can go directly to mainline?
ezequielg: no, i mean, what are the requirements for a driver to be accepted in staging.
<br> i mean, in staging/media.
***: camus has quit IRC (Ping timeout: 480 seconds)
<br> camus has joined #linux-media
hverkuil: <u>ezequielg</u>: not a lot: it must compile and it has to have a TODO file. Of course, if it doesn't see progress over time it may be kicked out again.
ezequielg: <u>hverkuil</u>: so for WAVE5's driver that dafna2[m] et al posted, they could just add all the review comments into the TODO, make sure no build warnings, and it's mergeable.
hverkuil: That might well be the case. I haven't looked at it yet, so I might have other concerns esp. since it is not using real silicon yet.
<br> I'm not so sure of the benefits of merging code for non-existent hardware. That might be a bit much, even for staging.
ezequielg: what's the difference between non-existent hardware and hardware that's really hard to impossible to find and test?
<br> because that's my main discomfort with all those MTK drivers. They look kind of cumbersome and I don't see them bringing any benefits.
ndufresne: <u>hverkuil</u>: merging code for non-existing sillicon has been very common in the GPU world, since if you wait for the Sillicon to be released to the public, your HW will likely not be supported by Linux when it get shipped, Intel is a common user of this Rationale
<br> Accidentally, something the Silicon does not make it, and the code is just removed, no one is ever affected
<br> in that case, yes, StarFive / BeagleV is dead, but there was couple of early sample being shipped, we have to investigate mr. Palmer chip, but not I'm not big fan of that company, and we can't do Open Source and have access to their BSP apparently
hverkuil: I know, it doesn't have to be a problem. I really need to read the patches, and understand if HW that will be using it is actually being developed (it's a bit unclear to me)
ndufresne: and for our target, the silicon will be there end of October, but there will be some times before all the rest of the code is there I suppose (we have plenty of time)
hverkuil: <u>ndufresne</u>: 'mr. Palmer chip'?
kbingham: The BeagleV is dead, but that doesn't mean StarFive is ?
<br> Or has someone heard confirmation that Starfive has gone. I had interactions with them /after/ the beagle-v announcment where they said they were still working on v4l2 drivers for their camera ?
<br> (though ... 'them' is a bit inaccurate)
ndufresne: <u>kbingham</u>: I meant the BeagleV sorry
kbingham: https://github.com/starfive-tech/linux/issues/21 suggested that (two weeks ago) there was still progress on the driver development. Of coruse it said "Ready next week" which has been and gone ;-)
ndufresne: for what matters to us, we don't know if StarFive will make another boards with a Wav5 and on, and if they do, it will likely arrive way after we get our target sillicon in hand
kbingham: Is Wave5 related to StarFive?
<br> (is there a connection there that I'm unaware of I mean)
ezequielg: <u>kbingham</u>: StarFive Starlight SoC has Wave5 IP core... but other than that, not sure if there's another link.
kbingham: Oh - and that #21 issues had an update an hour ago ;-)
<br> Ah ok - so StarFive 'used' Wave5 IP blocks in the Beagle-V ... is that a correct summary ?
<br> (or ... perhaps that's 'potentially used' ;D)
mort_: How can I get a driver to tell me what sort of formats it supports? (With media-ctl?)
ndufresne: <u>kbingham</u>: correct, the CODEC on StartFixe BeagleV is a Chips & Media WAV5 chip
<br> which is the successor of CODA
<br> CODA9 that is
mort_: nvm, obviously v4l2-ctl --list-formats. I assumed --all would show the formats
ndufresne: <u>mort_</u>: there is also --list-formats-ext
<br> which gives a tad more info
<br> <u>mort_</u>: code m2m codecs, the reply from this will depend on the format you have on the OUTPUT queue
***: wwilly has quit IRC (Quit: Leaving)
<br> eelstrebor has joined #linux-media
pinchartl: <u>ndufresne</u>: are you aware of the vulkan codec API ? https://www.khronos.org/blog/an-introduction-to-vulkan-video
<br> I wonder if that could be implemented on top of V4L2 APIs, or if it will be tied to DRM/KMS and Mesa
ndufresne: <u>pinchartl</u>: it's a bit like libcamera vs khronos, but after the fact ;-D
<br> just like VAAPI, we have been closer to HW, adding some relatively weird parameters in our CODEC interface
pinchartl: it does fill the space of codecs implemented in the GPU, which are not supported by V4L2 today
ndufresne: sorry, Vulkan is like VAAPI, and may not have some weird parameters we at at the kernel level interface
pinchartl: yes
ndufresne: <u>pinchartl</u>: correct, spinning off a V4L2 from a GPU driver is counter intuitive, as the codecs are driven the same way GPU operation are (some binary bitstream command) and code to craft and manage the "pipe" are in userspace
pinchartl: I wonder if that API could cover DRM and V4L2 codecs alike, offering a single userspace API for all codecs
ndufresne: so in the end, if someone wants this, he'll need a bitstream parser in it's V4L2 Vulkan driver
***: paulk has quit IRC (Ping timeout: 480 seconds)
pinchartl: yes
<br> you mean the userspace part of the driver, right ?
ndufresne: it could, and Vulkan is supposed to offer better mem abstraction and better multi-device support
<br> yes, the userspace part of the driver will need to fill in the gap
<br> Vulkan got no slice mode
<br> which means you don't get enough info from the API to driver Cedrus notably
pinchartl: but you get them from the stream ?
ndufresne: and it does not provide any bit skip values, needed to drive Hantro
<br> yes, from the stream
<br> you only get the image part, for H264/HEVC, the header are stripped off
<br> but I think the structure are complete in this regard
<br> now, it's more complex then using v4l2 or VA, so you really have to be motivated
<br> abstracting through ffmpeg or gstreamer might be easier
pinchartl: I have lots of motivation, but not on the codec side :-)
ndufresne: I think its a good fit for games though
pinchartl: good point
<br> there seems to be a WIP implementation of a gstreamer vk decoder element
ndufresne: correct, it has lying in khronos gitlab for a long time
<br> it's not exactly functional, but it's hard to keep up, working drivers are hard to find
<br> the competing D3D12 support is being merged now
<br> that's much more mature
***: BrianG61UK has quit IRC (Remote host closed the connection)
<br> gouchi has joined #linux-media
<br> gouchi has quit IRC (Remote host closed the connection)
<br> eelstrebor has quit IRC (charon.oftc.net liquid.oftc.net)
<br> andrzej_p has quit IRC (charon.oftc.net liquid.oftc.net)
<br> mmind00 has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dwlsalmeida has quit IRC (charon.oftc.net liquid.oftc.net)
<br> ndufresne has quit IRC (charon.oftc.net liquid.oftc.net)
<br> syoung has quit IRC (charon.oftc.net liquid.oftc.net)
<br> tonitch has quit IRC (charon.oftc.net liquid.oftc.net)
<br> KitsuWhooa has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dv_ has quit IRC (charon.oftc.net liquid.oftc.net)
<br> sigmaris has quit IRC (charon.oftc.net liquid.oftc.net)
<br> gnurou has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dafna2[m] has quit IRC (charon.oftc.net liquid.oftc.net)
<br> pinchartl has quit IRC (charon.oftc.net liquid.oftc.net)
<br> eelstrebor has joined #linux-media
<br> andrzej_p has joined #linux-media
<br> mmind00 has joined #linux-media
<br> dwlsalmeida has joined #linux-media
<br> ndufresne has joined #linux-media
<br> syoung has joined #linux-media
<br> tonitch has joined #linux-media
<br> KitsuWhooa has joined #linux-media
<br> dv_ has joined #linux-media
<br> sigmaris has joined #linux-media
<br> gnurou has joined #linux-media
<br> dafna2[m] has joined #linux-media
<br> pinchartl has joined #linux-media
<br> gnurou has quit IRC (charon.oftc.net liquid.oftc.net)
<br> sigmaris has quit IRC (charon.oftc.net liquid.oftc.net)
<br> tonitch has quit IRC (charon.oftc.net liquid.oftc.net)
<br> andrzej_p has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dafna2[m] has quit IRC (charon.oftc.net liquid.oftc.net)
<br> ndufresne has quit IRC (charon.oftc.net liquid.oftc.net)
<br> eelstrebor has quit IRC (charon.oftc.net liquid.oftc.net)
<br> KitsuWhooa has quit IRC (charon.oftc.net liquid.oftc.net)
<br> syoung has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dv_ has quit IRC (charon.oftc.net liquid.oftc.net)
<br> mmind00 has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dwlsalmeida has quit IRC (charon.oftc.net liquid.oftc.net)
<br> pinchartl has quit IRC (charon.oftc.net liquid.oftc.net)
<br> eelstrebor has joined #linux-media
<br> andrzej_p has joined #linux-media
<br> mmind00 has joined #linux-media
<br> dwlsalmeida has joined #linux-media
<br> ndufresne has joined #linux-media
<br> syoung has joined #linux-media
<br> tonitch has joined #linux-media
<br> KitsuWhooa has joined #linux-media
<br> dv_ has joined #linux-media
<br> sigmaris has joined #linux-media
<br> gnurou has joined #linux-media
<br> dafna2[m] has joined #linux-media
<br> pinchartl has joined #linux-media
<br> gnurou has quit IRC (charon.oftc.net liquid.oftc.net)
<br> sigmaris has quit IRC (charon.oftc.net liquid.oftc.net)
<br> tonitch has quit IRC (charon.oftc.net liquid.oftc.net)
<br> andrzej_p has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dafna2[m] has quit IRC (charon.oftc.net liquid.oftc.net)
<br> ndufresne has quit IRC (charon.oftc.net liquid.oftc.net)
<br> eelstrebor has quit IRC (charon.oftc.net liquid.oftc.net)
<br> KitsuWhooa has quit IRC (charon.oftc.net liquid.oftc.net)
<br> syoung has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dv_ has quit IRC (charon.oftc.net liquid.oftc.net)
<br> mmind00 has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dwlsalmeida has quit IRC (charon.oftc.net liquid.oftc.net)
<br> pinchartl has quit IRC (charon.oftc.net liquid.oftc.net)
<br> eelstrebor has joined #linux-media
<br> andrzej_p has joined #linux-media
<br> mmind00 has joined #linux-media
<br> dwlsalmeida has joined #linux-media
<br> ndufresne has joined #linux-media
<br> syoung has joined #linux-media
<br> tonitch has joined #linux-media
<br> KitsuWhooa has joined #linux-media
<br> dv_ has joined #linux-media
<br> sigmaris has joined #linux-media
<br> gnurou has joined #linux-media
<br> dafna2[m] has joined #linux-media
<br> pinchartl has joined #linux-media
<br> NiksDev has joined #linux-media
<br> paulk has joined #linux-media
<br> jm_h has quit IRC (Remote host closed the connection)
<br> paulk has quit IRC (Ping timeout: 480 seconds)
<br> NiksDev_ has joined #linux-media
<br> NiksDev has quit IRC (Ping timeout: 480 seconds)
<br> dwlsalmeida6 has joined #linux-media
<br> gnurou has quit IRC (charon.oftc.net liquid.oftc.net)
<br> sigmaris has quit IRC (charon.oftc.net liquid.oftc.net)
<br> tonitch has quit IRC (charon.oftc.net liquid.oftc.net)
<br> andrzej_p has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dafna2[m] has quit IRC (charon.oftc.net liquid.oftc.net)
<br> ndufresne has quit IRC (charon.oftc.net liquid.oftc.net)
<br> eelstrebor has quit IRC (charon.oftc.net liquid.oftc.net)
<br> KitsuWhooa has quit IRC (charon.oftc.net liquid.oftc.net)
<br> syoung has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dv_ has quit IRC (charon.oftc.net liquid.oftc.net)
<br> mmind00 has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dwlsalmeida has quit IRC (charon.oftc.net liquid.oftc.net)
<br> pinchartl has quit IRC (charon.oftc.net liquid.oftc.net)
<br> dwlsalmeida6 is now known as dwlsalmeida
<br> ndufresne has joined #linux-media
<br> ndufresne is now known as Guest174
<br> djrscally has quit IRC (Quit: Konversation terminated!)
<br> djrscally has joined #linux-media
<br> djrscally has quit IRC (Read error: Connection reset by peer)
<br> eelstrebor has joined #linux-media
<br> andrzej_p has joined #linux-media
<br> mmind00 has joined #linux-media
<br> syoung has joined #linux-media
<br> tonitch has joined #linux-media
<br> KitsuWhooa has joined #linux-media
<br> dv_ has joined #linux-media
<br> sigmaris has joined #linux-media
<br> gnurou has joined #linux-media
<br> dafna2[m] has joined #linux-media
<br> pinchartl has joined #linux-media