#v4l 2020-02-14,Fri

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
ndufresnejkqxz: so my idea was that for the kernel/driver interface, we could move the common stuff into the decoder_params, that would reduce a bit the overhead, and for frame base decoders (the one that parses the slice, it will cover pretty much all the extra needed
well, except for the Hantro skip bit sizes
common/redundant
[01:33]
................................................................................................... (idle for 8h10mn)
hverkuilezequielg: the "[PATCH 0/4] Hantro VPU JPEG encoder fixes" series is good to go as far as you are concerned? Just double checking. [09:44]
.... (idle for 18mn)
I would like to move the usbvision driver to staging and remove it by the end of the year if nobody steps up to clean up this mess.
It's really old hardware by now, and a continuous source of syzbot bugs, mostly because the code is a mess.
Any objections?
[10:02]
pinchartlno objection [10:08]
kbinghamhverkuil, makes me think of this : https://www.goodreads.com/quotes/40705-but-the-plans-were-on-display-on-display-i-eventually :D but I can't step up so no objection :) [10:11]
.............. (idle for 1h6mn)
hverkuilezequielg: I'm marking the rkvdec driver series as "Changes Requested" due to the comments about copyright. I think that's the only blocking issue remaining.
ezequielg: But also see the discussion here between ndufresne and jernej and jkqxz in the last two days. I'm not sure if that impacts rkvdec or not.
[11:17]
............. (idle for 1h3mn)
ndufresne: Please mail linux-media about the slice param issues you've found, CC-ing all the relevant people. Also, any API limitations that prevent 8k video support for any codec should be fixed. It may be rare now, but it won't be as rare in a few years time. [12:21]
.... (idle for 15mn)
ezequielghverkuil: regarding the JPEG series: I think it's good to go. One minor thing, do you think it makes sense to express the tables in decimal, so they all look just like the spec?
eventually we'll want to move these tables elsewhere.
[12:36]
hverkuilezequielg: that might be useful (+ a link to the spec if that isn't there already and a comment why we use decimal here). But do that in be separate patch.
I'm going to post a PR for that series (and a lot more) today.
[12:38]
ezequielghverkuil: fair enough. separate patch it is.
hverkuil: so about rkvdec, I was planning to submit a new version next week. Do you think we should hold the driver until uAPI fixes are discussed?
It seems to me it's a separate discussion, the driver could move forward in the meantime.
[12:41]
hverkuilI agree. Just be ready to update the driver if uAPI changes are needed. But it is easier to maintain if it is merged.
ezequielg: BTW: when you post a new version, please also add a TODO file.
[12:51]
ezequielgI haven't checked the irc backlog. Perhaps today is a good day to do so :-) But if there are h264 core and uAPI changes in the pipeline, perhaps having the h264 helpers Boris wrote could be better.
(and using them everywhere)
[12:52]
hverkuilezequielg: remind me again which helpers you're talking about? [12:57]
ezequielghttp://patchwork.linuxtv.org/patch/61375/ hverkuil [12:57]
hverkuil(and yes, if you have time it's good to read the backlog, it seems to have started Feb 11)
Ah, I thought you referred to some other series.
[12:58]
.......................................... (idle for 3h27mn)
***benjiG has left [16:26]
............................................................. (idle for 5h2mn)
ndufresneezequielg: got no error but it my S_EXT_CTLRS traces like this "video2: VIDIOC_S_EXT_CTRLS: which=0xf010000, count=5, error_idx=4,"
I'm a bit confused, do it mean only 4 of the file worked, shouldn't it also fail the ioctl ?
my reading was that the error_idx should be count on success, but I assumed the ioctl would fail
[21:28]
ezequielghm, ok
ndufresne: if you suspect errors you can enable dev_debug on your sys/class/video4linux/videoX
you can start with 0xff
[21:43]
ndufresnesig, this is dev debug output I just pasted [21:43]
ezequielglol
not too verbose, uh
I thought we where already doing better
sorry
[21:45]
ndufresnewell, I pass the controls, the ioctl return 0, but I just notice reading the rate that the error-id isn't 5, have no idea if that make any sense, if it fail or not
I never used that API before
do you have ffmpeg handy, and check what you get with it works ?
[21:47]
ezequielgnope
but i'm checking the code and the docs
"The value is undefined if the ioctl returned 0 (success)."
ndufresne: ^
[21:49]
ndufresnehmm, weird
that's can only get people like me to be confused
[21:51]
ezequielgyeah, i'm still checking.
yet another todo item :-)
[21:52]
ndufresneI read the huge blob of text, but apparently forgot about that line by the end of it
that does sounds like "you know, this is a terrible API, so let me explain how it can work, as it's not obvious"
* that doc
[21:52]
ezequielgafter 3 minutes of code reading, here's my take. i can confirm this on monday.
count is 5 so you have 5 controls, index 0 to 4
[21:53]
ndufresne(y) [21:53]
ezequielgwhen the kernel starts dealing with a control it sets error_idx to the index. [21:54]
ndufresneah, so it ended on index 4, leaving it to 4 [21:54]
ezequielgso if it fails, error_idx will have the last one.
exaclt.y
but i didn't even spend 3 minutes, more 3 seconds, so my theory can be all bogus.
[21:54]
ndufresneyou know what, I have forgotten it's an index in the first placed, because of this count thing [21:54]
ezequielgOTOH, I agree we could zero it on a success
avoiding ambiguities for the win on an API
[21:55]
ndufresneit's an internal value leaked back to user
not a big deal, I was just very confused, thanks a lot
[21:55]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)