[12:15] <ndufresne> hverkuil, sorry if I'm creating more question then giving answer in my reply, I'll keep thinking about this a little, specially the mediatek case
[12:15] <ndufresne> tfiga, do you know a little more about mediatek codec and were to look at outside of the driver source code ?
[12:16] <ndufresne> I'm thinking at first that we need to check if there is a common format, which the kernel can maybe bounce as needed, and then we could add some signaling as an "optimization"
[12:17] <ndufresne> also, we should check what the RPi4 driver does, I think it's not submitted yet as it's pending on major changes in mmal
[12:18] *** z3ntu_ has left 
[13:21] <tfiga> ndufresne: what would you like to look at? I'm afraid the driver is the only thing we have, at least for the currently upstream statefull decoder
[13:21] <tfiga> I might be able to ask some specific questions to mediatek directly, though
[13:56] <ndufresne> tfiga, mostly if on top of needing pps/sps each in their own buffers, do we need to identify them ?
[13:57] <ndufresne> (from a firmware API point of view)
[14:41] <tfiga> ndufresne: not sure, the driver was done when I was out of the video business for a while
[14:42] <tfiga> gnurou tested different buffer contents some time ago and that's how we figured out that such separation was needed
[14:42] <tfiga> it's possible that the firmware was made to expect exactly what chrome was passing in each buffer at that time...
[14:43] <ndufresne> and was the order guarantied ?
[14:43] <tfiga> no, I don't think so
[14:44] <ndufresne> hmm, ok, then it's weird that it does not accept random alignment, since it has to parse
[14:44] <tfiga> I described the behavior on the list some time ago
[14:44] <ndufresne> maybe it does not do NAL framing ?
[14:44] <tfiga> for some NAL unit types, we send a buffer with only that NAL unit and that includes SPS and PPS
[14:44] <tfiga> and possibly something else, I don't remember
[14:45] <tfiga> but it goes in the order as it comes from the stream
[14:45] <tfiga> I think it's just broken
[14:45] <tfiga> we had so many issues with that firmware
[14:46] <tfiga> that's the reason we pushed for stateless with the next hw generation
[14:47] <tfiga> ndufresne: are there streams that have PPS and then SPS and then streams that have different order?
[14:47] <tfiga> maybe we just didn't encounter a problematic stream?
[14:47] <tfiga> if you have any stream that could potentially break the assumptions of that firmware, please let me know and I can test
[14:48] <tfiga> if we find a problem, we might be able to get mediatek to fix that
[14:49] <ndufresne> tfiga, I have test stream from Allegro (kindly provided by Intel) where there is PPS in between SLICES, an then that SPS get activated with the first slice of the next frame (that all valid btw)
[14:49] <ndufresne> assuming that SPS/PPS preceeds all slices is bogus
[14:50] <ndufresne> I can't blame here, I thought it was the case for a long time
[14:52] <tfiga> is that stream really valid wrt the spec?
[14:53] <tfiga> that said, I would be interested in testing it
[14:53] <tfiga> that could give us a bit more information about the firmware expectations
[15:44] *** benjiG has left 
[20:51] <savoca> Does anyone have some pointers on reducing cpu usage from v4l2? I have a simple single thread app that reads frames from a v4l2 camera, then shows them with SDL
[20:52] <savoca> currently the sdl portion doesnt impact the cpu, but the v4l2 reading frames seems to peg core0 at 100%
[21:01] <sailus> savoca: What kind of hardware do you have?
[21:01] <savoca> the camera is a mipi ov2710, on android rk3288
[21:01] <sailus> With USB devices the data gets copied around so that will take some CPU time.
[21:02] <savoca> so hardware should be quite fast
[21:02] <savoca> 1080p@30, vga@120fps for this sensor
[21:02] <sailus> In some unlucky setups cache flushes may be involved as well.
[21:03] <savoca> i also have the same little app for my pc webcam and it does about the same, 100% on one core
[21:03] <savoca> but other apps like the cheese ubuntu webcam one barely touches cpu at all, so im sure im doing something off
[21:05] <sailus> Could it be this little program that does something funky?
[21:07] <savoca> im thinking so, its very basic only 500 lines, using 4 buffers but single threaded, probably something silly.