stikonas has quit [Quit: Konversation terminated!]
jakllsch has quit [Ping timeout: 260 seconds]
jakllsch has joined #linux-rockchip
hexdump02 has joined #linux-rockchip
dsimic has quit [Ping timeout: 240 seconds]
naoki has joined #linux-rockchip
dsimic has joined #linux-rockchip
cbeznea has joined #linux-rockchip
_whitelogger has quit [Ping timeout: 256 seconds]
_whitelogger_ has joined #linux-rockchip
cbeznea_ has quit [Remote host closed the connection]
jakllsch has quit [*.net *.split]
f_ has quit [*.net *.split]
norris has quit [*.net *.split]
eballetbo has joined #linux-rockchip
jakllsch has joined #linux-rockchip
norris has joined #linux-rockchip
f_ has joined #linux-rockchip
ldevulder has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-rockchip
franoosh has joined #linux-rockchip
cbeznea has joined #linux-rockchip
stikonas has joined #linux-rockchip
stikonas has quit [Client Quit]
hramrach has joined #linux-rockchip
raster has joined #linux-rockchip
Emantor has quit [*.net *.split]
FergusL has quit [*.net *.split]
mx08 has quit [*.net *.split]
psydroid has quit [*.net *.split]
clarity has quit [*.net *.split]
tortoise has quit [*.net *.split]
leming has quit [*.net *.split]
mx08 has joined #linux-rockchip
Emantor has joined #linux-rockchip
FergusL has joined #linux-rockchip
psydroid has joined #linux-rockchip
clarity has joined #linux-rockchip
tortoise has joined #linux-rockchip
leming has joined #linux-rockchip
<linkmauve>
> 16:43:54 diederik> Playing BBB 1080p in x264 on my 4k TV and I get 930 dropped frames (which I think was almost 0 on my monitor) ...
<linkmauve>
That is using mpv? You could try --vo=dmabuf-wayland, since the default --vo=gpu-next uses the GPU for rendering and filtering and maybe the GPU can’t do all that at 4K resolutions.
<diederik>
Yep, all my tests were with (a patched ffmpeg + patched) mpv
<linkmauve>
Then --vo=dmabuf-wayland on a good compositor (I recommend Weston for testing) will completely bypass the GPU.
<diederik>
But I get those ~930 dropped frames on all devices, thus also on my 1080p monitor where I did 90+% of my tests. And I'm using sway which I assume is a good compositor (too)
<diederik>
I'll try with ``--vo=dmabuf-wayland`` next time (next to ``--hwdec=v4l2request``), but I may have actually already tried that
<diederik>
But my problem is that I've tried various parameters ... without actually understanding them and that made me feel like I was just doing random stuff, which didn't seem useful. I don't actually understand the (full) display pipeline, so I'd then just do random things "I found on the internet"
<linkmauve>
diederik, try asking at #mpv next time, or pinging me, I’ve worked quite a lot in video these past few years.
<diederik>
linkmauve: will keep that in mind/will do. Thanks :)
<linkmauve>
The general goal with video being, since the buffers are huge, to never copy them more than needed.
<linkmauve>
On desktop we have a huge amount of memory bandwidth, and mpv optimizes for desktops by default.
<linkmauve>
But there are many platform where you can’t afford to waste memory bandwidth, either because you don’t have enough, or even just for power efficiency reasons.
<diederik>
hmm ... someone mentioned memory bandwidth/speed before to explain the difference between rk3588 and rk356x (and rk3576)
<diederik>
(really good and impressive on rk3588 (Rock 5B) ... not much improvements on my rk356x devices)
<linkmauve>
On such platforms, you want the decoding/rendering to be as steamlined as possible, basically to send the encoded frame to the decoder, which outputs it to memory in a layout that is scanoutable by the display controller, and then configure said display controller to display it.
<linkmauve>
In Linux, that means using V4L2 to allocate the buffer and export it as a dmabuf, then using the zwp_linux_dmabuf_v1 Wayland protocol to import the dmabuf into a wl_buffer, then in the compositor to use a DRM plane to pass the wl_buffer’s dmabuf to the kernel driver.
<linkmauve>
And the driver then configures the hardware pipeline, from the YUV converter to the scaler to the encoder to the connector, so that the final image looks like what was being decoded.
<linkmauve>
mpv’s still not upstream --hwdec=v4l2request does the V4L2 decoding part, --vo=dmabuf-wayland does the zwp_linux_dmabuf_v1 part, and various compositors are at various support levels for the DRM plane part.
<linkmauve>
I don’t know how to determine whether Sway does it properly or not, in Weston you can see which surfaces are composited with a green tint added with the Super+Shift+Space+s shortcut.
<dsimic>
linkmauve: please, let me ask a stupid question: where's the part that consumes too much memory bandwith in all that?
<diederik>
linkmauve: I don't understand most of what you wrote ...
<dsimic>
(I mean, where's exactly the optimization for "big iron"?)
<dsimic>
FTR, the memory DVFS support in the downstream kernel actually contains various profiles intended for decoding different kinds of video
<linkmauve>
dsimic, any step you don’t do like I mentioned, you risk doing a copy and for 4K buffers it’s up to 26 MiB per frame being copied.
<dsimic>
they're seemingly optimized for the purpose, to consume as little power as possiblee while allowing smooth decoding
<linkmauve>
diederik, oops sorry, I can do it slower, or give you things to read or to watch to explain it better. :s
<dsimic>
linkmauve: ah, I see, so the general goal is to have it all processed and displayed (i.e. scanned out) in place
<diederik>
no need to be sorry :) I just don't have an understanding of most of the underlaying tech. So it's for the most part 'black magic' to me
<diederik>
wrt to various parameters, like dmabuf-wayland, I can try it and I may notice some difference, but I don't know what (actually) is different or why. Hence it feels like "just trying random things"
CounterPillow is now known as CountPillow
<linkmauve>
diederik, gpu-next, the default video output (--vo) uses the GPU to convert from a YUV buffer to the final RGB image that can be displayed on the screen.
<linkmauve>
dmabuf-wayland passes the YUV buffer to the Wayland compositor, instructing it to do the same conversion however it wants.
<linkmauve>
This means less work for the video player, which just passes a file descriptor (fd) from one end (V4L2, the decoder) to another end (the Wayland compositor).
<linkmauve>
And the compositor can offload that work to dedicated hardware, instead of doing it in the GPU.
<linkmauve>
Avoiding the GPU is useful because it consumes a lot of power to do its work.
sre58 has joined #linux-rockchip
sre5 has quit [Read error: Connection reset by peer]
sre58 is now known as sre5
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-rockchip
rgolledge has quit [Ping timeout: 245 seconds]
rgolledge has joined #linux-rockchip
godvino has quit [Ping timeout: 245 seconds]
godvino has joined #linux-rockchip
minute has quit [Ping timeout: 245 seconds]
minute has joined #linux-rockchip
beeble has quit [Ping timeout: 256 seconds]
beeble has joined #linux-rockchip
kbingham has quit [Ping timeout: 265 seconds]
kbingham has joined #linux-rockchip
necessarypinch4 has quit [Ping timeout: 256 seconds]
necessarypinch4 has joined #linux-rockchip
rtp has quit [Ping timeout: 265 seconds]
rtp has joined #linux-rockchip
naoki has quit [Quit: naoki]
naoki has joined #linux-rockchip
<diederik>
linkmauve: adding ``--vo=dmabuf-wayland`` had some spectacular results \o/ Virtually no framedrop (only when invoking OSD) and while x265 previously resulted in an all blue output ... that now worked too :-D \o/
<linkmauve>
:)
<linkmauve>
diederik, I assume GNOME’s new video player, Showtime, would also work fine then.
<linkmauve>
diederik, the issue with the OSD might be that your compositor falls back to using the GPU instead of putting the OSD on a different DRM plane.
<linkmauve>
Are you still using Sway?
<diederik>
I 'recently' experienced GNOME for the first time (with PineNote) ... and it's unlikely that I'll use GNOME in the future if I have other options.
<diederik>
Yep, still on Sway
<diederik>
I did the test(s) exactly as I did before
<linkmauve>
Great anyway. :)
<Ermine>
I guess Showtime is basically gstreamer?
<linkmauve>
Yeah.
<walter>
I'm monkeying around with an RK3399 board and I've accidentally flashed an u-boot TPL without RAM params, and it tries to get into MaskROM, but it gets stuck. And the buttons I have on the board are just a power reset and some ADC input. How do I get into MaskROM again? Do I really need to find the eMMC clock?
<ndufresne>
walter: depends on the board, some have bare pads you can short with a tweeze, on the Rengade, they forgot about it, so they give instruction to short the nor flash pins
<qschulz>
walter: you have to short emmc clock or data lanes (and any other boot media such as SPI flashes if flashed)
<ndufresne>
so its just labelled clk + gnd
<walter>
I see. thanks!
jakllsch has quit [Quit: brb]
jakllsch has joined #linux-rockchip
cbeznea has joined #linux-rockchip
godvino has quit [Ping timeout: 260 seconds]
cbeznea has quit [Read error: Connection reset by peer]
sre5 has quit [Ping timeout: 256 seconds]
psydroid2 has joined #linux-rockchip
naoki has quit [Quit: naoki]
ldevulder has quit [Ping timeout: 246 seconds]
Hypfer has quit [Ping timeout: 240 seconds]
Hypfer has joined #linux-rockchip
<walter>
I don't recommend people do this, but I poked around with a wire attatched to ground and a 220Ohm rezistor on the other end, and I've powrecycled the board several times while poking at test points around the eMMC. The 4th or 5th test point caused the board to enter MaskROM. Party!
vagrantc has joined #linux-rockchip
detlevc85 has joined #linux-rockchip
detlevc7 has joined #linux-rockchip
detlevc8 has quit [Read error: Connection reset by peer]
detlevc85 is now known as detlevc8
macromorgan has quit [Quit: No Ping reply in 180 seconds.]
detlevc has quit [Read error: Connection reset by peer]
detlevc7 is now known as detlevc
macromorgan has joined #linux-rockchip
krei-se has joined #linux-rockchip
veremitz- has joined #linux-rockchip
smaeul_ has quit [Read error: Connection reset by peer]
eballetbo has quit [Quit: Connection closed for inactivity]
krei-se- has quit [Write error: error:80000068:system library::Connection reset by peer]
walter has quit [Read error: Connection reset by peer]
veremitz has quit [Read error: Connection reset by peer]