| mntmn | Asmadeus: i wonder how the AVHWAccel is supposed to be picked up | 00:00 |
|---|---|---|
| mntmn | mhm configure:HWACCEL_LIST=$(find_things_extern hwaccel AVHWAccel libavcodec/hwaccels.h) | 00:02 |
| mntmn | oops | 00:04 |
| mntmn | ahh it is featured in h264dec.c | 00:37 |
| mntmn | #if CONFIG_H264_V4L2REQUEST_HWACCEL | 00:37 |
| mntmn | HWACCEL_V4L2REQUEST(h264), | 00:37 |
| mntmn | ok, poked enough in this for today, no success | 00:49 |
| mntmn | it feels like there is no real/obvious path in ffmpeg (the tool) to get this decoder to get picked up by anything | 01:14 |
| mntmn | the h264 AVCodec has a .hw_configs field which is a list of AVCodecHWConfigInternal... but i don't even understand who is evaluating this list | 01:16 |
| mntmn | i've put a breakpoint in avcodec_default_get_format() in decode.c. it gets hit. avctx->hw_device_ctx is 0x0 | 01:21 |
| mntmn | it checks a pixel format (of the input?), it is yuv420p. it does not have the AV_PIX_FMT_FLAG_HWACCEL flag. | 01:22 |
| _Bnu | Weird, that's typically the only one that has the hardware acceleration support. | 01:41 |
| _Bnu | (Since all YouTube videos/streams/etc are 4:2:0.) | 01:42 |
| mntmn | makes sense | 01:46 |
| _Bnu | Well, and DVDs and blu-rays and snake video and all that... | 01:55 |
| mntmn | anyway there's something fundamental i'm missing here | 02:01 |
| - wiedi (QUIT: Read error: Connection reset by peer) (~wiedi@2a01:138:a015:15:3971:d225:f6e0:f8e) | 03:58 | |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.30) | 04:16 | |
| + freakazoid333 (~freakazoi@72.168.176.30) | 04:17 | |
| + wiedi (~wiedi@2a01:138:a015:15:30a8:5aa8:ce44:3085) | 08:10 | |
| + odnes (~odnes@109-178-154-27.pat.ren.cosmote.net) | 08:27 | |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.30) | 09:07 | |
| + freakazoid333 (~freakazoi@72.168.176.34) | 09:08 | |
| - artfwo (QUIT: Ping timeout: 272 seconds) (~artfwo@2a02:8109:8500:26d0:fd06:e800:101b:2f14) | 09:24 | |
| + artfwo (~artfwo@2a02:8109:8500:26d0:ad5e:7dd5:ea9:c904) | 09:36 | |
| - S0rin (QUIT: Ping timeout: 268 seconds) (~S0rin@user/s0rin) | 10:12 | |
| + S0rin (~S0rin@user/s0rin) | 10:13 | |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.34) | 11:06 | |
| + freakazoid333 (~freakazoi@72.168.176.34) | 11:06 | |
| - odnes (QUIT: Remote host closed the connection) (~odnes@109-178-154-27.pat.ren.cosmote.net) | 11:36 | |
| + odnes (~odnes@109-178-154-27.pat.ren.cosmote.net) | 11:36 | |
| mntmn | > If a decoder supports hwaccel, then it must call ff_get_format(). | 14:11 |
| mntmn | in pthread_frame.c | 14:11 |
| mntmn | h264 does not do this | 14:12 |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.34) | 14:16 | |
| + freakazoid333 (~freakazoi@72.168.176.34) | 14:17 | |
| + rasmus (~rasmus@c83-253-223-217.bredband.tele2.se) | 14:19 | |
| - rasmus (PART: Disconnected: closed) (~rasmus@c83-253-223-217.bredband.tele2.se) | 14:36 | |
| _Bnu | That's fine... no one needs it... | 14:39 |
| - odnes (QUIT: Ping timeout: 268 seconds) (~odnes@109-178-154-27.pat.ren.cosmote.net) | 14:52 | |
| + odnes (~odnes@109-178-154-27.pat.ren.cosmote.net) | 15:00 | |
| mntmn | mhm so the magic has to happen in h264_slice.c get_pixel_format(H264Context *h, int force_callback) perhaps | 15:04 |
| mntmn | ah and this also calls ff_thread_get_format() -> ff_get_format() in the end | 15:06 |
| mntmn | oops, #if CONFIG_H264_V4L2REQUEST_HWACCEL branch is not hit | 15:12 |
| mntmn | but: configuration: --enable-v4l2-request --enable-libdrm --enable-libudev --enable-shared | 15:12 |
| mntmn | huh config.h:#define CONFIG_H264_V4L2REQUEST_HWACCEL 0 | 15:13 |
| mntmn | i guess the configuration line is incomplete | 15:15 |
| mntmn | what's missing is --enable-hwaccel=h264_v4l2request | 15:17 |
| mntmn | >:O | 15:18 |
| mntmn | love how grumpy this post is https://forum.pine64.org/showthread.php?tid=14018 | 15:39 |
| - erlehmann (QUIT: Quit: Just say no, then the virus can not enter your body without your consent.) (~erle@dynamic-046-114-039-105.46.114.pool.telefonica.de) | 15:40 | |
| + erlehmann (~erle@dynamic-046-114-039-105.46.114.pool.telefonica.de) | 15:40 | |
| mntmn | lol > WARNING: Disabled h264_v4l2request_hwaccel because not all dependencies are satisfied: v4l2_request h264_v4l2_request | 15:40 |
| mntmn | wat > configure:check_cc h264_v4l2_request linux/videodev2.h "int i = V4L2_PIX_FMT_H264_SLICE;" | 15:42 |
| mntmn | ah this needs some linux kernel header patch | 15:43 |
| mntmn | > #define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* H264 parsed slices */ | 15:45 |
| mntmn | slices sound tasty | 15:46 |
| _Bnu | 8D | 15:59 |
| _Bnu | Yes, I love when they break V4L in every single kernel... | 15:59 |
| mntmn | fourcc factory goes brrrr | 16:00 |
| mntmn | yeah so it needs up-to-date v4l2-controls.h and videodev2.h from linux uapi headers | 16:11 |
| mntmn | also, there are too many codecs in the world | 16:15 |
| mntmn | ok progress: > [h264 @ 0x5590310b40] v4l2_request_probe_media_device: opening /dev/media0 failed, Permission denied (13) | 16:19 |
| mntmn | ok it works! | 16:20 |
| mntmn | > 58: 445 0 0 0 GPCv2 7 Level 38300000.video-codec | 16:24 |
| _Bnu | ownloading... | 16:29 |
| mntmn | ok so mpv can do it! | 16:41 |
| mntmn | > ./mpv --hwdec-codecs=all --hwdec=auto --vo=gpu ~/Videos/lumixtest1.mp4 -v | 16:41 |
| mntmn | (had to build mpv from source to pick up the custom libavcodec.so and friends in /usr/local/lib) | 16:41 |
| mntmn | cool, can watch movies with almost no CPU use like this | 16:43 |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.34) | 16:58 | |
| + freakazoid333 (~freakazoi@72.168.176.34) | 16:58 | |
| mntmn | ok here are my notes on getting H.264 HW decode to run, based on Asmadeus' work of updating the patchset: https://community.mnt.re/t/notes-on-building-ffmpeg-and-mpv-to-use-the-hardware-h-264-decoder/305 | 17:04 |
| _Bnu | Now we can finally watch 4k YouTube videos using StreamLink... except YouTube limits StreamLink to 720p, haha. | 17:06 |
| mntmn | hue hue | 17:07 |
| mntmn | well, having almost no CPU usage with 720p is also neat | 17:07 |
| mntmn | also, the cpu was sometimes struggling with 1080p, but i don't have many 1080p videos to test, i mostly... use... 720p videos | 17:08 |
| mntmn | _Bnu: can mpv directly play back youtubes? | 17:08 |
| _Bnu | If you set it as the player in StreamLink, yeah. | 17:09 |
| mntmn | ah oh | 17:09 |
| _Bnu | Can also open twitch.tv links and most other streaming services that don't block it. | 17:09 |
| mntmn | lets give this a spin | 17:10 |
| ezequielg | mntmn: so so glad to read your notes. | 17:14 |
| ezequielg | from 9 to 10 how painful was that :P | 17:14 |
| mntmn | ezequielg: haha yes :D | 17:15 |
| ezequielg | (also: hevc and vp9 is just around the corner) | 17:15 |
| _Bnu | HEVC is never around the corner due to licensing issues. | 17:16 |
| _Bnu | Unless you count select commercial streaming services. | 17:16 |
| mntmn | ezequielg: it was a good level of pain, but not the highest | 17:16 |
| ezequielg | the header stuff is due to ffmpeg not shipping its own private copy of headers. i.e. https://kernelnewbies.org/KernelHeaders | 17:16 |
| mntmn | yeah >:| | 17:16 |
| mntmn | > error: This plugin does not support protected videos, try youtube-dl instead | 17:16 |
| mntmn | hehe | 17:16 |
| ezequielg | _Bnu: what's the difference between hevc and h264 wrt to licensing issues? | 17:17 |
| ezequielg | (100% curiosity) | 17:18 |
| _Bnu | HEVC is H.265, not H.264. | 17:18 |
| mntmn | hmm | 17:19 |
| mntmn | mntmn@reform:~/src$ ~/.local/bin/streamlink --subprocess-cmdline 'https://www.youtube.com/watch?v=1zZaRH00Q54' 1080p | 17:19 |
| mntmn | error: The stream specified cannot be translated to a command | 17:19 |
| mntmn | _Bnu: i think the question was about, what's the licensing difference between the 2 | 17:19 |
| _Bnu | The difference is that you need a paid license to broadcast H.265 to anyone. | 17:20 |
| _Bnu | It can never be used for anything, pretty much. Except for staring at your own local recording or something. | 17:20 |
| ezequielg | the thing I really haven't yet figured out is why I have customer that insist in HEVC, instead of going VP9. | 17:20 |
| mntmn | ah hm it uses vlc | 17:20 |
| ezequielg | unless you tell me hevc really beats the shit out of vp9. | 17:21 |
| _Bnu | HEVC more commonly has a hardware decoder and better quality at the same bit rate, but if this is due to the maturity of the encoders or not is unclear. | 17:21 |
| ezequielg | fwiw, I don't judge people/companies preferences, I just support whatever they want :) | 17:21 |
| _Bnu | Yeah I mean they might have a paid license for H.265. | 17:22 |
| ezequielg | well, on the reform you have: mpeg-2, h264 and vp8 through the g1 block, and hevc and vp9 through the g2 block. (i.e. everything except av1?) | 17:22 |
| _Bnu | But basically for it to be used on something like Twitch, each individual person streaming would need to have a license, as would Twitch. | 17:22 |
| _Bnu | They just really didn't want people to use it for anything fun, I guess. | 17:23 |
| mntmn | ok i guess i need to wrap "mpv --hwdec=auto" in a script, or does it have a config file... | 17:23 |
| mntmn | has a config file. | 17:24 |
| ezequielg | is that really needed? | 17:24 |
| ezequielg | mntmn: btw, thanks a lot for putting that together. | 17:25 |
| mntmn | ezequielg: yes, by default mpv does not use hwdec | 17:25 |
| ezequielg | if get any bug reports, please point people towards the linux-media ML, we are happy to support everyone. | 17:25 |
| mntmn | ezequielg: because they argue that software decoding is better quality | 17:25 |
| ezequielg | O_o ok.. | 17:26 |
| _Bnu | It's true, to some degree. Because hardware decoders often ignore video stream metadata. | 17:26 |
| mntmn | so what works: putting a line hwdec=auto in ~/.config/mpv/mpv.conf | 17:26 |
| mntmn | works with streamlink now! | 17:26 |
| _Bnu | So you have to match what they expect, typically limited range BC709. | 17:26 |
| _Bnu | *BT | 17:26 |
| mntmn | ~/.local/bin/streamlink --player=mpv 'https://www.youtube.com/watch?v=1zZaRH00Q54' 1080p | 17:27 |
| mntmn | works! | 17:27 |
| _Bnu | :3 | 17:27 |
| mntmn | uses very little cpu | 17:27 |
| _Bnu | Now I can watch 1080p Twitch all day while keeping the Reform cooler... | 17:27 |
| ezequielg | fwiw, the hardware decoder on the reform (hantro) is ran against a conformance test suite, although not on a CI yet. Doesn't this mean it should produce the same results as software decoding? At least for the cases where the test vectors are passing. | 17:28 |
| _Bnu | Or maybe watch 1080p Twitch on one screen while I play Nibb... code on the other one... | 17:28 |
| ezequielg | mpv should try hwdec, and fallback to swdec if it fails. I guess. | 17:28 |
| ezequielg | should/could. | 17:28 |
| _Bnu | From what I recall, they're really against that. | 17:29 |
| ezequielg | as there are some features that the hw decoder doesn't support. | 17:29 |
| ezequielg | thinking some more, makes sense to default to swdec. | 17:29 |
| _Bnu | Because with hwdev they can't choose the chroma offset point for decoding, color space, color range, things like that. | 17:29 |
| ezequielg | yeah. | 17:29 |
| _Bnu | *hwdec | 17:29 |
| ezequielg | after all, my dell laptop still crashes on some va-api so... :) | 17:29 |
| mntmn | ezequielg: there are some bugs in hw decoders | 17:30 |
| mntmn | ezequielg: that's why they don't wanna rely on it | 17:30 |
| ezequielg | yeah, makes total sense. | 17:30 |
| mntmn | ok so 1080p via streamlink->mpv is crisp. framerate is a bit low but i think it is this video... need something that has higher fps perhaps | 17:31 |
| ezequielg | https://www.youtube.com/watch?v=zj7lpntqVj8 ? | 17:33 |
| ezequielg | also, https://kodi.wiki/view/Samples | 17:33 |
| mntmn | i tried this ~/.local/bin/streamlink --player=mpv 'https://www.youtube.com/watch?v=3NzKWPBEYBo' 1080p60 | 17:34 |
| mntmn | but audio/video desyncs | 17:34 |
| mntmn | it can't decode fast enough _or_ render the frames out fast enough | 17:34 |
| ezequielg | also https://jell.yfish.us/ | 17:34 |
| mntmn | ah, good to have some test clips, thanks | 17:35 |
| ezequielg | I wonder what's the limit on the MX8MQ. | 17:36 |
| mntmn | yeah for example, jellyfish-20-mbps-hd-h264.mkv looks really crisp but drops a lot of frames | 17:36 |
| ezequielg | not good. | 17:37 |
| mntmn | maybe it's because of the blitting (i guess it's not zero copy) | 17:37 |
| ezequielg | should be zero-copy by all means. | 17:37 |
| mntmn | Using hardware decoding (drm-copy). | 17:37 |
| mntmn | VO: [gpu] 1920x1080 nv12 | 17:37 |
| ezequielg | what do you run as gfx? | 17:38 |
| mntmn | what do you mean gfx? | 17:38 |
| mntmn | i'm using sway (wayland compositor, based on wlroots) | 17:39 |
| _Bnu | Weird, doesn't it support NV12/YV420 textures? | 17:39 |
| mntmn | also tried mpv --gpu-context=wayland jellyfish-20-mbps-hd-h264.mkv | 17:39 |
| ezequielg | right, so there are a few things to blame. | 17:40 |
| ezequielg | maybe something like perf top can give some insight? | 17:40 |
| mntmn | what's that? | 17:41 |
| ezequielg | just a profiling tool | 17:41 |
| mntmn | btw 720p60 is fine | 17:42 |
| mntmn | wait, this uses software decode lol | 17:42 |
| ezequielg | fwiw, "drm-copy" looks like there's a copy? | 17:44 |
| _Bnu | 1080p60 is typically fine for me in software on VLC, as long as I go fullscreen. Windowed is like total no-go, haha. | 17:44 |
| mntmn | ezequielg: i thought so too, but i know nothing about mpv internals | 17:46 |
| ezequielg | would be interesting to test weston and sway. | 17:46 |
| ezequielg | mntmn: there should be an option to list the hwaccels, in mpv? (maybe not) | 17:47 |
| ezequielg | also, just fyi: decoding playback can be full-zero copy, without even touching the gpu. this can be achieved if the display controller supports the pixel format (i.e. NV12), and with support from the compositor. the compositor should just "route" the client to the overlay NV12 plane. I'd say that works provided the other planes are occluded (i.e. in fullscreen only). | 17:48 |
| ezequielg | weston does it, dunno about sway. | 17:49 |
| mntmn | ah, planes | 17:51 |
| ezequielg | your notes could be a good starting point, in any case, for further digging :) | 17:51 |
| + ZylonMaster (~dldske@2603-7000-c601-f02e-0000-0000-0000-0353.res6.spectrum.com) | 17:55 | |
| ZylonMaster | hmm quiet chat room | 17:57 |
| mntmn | ZylonMaster: you are just 30 minutes late... | 18:02 |
| ZylonMaster | oh? | 18:03 |
| ZylonMaster | what do you mean? | 18:03 |
| mntmn | ZylonMaster: 30 minutes ago, it was not quiet! | 18:03 |
| ZylonMaster | ah k | 18:03 |
| mntmn | ezequielg: ok so i don't think mpv uses planes, and instead the decoded output is copied to a texture and this is then displayed using opengl. | 18:03 |
| ZylonMaster | curious, but hows the pocket mnt reform development | 18:03 |
| ZylonMaster | going | 18:03 |
| ZylonMaster | ? | 18:03 |
| ZylonMaster | it looks awesome | 18:03 |
| mntmn | ZylonMaster: thanks, it is still in the user research phase. we're figuring out sizes and keyboard arrangements, pointing device | 18:04 |
| ZylonMaster | do you have any estimate as to the price? | 18:04 |
| ZylonMaster | i assume no right? | 18:04 |
| ZylonMaster | you guys work early btw it seems | 18:05 |
| ZylonMaster | :) | 18:05 |
| mntmn | i do not | 18:05 |
| mntmn | early? | 18:05 |
| ZylonMaster | k | 18:05 |
| ZylonMaster | yeah | 18:05 |
| ZylonMaster | at least in my mind its 11:30am here | 18:05 |
| ZylonMaster | well 12pm | 18:05 |
| ZylonMaster | actually | 18:05 |
| ZylonMaster | 11:30 wouldve been how early id need to be here for it to be busy | 18:06 |
| mntmn | it's saturday so i don't really work officially, and it's 18h here | 18:06 |
| ZylonMaster | oh | 18:06 |
| ZylonMaster | k | 18:06 |
| ZylonMaster | Its a shame FSF wont promote your product yet will promote anything from purism | 18:06 |
| ZylonMaster | im losing hope in them to be honest | 18:06 |
| ZylonMaster | well not anything | 18:06 |
| ZylonMaster | but you know what i mean | 18:06 |
| ZylonMaster | lol | 18:06 |
| ZylonMaster | :/ | 18:07 |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.34) | 18:07 | |
| ZylonMaster | sometime down the road do you think there will be an instruction set, for brightness control on the bios level? | 18:07 |
| ZylonMaster | or should I ask other users | 18:08 |
| ZylonMaster | or idk | 18:08 |
| ZylonMaster | ? | 18:08 |
| + freakazoid333 (~freakazoi@72.168.176.34) | 18:08 | |
| ZylonMaster | battery life is important aka | 18:08 |
| ZylonMaster | :) | 18:08 |
| mntmn | ZylonMaster: i'm not really a fan of FSF and don't care about RYF | 18:08 |
| ZylonMaster | ahh | 18:09 |
| ZylonMaster | good call | 18:09 |
| ZylonMaster | they are making themselves look bad | 18:09 |
| mntmn | ZylonMaster: there is no bios on ARM systems. | 18:09 |
| ZylonMaster | right now | 18:09 |
| ZylonMaster | oh | 18:09 |
| ZylonMaster | what is it then | 18:09 |
| ZylonMaster | i guess | 18:09 |
| ZylonMaster | ? | 18:09 |
| ZylonMaster | u boot? | 18:09 |
| mntmn | ZylonMaster: yeah, u-boot or barebox for example | 18:09 |
| ZylonMaster | i must have gotten confused | 18:09 |
| ZylonMaster | k | 18:09 |
| ZylonMaster | I just would love to squeeze out more battery life with arm systems, 24 hours if possible | 18:09 |
| ZylonMaster | :) | 18:09 |
| mntmn | ZylonMaster: well, go ahead | 18:10 |
| ZylonMaster | indeed | 18:10 |
| ezequielg | ZylonMaster: the world is round and time goes back and forth. It's 1pm here, I'm in the future. | 18:10 |
| ZylonMaster | how big is that pocket reform anyways | 18:10 |
| ezequielg | or the past? | 18:10 |
| mntmn | the brightness is controlled by a PWM output on the system-on-chip (in this case, i.MX8MQ) | 18:10 |
| ZylonMaster | 4.5 inches? | 18:10 |
| ZylonMaster | ah | 18:10 |
| mntmn | ZylonMaster: the display is 5.5 inch currently | 18:10 |
| ZylonMaster | cool | 18:10 |
| ZylonMaster | 5.5 | 18:10 |
| ZylonMaster | is nice | 18:10 |
| mntmn | but we might still change it. | 18:10 |
| ZylonMaster | oh | 18:11 |
| ZylonMaster | too big or too small? | 18:11 |
| mntmn | that's why we're doing user research | 18:11 |
| ZylonMaster | smaller might be good imo | 18:11 |
| mntmn | we're giving it to people to test and write down what they're experiencing | 18:11 |
| ZylonMaster | 5 inches is good enough | 18:11 |
| ZylonMaster | for me anyways | 18:11 |
| ZylonMaster | heh | 18:11 |
| ZylonMaster | You know who also btw doesnt think much of FSF in its current state now? | 18:12 |
| ZylonMaster | hyperbola | 18:12 |
| ZylonMaster | good minds think alike eh | 18:12 |
| ZylonMaster | anywho, you are not at beta testing yet are you? | 18:12 |
| ZylonMaster | for mnt reform pocket? | 18:12 |
| mntmn | no. | 18:13 |
| ZylonMaster | ah | 18:13 |
| ZylonMaster | just checking | 18:13 |
| mntmn | also, i don't want to go into any politics around FSF etc here. this channel is mainly about discussing problems/experiences with MNT Reform. | 18:13 |
| ZylonMaster | how much battery life do you think you can get out if it with the usual settings btw | 18:13 |
| ZylonMaster | sorry | 18:13 |
| ZylonMaster | i didnt know | 18:13 |
| ZylonMaster | my bad | 18:14 |
| ZylonMaster | ill say nothing more on fsf if you want | 18:14 |
| mntmn | no problem, i just wanted to clarify it. i also can't really discuss a lot about the pocket device yet because there is too much change happening still. | 18:14 |
| ZylonMaster | yeah | 18:14 |
| ZylonMaster | sorry, about that too, I can be impatient | 18:14 |
| ZylonMaster | lol | 18:14 |
| ZylonMaster | it looks like something I will want | 18:14 |
| mntmn | yeah, we will still take a long time to develop it. no rush | 18:15 |
| ZylonMaster | like a year or two? | 18:15 |
| mntmn | yeah, maybe a year | 18:15 |
| ZylonMaster | k | 18:15 |
| ZylonMaster | good to know | 18:15 |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.34) | 18:15 | |
| ZylonMaster | That's fine with me | 18:15 |
| mntmn | currently i have to focus on MNT Reform shipping and bugfixing | 18:15 |
| ZylonMaster | sort of | 18:15 |
| ZylonMaster | k | 18:15 |
| + freakazoid333 (~freakazoi@72.168.176.34) | 18:15 | |
| ZylonMaster | good things require time | 18:15 |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.34) | 18:16 | |
| + freakazoid333 (~freakazoi@72.168.176.34) | 18:16 | |
| ZylonMaster | if you do that device right, I bet I won't need to squeeze to get 12 hours of battery life out of it even while its running with screen on. screen size is like 2x smaller anyways | 18:17 |
| ZylonMaster | anywho, Ill stop talking now if you like | 18:17 |
| ZylonMaster | my curiosity is very high | 18:17 |
| ZylonMaster | on this | 18:17 |
| - ZylonMaster (QUIT: Read error: Connection reset by peer) (~dldske@2603-7000-c601-f02e-0000-0000-0000-0353.res6.spectrum.com) | 18:20 | |
| + kdhsk (~dldske@2603-7000-c601-f02e-0000-0000-0000-0353.res6.spectrum.com) | 18:20 | |
| * kdhsk -> ZylonMaster | 18:20 | |
| - ZylonMaster (QUIT: Client Quit) (~dldske@2603-7000-c601-f02e-0000-0000-0000-0353.res6.spectrum.com) | 18:23 | |
| - Neelfyn (QUIT: Quit: Connection closed for inactivity) (uid180106@id-180106.stonehaven.irccloud.com) | 18:32 | |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.34) | 18:42 | |
| + freakazoid333 (~freakazoi@72.168.176.34) | 18:42 | |
| - odnes (QUIT: Ping timeout: 258 seconds) (~odnes@109-178-154-27.pat.ren.cosmote.net) | 18:47 | |
| marex | mntmn: hey, I recall you had problems with mxsfb, right ? | 19:39 |
| mntmn | marex: well, depends | 19:47 |
| mntmn | marex: i had a bus contention problem with lcdif | 19:48 |
| marex | mntmn: seems there is more to that | 19:48 |
| marex | mntmn: did you ever see image corruption on that lcdif ? | 19:48 |
| marex | (due to that contention) | 19:48 |
| mntmn | marex: i think only temporary, dropouts, like pixel feed couldn't keep up | 19:49 |
| marex | mntmn: do you still have it ? | 19:49 |
| mntmn | marex: also i had lcdif and nwl-dsi get out of sync | 19:49 |
| mntmn | marex: no, i fixed it with magic secret pokes | 19:49 |
| marex | NOC QoS, right ? | 19:49 |
| mntmn | marex: "advanced QoS" registers or something, the top level noc lumps lcdif and pcie into "other" masters | 19:50 |
| mntmn | for example if cpu, gpu, vpu or something is starving your lcdif, you can probably fix that in NoC | 19:51 |
| mntmn | but not pcie | 19:51 |
| marex | mntmn: I think there is more to it than just the NOC | 19:52 |
| marex | mntmn: I have a few lcdif patches already, but I didnt find the root cause yet | 19:53 |
| mntmn | marex: i guess you are not on imx8mq? or are you? | 19:53 |
| mntmn | marex: also, interested in what you are patching and why | 19:53 |
| mntmn | btw i'm still amazed how fast and stable chromium 93 is with ANGLE... there are like zero glitches | 19:57 |
| marex | mntmn: 8mm , the lcdif IP is the same, I'm seeing the image on the display shifted to the right and wrapped around | 19:58 |
| marex | mntmn: apparently that also happened on mx6sx | 19:58 |
| mntmn | marex: ah, i had this problem too and very rarely get it now | 19:59 |
| marex | (thats why I think there is more to it than just NOC) | 19:59 |
| mntmn | marex: yes | 19:59 |
| marex | mntmn: excellent | 19:59 |
| mntmn | marex: i have seen it under very heavy bus load maybe... | 19:59 |
| marex | mntmn: yep | 20:00 |
| mntmn | marex: what have you found out? i know agx (guido from purism) also did 1 hack/fix for this, but i think it was not conclusive... had to do something with reset | 20:00 |
| marex | mntmn: there is recover_on_underflow bit in ctrl1 and outstanding_reqs field in ctrl2 register, but neither really helps to recover from it fully | 20:00 |
| mntmn | ah | 20:00 |
| marex | mntmn: also, there is no underflow IRQ, which is real weird | 20:00 |
| mntmn | yes i remember from my experiments | 20:01 |
| marex | I mean, I have those enabled, but they dont fire , nor is the IRQ bit set, which is odd | 20:01 |
| mntmn | with driving lcdif directly | 20:01 |
| marex | ;-) | 20:01 |
| mntmn | yeah, i think the irq just goes nowhere | 20:01 |
| mntmn | it's kind of not implemented | 20:01 |
| mntmn | maybe it was used by the older socs | 20:01 |
| mntmn | you can poll for the status though, in my experience it does complain about underflow. silently | 20:02 |
| mntmn | maybe you can reset it on underflow? like poll every few seconds or so | 20:02 |
| marex | mntmn: what is not implemented ? | 20:02 |
| mntmn | the irq line | 20:02 |
| marex | mntmn: from the lcdif to the soc irq controller or inside the lcdif ? | 20:03 |
| marex | mntmn: the former is implemented, the later should be as well | 20:03 |
| marex | but with this lcdif, nothing surprises me anymore | 20:03 |
| mntmn | marex: ah, it is? i thought there was no way to get the irq in the soc | 20:03 |
| mntmn | i probably remember it wrong | 20:04 |
| marex | mntmn: you should at least get VSYNC IRQ delivered on your SoC already | 20:04 |
| marex | that's the only IRQ line the MXSFB has I think | 20:04 |
| mntmn | yeah, ok | 20:05 |
| marex | but maybe you have a point, hold on | 20:06 |
| marex | the mx8 datasheet talks about icoll, which is mx28 stuff | 20:06 |
| marex | hm no, all the relevant LCD irqs are wired to a single ICOLL IRQ on the MX28, so there is only one IRQ from the lcdif | 20:07 |
| mntmn | ok | 20:07 |
| mntmn | i remember there was some kind of urgent/alert line that you can set up that goes nowhere | 20:07 |
| mntmn | like, you can say, dear lcdif please alert me if this buffer goes low | 20:08 |
| mntmn | but it is not in the manual where this alert goes | 20:08 |
| marex | mntmn: I will look into the older datasheets a bit more, that's a good point | 20:08 |
| marex | 33.2.4LCDIF Interrupts | 20:10 |
| marex | LCDIF supports a number of interrupts to aid controlling and status reporting of the | 20:10 |
| marex | block. All the interrupts have individual mask bits for enabling or disabling each of them. | 20:10 |
| marex | They all get funneled through a single interrupt line connected to the interrupt collector | 20:10 |
| marex | (ICOLL). | 20:10 |
| marex | so no, there is single IRQ line | 20:10 |
| mntmn | ah, gotcha, so it should end up in the same interrupt line that is used for vblank, yes? | 20:11 |
| marex | yep | 20:13 |
| mntmn | ok... so then theoretically the driver could recover actively | 20:13 |
| marex | except there is no underflow bit set when this wraparound happens | 20:14 |
| marex | mntmn: so anyway, once I have some patches, I'll let you know so you can test too | 20:15 |
| mntmn | marex: cool! | 20:15 |
| marex | mntmn: thanks for confirming this also happens on 8mq, that's good | 20:15 |
| mntmn | yeah. i wasn't sure if this was something mipi specific but it makes a lot of sense that it's just lcdif | 20:18 |
| mntmn | also, it does not happen with DCSS | 20:18 |
| marex | mntmn: it is likely only lcdif, since the mx6sx had DPI directly out of the LCDIF | 20:19 |
| mntmn | ok | 20:19 |
| marex | mntmn: pity, I no longer have that hardware :( | 20:19 |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@72.168.176.34) | 20:21 | |
| + freakazoid333 (~freakazoi@72.168.176.34) | 20:22 | |
| mntmn | giving FEX another spin https://github.com/FEX-Emu/FEX | 21:10 |
| - adjtm (QUIT: Remote host closed the connection) (~adjtm@188.26.199.251) | 22:26 | |
| + adjtm (~adjtm@2a0c:5a80:1b04:a00:151f:79bd:1956:4d81) | 22:29 | |
| Asmadeus | mntmn: nice! (ffmpeg) | 22:55 |
| mntmn | Asmadeus: yeah! thanks for the prep work!~ | 22:55 |
| mntmn | i also got amd64 glxgears to run in FEX with native GL lib | 22:55 |
| Asmadeus | ezequielg: you can explicitely select which hwaccel you want, and they also suggest putting hwdec=auto-safe in your config "if you really have to" so we might want to make sure v4l2 request goes into the 'safe' list at some point | 22:55 |
| mntmn | good to know | 22:56 |
| Asmadeus | I'll update my repo with the two modifications you listed on the forum for others | 22:57 |
| mntmn | Asmadeus: super, thanks | 23:00 |
| + adjtm_ (~adjtm@188.26.199.251) | 23:00 | |
| - adjtm (QUIT: Remote host closed the connection) (~adjtm@2a0c:5a80:1b04:a00:151f:79bd:1956:4d81) | 23:00 | |
| Asmadeus | hm, device == NULL probably ought to return an error instead of success? did you get a crash on this before adjusting permissions? | 23:01 |
| Asmadeus | Some check does seem to be needed though, other .device_create() have a check | 23:03 |
| mntmn | Asmadeus: i took this from another patchset but i still have to verify if its really needed | 23:03 |
| Asmadeus | found it, https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190903010230.96236-26-ffmpeg@tmm1.net/#45109 ? | 23:05 |
| mntmn | Asmadeus: yes | 23:05 |
| Asmadeus | btw I was expecting configure to fail if you didn't have recent kernel headers, sorry about that.. Sonuds like we'll want to add such a check before retrying to push upstream... | 23:10 |
| mntmn | Asmadeus: it does fail, but only if adding the additional configure option that i was missing at first (and that wasn't mentioned in the patchset) | 23:11 |
| Asmadeus | ah! ok | 23:11 |
| mntmn | Asmadeus: the full configure line is ./configure --enable-v4l2-request --enable-libdrm --enable-libudev --enable-shared --enable-hwaccel=h264_v4l2request | 23:12 |
| mntmn | Asmadeus: but i think the original patchset didn't mention --enable-hwaccel=h264_v4l2request | 23:12 |
| mntmn | and it will build anyway! but it will never activate | 23:12 |
| Asmadeus | evil thing, thanks for figuring it out | 23:13 |
| Asmadeus | ok you can take that extra patch off your post if you want, I think it's also missing a 'checkout' at some point to use my v4l2-request branch? | 23:14 |
| Asmadeus | And I'll definitely play with it a bit more when the reform arrives around the end of the week :) | 23:14 |
| mntmn | oh, let me see | 23:17 |
| mntmn | you are right, checkout is missing, and i'll remove the patch | 23:18 |
| - erlehmann (QUIT: Ping timeout: 252 seconds) (~erle@dynamic-046-114-039-105.46.114.pool.telefonica.de) | 23:27 | |
| + erlehmann (~erle@dynamic-046-114-038-222.46.114.pool.telefonica.de) | 23:41 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!