kbingham you there?
LazyGrizzly hi!
hi kbingham[m]sorry for the ping i still haven't gotten feedback concerning my patch. see: https://www.mail-archive.com/linux-media@vger.kernel.org/msg121910.html am I missing something or is this normal?
pinchartl: Edgar resolved the issues I raised. Could you look at this patch for your tree please? ^
LazyGrizzly: perfectly reasonable ping :-)
ok, i wasn't sure^^
kbingham[m]: I'll try to :-)
LazyGrizzly: sure, you can ping me :-)
pinchartl: will do should anything come up :)
sailus: there are two pull requests from you, apparently for the same thing:
lmml_45990_resend_git_pull_for_4_16_intel_ipu3_cio2_csi_2_receiver_driver.patch
lmml_45996_git_pull_for_4_16_v2_intel_ipu3_cio2_csi_2_receiver_driver.patch
which is the right one?
Hey all. I wonder if someone could help me. I'm working on a streaming camera on RPi Zero W with v4l2 and the Pi camera in Golang/C. I'm using MJPEG and can stream video fine to a single source, by skipping frames if a receiver isn't ready for a frame, but this seems to fall apart when I have multiple receivers. I suppose I need to buffer the frames somewhere but conceptually, I don't know how best to
provide the frames to receivers
with my current implementation, its first come first served for frames, clearly that doesn't work
alias_neo: each receiver should have a queue from wich they can pop a buffer once they need it. you provider simply receives the image stream and fills a central buffer collection that the queues reference
at least that would be my first stab at it
LazyGrizzly: So every receiver would receive a copy of every frame into its buffer?
or you're suggesting a single, central buffer that the queues can pop a frame from, sounds like the locking requirements might complicate things?
alias_neo: i would rather have a central buffer collection that is managed by the provider. the queues reference the buffers and once all queues are through with the buffer it goes back into the pool and gets requeued into v4l2
its either copying for every queue or references
So currently I have a single v4l2_requestbuffers using MEMORY_MMAP with 4 buffers, they're all initially queued, and i dequeue them one at a time to read a frame and put them back when i'm done. Are you suggesting I might need multiple of these? I'm pretty new to v4l so not overly familiar with best practice
no. your device interaction will always be with only one v4l2_requestbuffers. although 4 buffers is likely not enough. what i am suggesting is that you hold the dequeued buffer in your application and give a pointer to this buffer into all queues. they handle your receivers and once all receivers are done you do a REQBUFS on it
also, I'm currently Q and DQ the buffers as fast as possible as it seems the only way to keep it working, I can't leave them queued for any period
having buffers queued in v4l2 should never cause problems
how odd
I presume they aren't refreshed though while queued?
they have to be DQ/REQ to update them
ok, I've increased my buffer count to 20
v4l2 only sees the buffers that are queued. dequeued buffers are not visible to v4l2. in order for v4l2 to fill a buffer you have to queue it
yes, understood, but, if I queue all my buffers, they don't get refreshed to I dequeue and requeue, correct?
s/to/until/
i think you are correct.
thanks. Ill have a crack at this queuing
gl hf
Is there a way lo tell userspace the render latency (time between queuing the buffer and it being actually rendered in the output) in an output source?
as far as i know the only thing you can see is the v4l2_buffer timestamp. everything else would have to come from the device itself via properties or an independent interface
mchehab: Bom dia!
sailus: moikka
mchehab: About the SPDX license tags --- what's the current recommendation?
I see some using C++ comments and some plain C comments.
And then there are patches changing one to the other and probably also the other way around. :-)
hverkuil: Ping?
hverkuil is in vacations
3 weeks
He just replied an e-mail.
Anyway, it can wait.
sailus: for *.c: C99 comments
for *.h: std-C comments
Or /* */ ?
SPDX ^
yes
Both are valid for C99, arent' they?
*.h: /**/
*.c: //
Ok.
that *is* confusing
Is there some reasoning behind this?
very easy to do it wrong
the reason for // is.... Linus wants this way
...but just for .c files? :-)
the reason for /* */ is mainly due to uAPI...
I somehow feel this won't be the end of the story...
:-)
as far as I understood the discussions, // can cause troubles on userspace, with some compilers (or when --std-c like flags are used)
no, it isn't the end... just the beginning
Linus wants // everywhere
I suspect that, soon, someone will change make headers_install to replace // by /*
Thanks for confirming this. I'll then revert my comment changes to a patch.
anytime
(14:01:56) mchehab: I suspect that, soon, someone will change make headers_install to replace // by /*
this is just my guess, although it may never happen
I'm not closely following SPDX discussions upstream
(I followed them for a while, but got busy with something else)
hmm... on a quick look on my own LKML archives, it seems that the subject stopped about the same time I stopped following :-)
My personal opinion is that comment blocks using C++ comments are just plain ugly. On a single line they are appealing though.
yeah, I don't like either
I guess a lot of people have their own opinions on the preferred comment style. :-)
ah, I knew there are more with // on header files...
Perhaps in one year we've gone back to C comments. :-D
it breaks build on some arch stuff with asm
I hope no-one will get hurt in the process.
https://lkml.org/lkml/2017/11/2/770
sailus: I guess // came to stay
I found easier the other way around
I'll either silently or very loudly nack :-D
Don't worry, the list server will happily eat it. ;-)
Let's introduce a bug^Wfeature at patchwork to send those to /dev/null
:-p
I added SPDX to some of my files...
even handling it with care, I ended by using the wrong documentation markup...
until someone pointed me, and I had myself to write a patch converting from // to /* */
it is *really messy* to have to obey to different standards on headers and c
from my side, while I prefer /* */, I'm actually ok with any of them, but just one, please :-)
so, yeah, I expect that, by the next KS time, this will be sorted out, one direction or the other
mchehab: My thoughts exactly; the current rules have, well, ended up being non-trivial and there will be further complications from exceptions due to arch or whatever exceptions. Code that mixes both comments randomly doesn't look nice either.
Which I guess has been partly the reason why we've stuck with /* */.
mchehab: Need to go, have a nice evening!
nice evening/night!