hverkuil: ah, nevermind that. I saw the videodev2.h.rst.exceptions warning.
ezequielg: sorry, I missed your question from earlier. But you found the answer already.
:-)
i can send the v4l2-meta-fmt-rk-isp1-params warnings as well, while here.
i have to proof read the docs, and then hopefully v5 will be ready.
I thought there was a patch for rkisp1 posted already.
ezequielg: one other question (I think I asked that before): vp8 is also ready for uapi, right? Will you make patches for vp8 as well to take it out of staging?
yes.
not sure there is time for 5.11 though.
(and not seeing the rkisp1 videodev2 exception patch)
ezequielg: https://patchwork.linuxtv.org/project/linux-media/patch/20201118142400.3540109-1-helen.koike@collabora.com/
ezequielg: once v5 is posted, I'll start compiling/testing etc. immediately. I really want to get this merged in time for 5.11. I'll also finish and post my fwht changes on top of that.
hverkuil: http://ix.io/2Fwe v4 to v5
think it's good.
please all take a look to "media: controls: Add VP8 stateless type initialization", would allow us to pass v4l2-compliance in the drivers.
s/all/also
hverkuil: OK, v5 sent.
mchehab: Bom dia!
sailus: moikka!
mchehab: How do you do?
fine, and you?
PR for de-staging of H.264 and FWHT stateless API has been posted.
Many thanks to ezequielg, ndufresne, jernej, paulk-leonov, mripard and others who worked on this and made this possible!
and I crashed as well!
Wow.
Try to downgrade to older fw (v7 definitely works), while I'll try to investigate what is going on here.
hverkuil: I guess that's addressed to me ? :)
Oops, yes :-)
hverkuil: awesome!
paulk-leonov: mripard: hverkuil: ezequielg: Has any of you time to look at my Cedrus VP8 patch?
there is no hurry, but nevertheless
ezequielg: credrus/gst got 52/135
so quite some work ahead ;-P
a lot of E to investigate
ndufresne: that's h264?
nufresne: was that with linux-next? Cedrus on 5.9 is not featureful
jernej: I'm on 5.9 indeed
but most of the failure are very strange
jernej: https://justpaste.it/2h20c
I see a DQBUF, buffer being marked dequeued, but when I try and queue it back, I get "invalid state done"
unless I'm missing something, this looks quite broken in the core
let's update to something newer
hm... I can't comment on gstreamer
that paste is kernel
were you can see a DQBUF followed immediatly by a QBUF, but it seems that the buffer state magically change from dequeued to done
well, I didn't observed any strange behaviour
try with linux-next first, anyway
jernej: in fact, there is very little different when you look at the kernel side if you compare gst vs ffmpeg, since there is very little flexibility in how to correctly decode
jernej: did you run ITU ?
I got that while trying to decode JVT-AVC_V1/BA1_FT_C/BA1_FT_C.264
not recently
currently I got one BBB sample, which exposes decoding issue
with ezequielg H264 series it refuses to decode, while with old code, it has artifacts
anyway, still something to improve
same file fails with the ffmpeg build I got
hmm, that ffmpeg build might be too old,
pointer control id 0x990ceb size too small, 892 bytes but 896 bytes needed
the API breaks is out to be fun !
ndufresne: BA1_FT_C is actually part of my standard test collection and I haven't experience any problem for a long time
have you tried fluster btw ?
well, something to figure-out then ...
no, not yet
I'm working on several things at the same time, cedrus is on side track atm
but for sure I'll try it at some point
false alarm, new H264 series doesn't change a thing for that video
noted
jernej: ezequielg added code in gst to avoid sending the same control again and again, I think it broke in cedrus, which has some dummy validation
(testing head of media tree now)
with the new API of course
why would that broke Cedrus? old values should be used in that case...
jernej: I'm not familiar with the code in cedrus_request_validate(), but I see that it fails for the controls I omited (but the old version was valid)
ndufresne: I see now, thanks for pointing this out
the spec explicitly allow this optimization, so I guess it would be nice to fix
maybe this is a relic of old plan
yeah, when paulk-leonov thought that each request was stateless up to userspace
but without a zero-copy way to pass the controls, that is expensive
the general idea ezequielg and I had is that we can reduce to a strict minimum the information we need to copy over for second and following slices
(for multi-slice decoding)
ndufresne: will you make necessary change? you have already appropriate setup to test
and in general, pps/sps is not needed if it haven't changed
I guess I could, but how do you validate similarly in that context ?
not sure what you mean exactly
I might need to ask ezequielg in fact, perhaps the idea is that validation should be done outside
validation of what?
cedrus approach is to check that specific controls are attached to a specific request
ezequielg I think was adding validation of the structure data instead
that's already in new h264 series
perhaps the answer is that this check should simply be removed in cedrus
yeah, I think so too
ok, testing now
jernej: my goal is to get interlaced decoding working in gst
as I know you tested that with ffmpeg (meaning driver should be fairly fine already) I picked Cedrus for that work
by interlaced decoding you mean two different streams at the same time?
hmm, back to square 1, at some random point, I DQBUF() the bitstream index 1, then I QBUF that same buffer, and the driver says it's in state DONE ....
and fail
jernej: no, frames with top and bottom fields, we didn't have support for the in our decoder common code yet
ah, yes, interlaced content decoding
that works fine
with linux-next :)
or maybe 5.9, not sure anymore
well, it should not have regressed right ;-P
no, I'm using very latest cedrus patches on top of 5.9.11
and it everything works fine with rare issues, at least for me
great
ndufresne: if you're interested in ffmpeg, I can give you patch, which can be applied on top of clean 4.3.1
right now I'm trying to get V4L2 code in gst to be on par with the DXVA2 and VA implementation
jernej: for the -next ?
that would be nice, could be handy to compare against
yes, including h264 destaging series
ndufresne: apply on top of ffmpeg 4.3.1: http://ix.io/2FzJ
note that this patchset has various WIP patches for other codecs too
but you can just ignore it
*them
thanks
jernej: a build issue I've hit with the ffmpeg work is missing PATH_MAX, I got FILENAME_MAX on my system, but not the other
interesting, in which file?
libavcodec/v4l2_m2m.h
it's the only occurrence of PATH_MAX in the entire code base
hm... it compiles fine for me, I never had such problem...
can you just replace or define it?
yes, I do each time, but it seems it's something that only works on debianish distro of some sort
is it something introduce in that patchset, or something upstream ?
that's from upstream
and it works on LE distro too, which is not debian related :)
LE ?
it has to do with the libc I suppose
jernej: ok, the bug is that #include <linux/limits.h> is missing
but you got lucky ;-P
jernej: can't get ffmpeg to use the request decoders come ffmpeg command line
any idea if something change ?
sorry, LE -> LibreELEC, main interest, that's why I'm working on Cedrus too
sure
what's your command line?
~/FFmpeg/ffmpeg_g -hwaccel drm -hwaccel_device /dev/dri/card0 -i fluster/resources/JVT-AVC_V1/BA1_FT_C/BA1_FT_C.264 -pix_fmt yuv420p -f rawvideo test.yuv
I had that command line in some notes for a while ...
the request .o are included, but perhaps something else is broken in my build ?
you have proper kernel headers with new api, right?
ah, it's picking from kernel headers ?
this version yes :)
you probably don't have v4l2_request_h264.o
jernej: correct, installing the kernel headers now
jernej: thanks for the hint, now it's trying at least ;-P
ndufresne: does it work?
jernej: I should take a look at the VP8 support in Cedrus.
ezequielg: thanks!
jernej: that's a nice and simple patch :-)
for vp8?
yup.
to me, if it passes v4l2-compliance, and also if it's working well: which means it doesn't regress h264, mpeg-2, h265, (i.e. allows concurrent decoding from any codec, any number of streams)... let's ship it.
there doesn't seem to be any showstopper.
is that patch for vp8 header already merged?
no, i was refering to vp8 cedrus.
let me reply to it :-)
jernej: yeah, looks like it works
not yet inside fluster
ah, got it running now