JohnnyonFlame has quit [Read error: Connection reset by peer]
<josch>
vkoskiv: yes we have ffmpeg patches in the reform repo, but currently, building ffmpeg is disabled because of buggy hardware decoding on imx8mq
<josch>
vkoskiv: use "apt-cache policy ffmpeg" to figure out where your ffmpeg binary comes from
<vkoskiv>
Yep, confirmed it's coming from debian unstable
<chewitt>
looks like a need an account on the Gitlab to see what's in the repos :)
<vkoskiv>
I don't see a kernel module named 'hevc' under staging for meson, but an object called 'vdec_hevc.o' does get linked into meson_vdec
<chewitt>
the pi devs have an interest in v4l2_m2m support since it's used on pi 0-4 boards (not pi5)
<chewitt>
and we collaborated a little to ensure the changes they would attempt to upstream also worked on the current staging driver (and also an Exynos chip)
<chewitt>
the initial attempt to start upstreaming hit some friction on the ffmpeg list
<chewitt>
(as things often do)
<vkoskiv>
Interesting, I'll try these changes
<vkoskiv>
Where do those firmware .bin files come from?
<chewitt>
the LE branch has some newer files than are in the upstream linux-firmware repo
<chewitt>
that doesn't necessarily guarantee they are better .. only different
<vkoskiv>
And sorry, noob question, but these .bin files are the amlogic proprietary firmware blobs, right?
<chewitt>
correct
<chewitt>
Amlogic ships a single firmware blob file for Android
<chewitt>
for Linux they were extracted into individual files using a tool
<vkoskiv>
Cool, okay. I think I'm running the g12a chip here (not sure what the difference is between gxbb/gxl/g12a), I think I'll be able to apply these and build another .ko to try out
<vkoskiv>
Thanks for the info!
<chewitt>
a311d is g12b .. which uses the g12a blobs
<vkoskiv>
Ah, got it.
<vkoskiv>
Okay, I need to read up on how this firmware gets packaged/loaded before I go much further
<vkoskiv>
Aha! dmesg says firmware is missing
<chewitt>
drop them in /usr/lib/firmware/meson/vdec
<vkoskiv>
That would probably make the hardware decoder unhappy :D
<chewitt>
indeed !
<vkoskiv>
josch: I'll figure this out and then submit a patch to reform-debian-packages if/when I get it working
<vkoskiv>
Still some weirdness, ffplay uses about twice as much CPU when decoding with vdec, than it does when decoding in software
<f_>
>H264 playback and seeking is solid
<chewitt>
note the distinction between older (gxbb/gxl/gxm) and newer (g12a/b and sm1) devices
<vkoskiv>
Yeah, ffplay pretty consistently uses ~400% cpu with hardware decoding, <200% when sw decoding
<f_>
chewitt: Sure
<vkoskiv>
It does play 1080p@60FPS though
<f_>
>No drivers for in-box DVB tuners
<f_>
ripped off mine lol
<f_>
my box is sitting without the original tuner
<f_>
Considering how it's useless in mainline
<chewitt>
the general advice for someone with an a311d chip would be to ignore the existence of hardware decode drivers
<chewitt>
it should be capable of playing anything software-decoded up to 1080p happily
<vkoskiv>
I'm using h264_v4l2m2m
<vkoskiv>
Yeah, software-decoded 1080p works perfectly fine here, I'm just interested in the reduced CPU load of hardware decode
<f_>
chewitt: didn't you want to plumb SPL into LE images?
<vkoskiv>
Software decoded 1080p@60* works fine, to be clear
<chewitt>
hardware decoding on g12a and up really needs the hevc driver which was started and never completed
<f_>
chewitt: I said that you should expect it to still be a WIP until it lands upstream
<f_>
guess what
<f_>
I don't think I'll be able to finish DRAM init anytime soon
<chewitt>
there's been some work sponsored by lvrp16 to investigate moving the media drivers forwards, but it didn't bear fruit yet
<f_>
lack of gxbb and gxl LPDDR hardware
* f_
checks lafrite specs again
<chewitt>
all gxbb devices I've ever seen were DDR3
<f_>
yet, gxbb BL2 seems to support LPDDR
<chewitt>
theoretical existence and commercial availability are different concepts
<f_>
Have no doubt some gxl devices will probably use LPDDR2 or LPDDR3
<f_>
all gxbb devices seem to be using DDR3 for sure, gxl no real idea
<chewitt>
the first boards I've seen with LPDDR anything were SM1 (VIM3L) with LPDDR4
<f_>
I don't think the patches I'll send will include DDR4 support either, although I do have DDR4 gxl hardware. It will be worked on later.
<chewitt>
the challenge for LE is that we need 'a' method to work everywhere
<f_>
chewitt: but I guess once this lands upstream with all gxbb defconfigs updated depending on dram settings, this should be usable on most gxbb hardware.
<chewitt>
so I can do basic experiments on specific boards but actual use in a distro needs a lot more code support for things
<f_>
Are you manually signing the binaries or using amlogic-boot-fip makefiles to do so?
<chewitt>
I use the boot-fip Makefiles
<f_>
sure
<chewitt>
I guess the Makefiles can be adjusted to use a different flow of course
<f_>
Right now when you build my tree it will also build signed images and put them at the root of the repo
<vkoskiv>
still 400+ % cpu use on the rpi_import_1 branch of rpi-ffmpeg
<chewitt>
"model = "MNT-REFORM2-BPI-CM4";"
<vkoskiv>
I'll profile it a bit to see what it's doing
<chewitt>
^ alsa has a 15 character limit on model name
<chewitt>
anything longer is truncated
<vkoskiv>
josch: ^
<chewitt>
MNT-REFORM2 would be good :)
<vkoskiv>
There are different variants of REFORM2, since the SoM is swappable
<vkoskiv>
But this is good to know - Can this affect hardware decoding? I thought alsa was more of an audio system
<f_>
MNT-REFORM2-G12?
<chewitt>
REFORM2-A311D perhaps
<f_>
MNT-REFORM2-BPI?
<chewitt>
what's the other SoM option?
<f_>
chewitt: i.MX and RPi CM4 IIRC
<josch>
vkoskiv: REFORM2-A311D fits into the 15 char limit and we use a311d to talk about the SoM in other parts
<vkoskiv>
currently on reform2, LS1028A, this A311D and the stock one is i.mx8mq
<josch>
chewitt: also nxp ls1028a
<vkoskiv>
A311D uses the Banana Pi compute module, the adapter board can also take a RCM4
<vkoskiv>
chewitt: I gues I'll try cherry-picking these amlogic commits from your branch, do you think that would make a difference to the CPU use?
<vkoskiv>
seeking did work, but it was a bit weird, perhaps.
<chewitt>
no harm in trying
<chewitt>
the challenge with them is .. with 10-bit or 4k media you'll probably wedge the board
<chewitt>
I also disable the mpeg2 codec as this is used with some dvb streams and the hardware driver is broken
<vkoskiv>
'wedge'?
<chewitt>
the board locks up
<vkoskiv>
Ah, the whole SoC, or just the hardware decoder part?
<chewitt>
hard lockup .. power cycle required
<vkoskiv>
Oof, okay. Well, I'm interested in 1080p and regular 8 bit color
<chewitt>
the challenge is that users turn up with all kinds of weird media .. and expect it to just play
<vkoskiv>
Yeah. I'm more than willing to accept weirdness if it means I get hardware decoding for 1080p
<vkoskiv>
Is hardware encoding realistic now or in the near future on here?
<chewitt>
i'm not aware of anyone working on the driver
<f_>
only if someone starts working on it :)
<chewitt>
and anecdotal comments from others suggest the Amlogic venc isn't so amazing
<chewitt>
i.e. a311d is more than capable of software-encoding at a higher quality than hardware venc would achieve (even if it did exist)
<vkoskiv>
fair enough. I don't think encoding was the bottleneck when I got OBS to work, seemed like sway was doing something weird, it was using more CPU than OBS when capturing the screen
<minute>
vkoskiv: it's because your repo is not public, vs our repo
<vkoskiv>
perf'd to see what is taking up so much CPU when hardware decoding (400+% cpu vs. <200% on sw decode), and perf says #1 is deinterleaveBytes_c at 65%, second is __memcpy_generic at 20%
<vkoskiv>
Third is also __memcpy_generic, but at 2.31%. Assuming that's just on a different codepath? Not sure why it's shown twice
<vkoskiv>
2nd is in red, 3rd in green, whatever that means.
<vkoskiv>
Hm, with swdec, there are no obvious outliers above ~2% overhead
<vkoskiv>
Is this because all I have are mem2mem variants, so it just has to do a lot of copying?
<vkoskiv>
(no idea if mem2mem is bad, or the standard way)
<vkoskiv>
If I try vp9, it seems to start playing, but no window pops up, seems to be stuck at the start there
<vkoskiv>
With the rpi-ffmpeg branch, I seem to get no video with h264, and a failed to open file or configure filtergraph error with vp9
jacobk has quit [Ping timeout: 260 seconds]
mripard has quit [Quit: mripard]
jacobk has joined #linux-amlogic
<vkoskiv>
Haven't tried the kernel patches yet
ldevulder has quit [Read error: Connection reset by peer]