| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When | |
|---|---|---|---|
| ezequielg | hverkuil: ah, nevermind that. I saw the videodev2.h.rst.exceptions warning. | [07:32] | |
| hverkuil | ezequielg: sorry, I missed your question from earlier. But you found the answer already. | [07:33] | |
| ezequielg | :-)
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. | [07:33] | |
| hverkuil | 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? | [07:36] | |
| ezequielg | yes.
not sure there is time for 5.11 though. (and not seeing the rkisp1 videodev2 exception patch) ezequielg bbl | [07:40] | |
| hverkuil | ezequielg: https://patchwork.linuxtv.org/project/linux-media/patch/20201118142400.3540109-1-helen.koike@collabora.com/ | [07:46] | |
| 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. | [07:51] | ||
| ................. (idle for 1h21mn) | |||
| ezequielg | 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 | [09:12] | |
| ..... (idle for 21mn) | |||
| hverkuil: OK, v5 sent. | [09:36] | ||
| ....... (idle for 30mn) | |||
| sailus | mchehab: Bom dia! | [10:06] | |
| *** | r0kc4t has quit IRC (Remote host closed the connection) | [10:07] | |
| .... (idle for 19mn) | |||
| mchehab | sailus: moikka! | [10:26] | |
| sailus | mchehab: How do you do? | [10:26] | |
| .... (idle for 19mn) | |||
| mchehab | fine, and you? | [10:45] | |
| .................................... (idle for 2h58mn) | |||
| hverkuil | 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! | [13:43] | |
| .................... (idle for 1h39mn) | |||
| 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. | [15:24] | ||
| mripard | hverkuil: I guess that's addressed to me ? :) | [15:25] | |
| hverkuil | Oops, yes :-) | [15:26] | |
| .... (idle for 17mn) | |||
| ezequielg | hverkuil: awesome! | [15:43] | |
| .......... (idle for 46mn) | |||
| jernej | paulk-leonov: mripard: hverkuil: ezequielg: Has any of you time to look at my Cedrus VP8 patch?
there is no hurry, but nevertheless | [16:29] | |
| ....... (idle for 34mn) | |||
| ndufresne | ezequielg: credrus/gst got 52/135
so quite some work ahead ;-P a lot of E to investigate | [17:03] | |
| jernej | ndufresne: that's h264? | [17:17] | |
| ......... (idle for 43mn) | |||
| nufresne: was that with linux-next? Cedrus on 5.9 is not featureful | [18:00] | ||
| .......... (idle for 46mn) | |||
| ndufresne | jernej: I'm on 5.9 indeed
but most of the failure are very strange
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 | [18:46] | |
| jernej | hm... I can't comment on gstreamer | [18:47] | |
| ndufresne | 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 | [18:47] | |
| jernej | well, I didn't observed any strange behaviour
try with linux-next first, anyway | [18:49] | |
| ndufresne | 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 | [18:50] | |
| jernej | 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 | [18:52] | |
| ndufresne | 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 ! | [18:55] | |
| jernej | ndufresne: BA1_FT_C is actually part of my standard test collection and I haven't experience any problem for a long time | [19:00] | |
| ndufresne | have you tried fluster btw ?
well, something to figure-out then ... | [19:01] | |
| jernej | 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 | [19:03] | |
| ndufresne | noted | [19:09] | |
| 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 | [19:18] | ||
| jernej | why would that broke Cedrus? old values should be used in that case... | [19:19] | |
| ndufresne | 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) | [19:21] | |
| jernej | ndufresne: I see now, thanks for pointing this out | [19:23] | |
| ndufresne | the spec explicitly allow this optimization, so I guess it would be nice to fix | [19:23] | |
| jernej | maybe this is a relic of old plan | [19:23] | |
| ndufresne | 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) | [19:24] | |
| jernej | ndufresne: will you make necessary change? you have already appropriate setup to test | [19:25] | |
| ndufresne | 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 ? | [19:25] | |
| jernej | not sure what you mean exactly | [19:26] | |
| ndufresne | I might need to ask ezequielg in fact, perhaps the idea is that validation should be done outside | [19:26] | |
| jernej | validation of what? | [19:27] | |
| ndufresne | 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 | [19:27] | |
| jernej | that's already in new h264 series | [19:27] | |
| ndufresne | perhaps the answer is that this check should simply be removed in cedrus | [19:27] | |
| jernej | yeah, I think so too | [19:28] | |
| ndufresne | 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 | [19:28] | |
| jernej | by interlaced decoding you mean two different streams at the same time? | [19:29] | |
| ndufresne | 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 | [19:30] | |
| jernej | ah, yes, interlaced content decoding
that works fine with linux-next :) or maybe 5.9, not sure anymore | [19:31] | |
| ndufresne | well, it should not have regressed right ;-P | [19:34] | |
| jernej | 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 | [19:35] | |
| ndufresne | great | [19:36] | |
| jernej | ndufresne: if you're interested in ffmpeg, I can give you patch, which can be applied on top of clean 4.3.1 | [19:37] | |
| ndufresne | 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 | [19:37] | |
| jernej | 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 | [19:38] | |
| ndufresne | thanks | [19:45] | |
| .......................... (idle for 2h7mn) | |||
| 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 | [21:52] | ||
| jernej | interesting, in which file? | [21:53] | |
| ndufresne | libavcodec/v4l2_m2m.h
it's the only occurrence of PATH_MAX in the entire code base | [21:54] | |
| jernej | hm... it compiles fine for me, I never had such problem...
can you just replace or define it? | [21:57] | |
| ndufresne | 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 ? | [21:58] | |
| jernej | that's from upstream
and it works on LE distro too, which is not debian related :) | [22:02] | |
| ndufresne | 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 ? | [22:04] | |
| jernej | sorry, LE -> LibreELEC, main interest, that's why I'm working on Cedrus too | [22:07] | |
| ndufresne | sure | [22:07] | |
| jernej | what's your command line? | [22:08] | |
| ndufresne | ~/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 ? | [22:08] | |
| jernej | you have proper kernel headers with new api, right? | [22:11] | |
| ndufresne | ah, it's picking from kernel headers ? | [22:12] | |
| jernej | this version yes :)
you probably don't have v4l2_request_h264.o | [22:12] | |
| ndufresne | jernej: correct, installing the kernel headers now | [22:21] | |
| jernej: thanks for the hint, now it's trying at least ;-P | [22:31] | ||
| ...... (idle for 25mn) | |||
| jernej | ndufresne: does it work? | [22:56] | |
| ezequielg | jernej: I should take a look at the VP8 support in Cedrus. | [22:59] | |
| jernej | ezequielg: thanks! | [23:00] | |
| ezequielg | jernej: that's a nice and simple patch :-) | [23:06] | |
| jernej | for vp8? | [23:06] | |
| ezequielg | 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. | [23:07] | |
| jernej | is that patch for vp8 header already merged? | [23:09] | |
| ezequielg | no, i was refering to vp8 cedrus.
let me reply to it :-) | [23:11] | |
| ...... (idle for 26mn) | |||
| ndufresne | jernej: yeah, looks like it works
not yet inside fluster ah, got it running now | [23:37] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |