Mangy_Dog has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 480 seconds]
dollroot has joined #linux-sunxi
dollroot_ has joined #linux-sunxi
dollroot_ has quit [Ping timeout: 480 seconds]
dollroot_ has joined #linux-sunxi
jernej has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
dollroot has quit []
dollroot_ has quit []
dollroot has joined #linux-sunxi
dollroot__ has joined #linux-sunxi
dollroot has quit [Ping timeout: 480 seconds]
dollroot has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 480 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
dollroot has quit []
dollroot__ has quit []
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 480 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
gsz has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Fat-Zer has joined #linux-sunxi
<Fat-Zer>
hi, I'm setting up an Orange Pi 3 board (allwinner h6/mali t720/arm64). What software part I should use for hardware video decoding?
<Fat-Zer>
I've stumped upon libva-v4l2-request from sunxi-cedrus, but it looks unmainainde for a while (last commit ~2years ago)... So I'm wondering if there is something newer or the project have been merged to some upstream?
apritzel has joined #linux-sunxi
vpeter has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
john386 has joined #linux-sunxi
john386 has quit []
vpeter has quit [Remote host closed the connection]
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #linux-sunxi
MoeIcenowy has quit []
MoeIcenowy has joined #linux-sunxi
tnovotny has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Ping timeout: 480 seconds]
jaganteki has joined #linux-sunxi
tnovotny_ has joined #linux-sunxi
tnovotny has quit [Remote host closed the connection]
tnovotny has joined #linux-sunxi
tnovotny_ has quit [Ping timeout: 480 seconds]
<Fat-Zer>
maybe there is already some built-in support for v4l2-request api in players?
tnovotny_ has joined #linux-sunxi
tnovotny has quit [Remote host closed the connection]
tnovotny has joined #linux-sunxi
tnovotny_ has quit [Ping timeout: 480 seconds]
zumbi has quit [Ping timeout: 480 seconds]
manu_ has joined #linux-sunxi
manu has quit [Ping timeout: 480 seconds]
choozy has joined #linux-sunxi
BroderTuck has joined #linux-sunxi
<BroderTuck>
Hopefully someone knows, but no answers materialized the last time this was discussed (which started with someone claiming that libva-v4l-request was "deprecated" without giving any explanation about what it was supposed to be replaced with). IF you find enything out, please document it on the wiki.
<BroderTuck>
(And I personally wouldn't accept "Just use LibreElec" as a valid response...)
BroderTuck has quit [Quit: -]
Mangy_Dog has joined #linux-sunxi
<rellla>
BroderTuck: the answer is, checkout libreelec sources :p
<rellla>
use a recent kernel, preferably 5.10.41, which is used by libreelec atm. apply their kernel patches, common ones, allwinner and device specific ones.
<Fat-Zer>
hmm... I've dug a bit into the LiberElec orange pi 3 image and it seems they just didn't bothered with the hardware decoding at all...
<Fat-Zer>
at least there are no signs of the libva or vdpau libs...
<rellla>
then build ffmpeg, i guess uses 4.3.2-Matrix*anything from xbmc ffmpeg github and also apply le's ffmpeg patches. the prime and v4l2request ones. then you are ready to build the app you prefer.
<rellla>
Fat-Zer: neither vaapi nor vdpau is needed or supported with mainline kernel and ffmpeg.
<rellla>
are the hints for ffmpeg. your app has to use ffmpeg or v4l2request directly. no vaapi, no vdpau.
<Fat-Zer>
rellla: yep... looks like that... are those patches are meant to be applied upon upstream ffmpeg?
<rellla>
on the sources i linked. check package.mk code!
<Fat-Zer>
it seems they don't introduce too much: just some tweaking here and there...
<rellla>
the problem is, that v4l2request didn't go into upstream ffmpeg - therefore the patches. and kernel and ffmpeg have to match for the API, so the best is to build it like le does, because they have it working.
<Fat-Zer>
ok...so it's xbmc's ffmpeg..
lurchi__ has joined #linux-sunxi
<rellla>
for ffmpeg it's not just tweaking. its v4l2request itself.
<Fat-Zer>
rellla: yep... you are right... I haven't noticed the generic patches at first...
prefixcactus has quit [Ping timeout: 480 seconds]
<Fat-Zer>
but I still don't see any signs that ffmpeg from "LibreELEC-H6.arm-9.95.4-orangepi-3.img" image was built with them: it doesn't have any related symbols, the config string is different and `strings` don't see any strins that supposed to be introduced by those...
<Fat-Zer>
a bit wierd thing...
<rellla>
you may ping jernej, but i doubt that it's not included, otherwise it won't work as expected and use hw decoding.
<rellla>
*wont use hw decoding
<Fat-Zer>
I might a bit later... although I feel I should test if it's really disabled on a board first...
<Fat-Zer>
so all-in-all, as far as I understand as for now there is an in-kernel v4l2-request API to interact with hardware, and 2 variants to interact with it from user space:
<Fat-Zer>
1) Unmaintained libva-v4l2-request bridge library for all players that support libva.
<Fat-Zer>
2) LibreElec patches for native support in ffmpeg for ffmpeg-derived players (kodi and mpv) .
<Fat-Zer>
right?
<rellla>
yes.
<rellla>
3) an app that directly interacts with kernels v4l2request
<plaes>
4) gstreamer git
<rellla>
you just need to take care, that userspace and kernel api matches
<apritzel>
rellla: so what is plan for the future of sunxi h/w video support? push v4l2request into all clients? Or some other wrapper library?
<rellla>
i don't know...
<rellla>
first goal would imho be to get it into ffmpeg.
<apritzel>
is there other video decoding hardware/SoCs relying of v4l2request?
<apritzel>
or is that just because Allwinner is such a special snowflake?
<apritzel>
but it's in the master branch there, so just waiting for a release?
<plaes>
stateless decoders: hantro, rockchip, cedrus (and even Nvidia tegra)
<plaes>
apritzel: yeah, waiting for the release, unfortunately it didn't make it into 18.x :(
<plaes>
I tried backporting it, but unfortunately changes were a bit too involved..
<apritzel>
so at least that sounds like a plan, moving forward
<apritzel>
I guess the first project merging support helps pushing the other ones
<apritzel>
because while I see the fun in doing Linux hacking the 1990's way (please follow this 5 page tutorial to get the mouse wheel to work on your particular setup), these days people expect it to work with just an apt-get
<Fat-Zer>
plaes: it seems it's in 1.18 according to gitlab tags, isn't it?
prefixcactus has joined #linux-sunxi
<plaes>
Fat-Zer: it's complicated :)
<plaes>
1.18 tree contains unstable stateless ABI
<Fat-Zer>
=)
Fat-Zer has quit [Ping timeout: 480 seconds]
<MoeIcenowy>
apritzel: rk and hantro
<MoeIcenowy>
hantro is IP core, used by rk (for vp9) and imx
<apritzel>
MoeIcenowy: thanks, and yeah, I heard about hantro before
<apritzel>
I am just somewhat puzzled that it doesn't receive more widespread client support then
<MoeIcenowy>
apritzel: considering it has been stable UAPI for only a few days
<apritzel>
is it?
<apritzel>
I thought this was done and dusted months ago already
<MoeIcenowy>
I think it's in uapi in 5.11
<apritzel>
I see, makes sense then
Fat-Zer has joined #linux-sunxi
<plaes>
yeah.. uapi was stabilized in 5.11
choozy has joined #linux-sunxi
BroderTuck has joined #linux-sunxi
<BroderTuck>
iirc, 5.10 (you know, the LTS kernel) seems to be in the worst shape possible for this stuff. Old gstreamer supports kernel 5.9, next 5.11+
<wens>
jernej: H264 in 5.11, VP8 in 5.13, MPEG2 in 5.14 (tentative)
<apritzel>
tuxd3v: what do you mean "you changed the pins"?
<apritzel>
tuxd3v: to be clear: the driver supports PWMs with 2 channels already, it's just that the H3 is wired to only have one channel
<apritzel>
because this is what the manual says
<apritzel>
tuxd3v: but if there is really a second channel, you would just need to change the .data variable to tell the driver about
<apritzel>
tuxd3v: check the BIT_CH() macro, that takes care of adding 15 to the bit number to access the second channel
<apritzel>
and "I can have pwm0 and pwm1 in DT?" scares me a bit, how else did you want to use it?
<vagrantc>
apritzel: i noticed in your one-image-to-rule-them-all talk, the u-boot.itb offsets tends to be much higher with recent u-boot ... sector 16384 typically ... makes the multi-image boot things much easier
<apritzel>
vagrantc: recent U-Boot? I thought this was just some Rockchip blunder?
<apritzel>
and it's just a value set through Kconfig or some headers, right? So changing them is easy?
<vagrantc>
probably
<vagrantc>
but the default recommendation is much higher ... which actually makes it easier to not conflict with allwinner :)
<apritzel>
well, Allwinner also uses also high offsets in their own misguided firmware design
<vagrantc>
yay? :)
<apritzel>
there is just no good reason to do so, and putting the whole firmware below 1MB make it much easier to squeeze in the gap before the first partition of an SD card
<apritzel>
I think the A64 firmware design originally used 19MB or something
<vagrantc>
if you can actually squeeze it in ... some ti platforms that support multiple .dtb files are getting harder to fit below 1MB
<apritzel>
but there is nothing magic about those offsets, and no reason why mainline U-Boot would need to copy the vendor values
<vagrantc>
but that could also be due to the offset at which it starts...
<apritzel>
unless you want to support vendor SPLs/boot0's
<vagrantc>
apritzel: well, i suspect rockchip maintainers in u-boot being actually from rockchip, they aligned them
<apritzel>
(which you might need for some RK SoC/DRAM combinations, IIRC)
* vagrantc
shrugs
<apritzel>
well, I mean there is no reason to leave a multi MB gap, unless you really need it
<vagrantc>
i need to write up this pinebook* image stuff :)
<apritzel>
but as mentioned, those values are compile-time defined, so we can change them anytime, as we ship the dependencies (SPL and U-Boot proper) together
<apritzel>
so if 1MB is getting too small, we just use 2MB
<apritzel>
or a small trampoline somewhere to keep it compatible
<vagrantc>
for debian, i try to minimize deviations from upstream u-boot where possible
<apritzel>
tbh, I still don't understand why $distribution is involved in providing *firmware* for certain *devices*
<vagrantc>
if i get a board without any firmware, i want my distro to be able to provide bootable images
<vagrantc>
also, one bootstrapped trust path to what i run ...
<apritzel>
I understand the practicality of this approach, but this firmware build is not (or should not be) distro specific
<apritzel>
so people in every distro are working on the same thing
<vagrantc>
i do carry some patches to make some boards work with distro_boot and such, where upstream refuses to do so
Daanct12 has joined #linux-sunxi
<apritzel>
"upstream refuses to do so": I'd like to hear about that
<vagrantc>
i even work on it in two distros :)
<apritzel>
in my experience there is mostly a reason for that ...
<vagrantc>
some exynos platforms insist on setting console differently than all the other distros, which ... surprise, breaks
<vagrantc>
er, platforms, not distros
<vagrantc>
actually, that's the only one where i actually ship and/or test it
<vagrantc>
managed to get it merged at some point, and then the exynos maintainers reverted it when it broke their vendor-specific stuff :/
<vagrantc>
the use of console= is pretty inconsistant across all the platforms ... ideally platforms switch to defining that in the .dtb ... but ... history
Danct12 has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
martinayotte has joined #linux-sunxi
swiftgeek has quit [Remote host closed the connection]
<apritzel>
but stdout-path is around for a while, they should have heard about it
<vagrantc>
old platforms tend to not get the best care
libv_ has joined #linux-sunxi
<apritzel>
for a reason, I guess
swiftgeek has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
diego71 has quit [Read error: No route to host]
<tuxd3v>
apritzel because the driver seems hardcoded with the bits that reference pwm for the channel 0 only :(
<tuxd3v>
pwm_sun4i
<tuxd3v>
that's why I changed the bits to use chanel 1:
<apritzel>
interesting, are you sure that's correct?
<tuxd3v>
its the only way I have to get pwm :)
<tuxd3v>
via GPIO
<apritzel>
I have v1.1 of the datasheet, from Jan. 26 2015, and it only mentions one channel and no PWM on PA6
<apritzel>
so did you somehow try that this actually works?
<apritzel>
or are you just relying on the info from that datasheet?
<tuxd3v>
because acordingly with the manual pwm0 is on port PA5, which is a alternate for uart3, and I also have uart3 on gpio, so it can't be cannhel 0, it needs to be channel 1
<tuxd3v>
I am on bananapi m2 zero now :)
<apritzel>
huh?
<tuxd3v>
I am relying on the info from the datasheet
<apritzel>
the muxes are set by Allwinner, and the board vendor decides which to use
<apritzel>
there is no guarantee that all peripherals are accessible
<tuxd3v>
yes but bananapi m2 zero used pwm1
<apritzel>
indeed, just saw this
<apritzel>
but your rationale was very confusing
<apritzel>
wouldn't be the first vendor that made a poor choice for muxed pins
<apritzel>
the v1.2 H2+ datasheet from 2016 also doesn't mention PWM1
<apritzel>
but by all means, please try it!
<apritzel>
my OrangePi Zero (also H2+) seems to do the same: PA6 is called PWM1 and connected to a header
<apritzel>
interestingly the power LED is PL10, which is S_PWM, so one should be able to actually control the brightness of that ...
<tuxd3v>
apritzel, exactly the same situation as with Bananapi m2 zero
<tuxd3v>
which is S_PWM
<tuxd3v>
pl10
<tuxd3v>
apritzel, ho, and if you change the led trigger to cpu it will start to trimm, now it seems that it indeed is using r_pwm: pwm@1f03800