<Pix>
could it mean S912 could now have full linux support ? :)
<narmstrong>
Pix: drivers for certain boards and Mali Midgards version has been release
<narmstrong>
Amlogic or ARM did not release any User Space Mali driver for the T820 on S912
<Ely>
narmstrong: Your comment about the size had me remember that they add a -8 offset to the vififo end. And sure enough I did that for the stbuf, but not the esparser vififo end. So is ends up being a silly mistake, luckily easy fix..
<narmstrong>
Yeah !
<Pix>
narmstrong, even if they released a midgard userland version for the kirin 960, you don't think it would enable the t820 ? (it's the same family, afaik)
<narmstrong>
Maybe, some has already tried and it lead to artefacts.
<narmstrong>
Anyway the kernel driver for Midgard is not finished on my side... it build ms but it seems the drivers needs some platform specific tweaks I did not had time to investigate
<Ely>
This also drastically reduces errors seen when decoding at full speed with ffmpeg -f null -, like 1080p at 130fps
<Ely>
although there are still a fews
<Ely>
-s
Elpaulo_m has joined #linux-amlogic
Elpaulo_m2 has quit [Ping timeout: 265 seconds]
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m2 has quit [Client Quit]
Elpaulo_m has quit [Ping timeout: 260 seconds]
<ndufresne>
Ely, and 4K ?
<Ely>
Haven't tested yet, right now I'm fixing a bug where bitstreams with SEI data aren't decoded
<Ely>
4K is next
<Ely>
unfortunately gst refuses to launch pipelines for like 80% of the mkv/mp4 files I find so it's a pain everytime
<ndufresne>
Ely, can you show me how, with GST_DEBUG=2 ?
<ndufresne>
there was some negotiation error on 1.12, some of them are fixed in 1.14, but the reporter from comcast couldn't give me streams to test with
<Ely>
it's indeed a non negotiated error, let me dump the logs for you
<ndufresne>
Ely, best is just to give me the link to the file, then I can reproduce
<ndufresne>
this way you can focus on the driver ;-P
<Ely>
ndufresne: 4K seems to work fine (using ffmpeg v4l2m2m), which is good news
<Ely>
decode speed is 4k30 which I think is expected from spec
<Ely>
at least for h264
<ndufresne>
I think for H264 it's 30fps yest
<Ely>
Had to cramp down max buffers because otherwise ffmpeg requests 20 4K capture buffers and cma is like "nope", but otherwise the picture looks good with ffplay
<ndufresne>
hehe, and on gst side, 2M is probably too small
<Ely>
oh, capture = output, sorry. I was talking in V4L2 terms :P
<Ely>
for OUTPUT (input) buffers, I think the driver forces the size anyway to w*h, which would be around 8MB
<ndufresne>
haha, that big, but ok
<ndufresne>
I think gst will only allocate two anyway
<Ely>
yeh gst is very minimalistic
<Ely>
ffmpeg requests 20 of both types
<Ely>
Maybe that's configurable though, I didn't look
<ndufresne>
but as the parser makes a copy, I wonder why more then 2-3 would give better results
<Ely>
absolutely
<Ely>
But I don't think it's the driver's job to limit the amount of input buffers
<Ely>
even if it knows it won't make a difference
<Ely>
eh idk
<ndufresne>
no, but if we don't set that value, aka 0, the drivers usually have small heuristic to give a size that usually works
<ndufresne>
in fact, that should be come an utility in the kernel, and shared across drivers
<ndufresne>
it's based on the profile level (and tier for hevc)
<Ely>
I may have spoken too soon, I can't find the 20 in FFmpeg, looks like they request 0.. maybe v4l2 sets it to 20
<ndufresne>
chewitt, wasn't the lack of dmabuf in ffmepg a problem ? or was this added and I missed it ?
<ndufresne>
at least, DB410c decoder is decoding to cacheable memory ;-P
<chewitt>
i'm the wrong person to ask :)
<chewitt>
that video might have the answer
<ndufresne>
the commenter is funny
<ndufresne>
chewitt, did you notice that khodi says "SW", because it assumed everything ffmpeg is SW
<chewitt>
that's just cosmetic
<chewitt>
there was quite a bit of work done Kodi side since then
<ndufresne>
but yeah, true zero-copy is needed to reach high framerate (1080p60)
<ndufresne>
I'm curious how they are going to add support for FD backed frames in ffmpeg, because I could then use that in gst, and then less code for me to maintain !
<chewitt>
but can be adapted once the scheduler API changes land .. afaik
<ndufresne>
request apis, rockchip codec is stateless
<ndufresne>
oh, this is downstream mvpp thing
<chewitt>
again, i'm not really the person to ask :)
<ndufresne>
not the one running on chrome books
<ndufresne>
this one is a simple mailbox driver with a fully userspace driver, the driver implements DRM Dumb to let userspace allocate memory
<ndufresne>
(a big hack)
<chewitt>
at that point we were forced to use a 4.4 bsp for support
<chewitt>
for RK things are being reworked around 4.16 at the moment, which gives a base to start poking m2m things
<ndufresne>
av_drmprime struct isn't a great idea though, like if DMABuf was a DRM thing ...
<ndufresne>
I didn't realize how much downstream HW accel support was in ffmpeg
<chewitt>
the same guy who did that work has just finished submitting v4l2 support to Qt as well
<ndufresne>
with super evident names, like h264_mmal
<ndufresne>
I know it's RPi, but what the ....
<ndufresne>
the problem is that each of these have "special" format, so it never just work ...
<ndufresne>
imho, dmabuf should be exposed as normal formats, and a side API to access the FDs, this way, it just work like any SW codec, and you can optimized once for Linux
<dsd_>
cale
tingoose has quit [Ping timeout: 260 seconds]
Ntemis has quit [Remote host closed the connection]
trem has joined #linux-amlogic
Barada has joined #linux-amlogic
<ndufresne>
Ely, ok, for the stream you gave me, you'll have to fix your try_fmt implementation
<ndufresne>
right now I do TRY_FMT(32768x32768 with format H264)
<ndufresne>
and it gives me 1080p
<ndufresne>
so I assume that 1080p is the maximum supported by that codec, and then it fails negotiation
<ndufresne>
long term, you should implement ENUM_FRAMESIZE
<Ely>
Both those were fixed recently :/
<Ely>
I added enum_framesize and bumped try_fmt to 3840*2160
<Ely>
side question, can you run the iphone sample with 1.14 ?
<ndufresne>
no, it fails earlier with this colorimetry thing, working on it
<Ely>
Ah kk
<ndufresne>
Ely, on 1.14, if I extract the raw h264, then it playes, gst-launch-1.0 filesrc location=test.h264 ! h264parse ! v4l2h264dec ! fakevideosink
<ndufresne>
but currently it fails with the mov provided colorimetry, and I don't know why yet
<ndufresne>
Ely, it's no full framerate though, I get 27fps
<Ely>
Yeah there's some clock work in the dts that I haven't fixed yet and was suggested by narmstrong
<Ely>
I don't think in the current branch the decoder is actually running at max speed
<ndufresne>
and the raw h264 works on 1.12.3 here
<ndufresne>
so it's really the colorimetry stuff that messes up, I'll have to continue this later
<ndufresne>
Ely, though, you cannot test for decoding speed on 1.12, you need fakevideosink element for that
<Ely>
Mh, I can't get the raw h264 to work on 1.12.4..