Message ID | 20250813102501.1645940-1-barnabas.pocze@ideasonboard.com |
---|---|
Headers | show |
Series |
|
Related | show |
One big issue I currently see with the virtual pipeline is that it drops the configured/negotiated framerate / FrameDurationLimits on the ground in PipelineHandlerVirtual::start() (const ControlList *controls is unused), making it producing frames at full speed with both libcamerasrc and pipewiresrc. This series looks like it would make it much easier to implement throttling - did you happen to have looked into that / did you consider that here? On 13.08.25 12:24, Barnabás Pőcze wrote: > changes in v2: > * make `Thread::removeMessages()` public > * cancel requests instead of waiting for completion > > v1: https://patchwork.libcamera.org/cover/24088/ > > Barnabás Pőcze (2): > libcamera: base: thread: Make `removeMessages()` public > libcamera: pipeline: virtual: Move image generation to separate thread > > include/libcamera/base/thread.h | 2 +- > src/libcamera/pipeline/virtual/virtual.cpp | 87 ++++++++++++++-------- > src/libcamera/pipeline/virtual/virtual.h | 9 ++- > 3 files changed, 67 insertions(+), 31 deletions(-) > > -- > 2.50.1
Hi 2025. 08. 18. 17:10 keltezéssel, Robert Mader írta: > One big issue I currently see with the virtual pipeline is that it drops the configured/negotiated framerate / FrameDurationLimits on the ground in PipelineHandlerVirtual::start() (const ControlList *controls is unused), making it producing frames at full speed with both libcamerasrc and pipewiresrc. This series looks like it would make it much easier to implement throttling - did you happen to have looked into that / did you consider that here? Yes, it ignores the given frame rate. Originally I wanted to mention this in the description, but after some thinking I came to conclusion that it is not actually inherently simpler after this change. But indeed, that seems like a natural next thing to improve. Regards, Barnabás Pőcze > > On 13.08.25 12:24, Barnabás Pőcze wrote: >> changes in v2: >> * make `Thread::removeMessages()` public >> * cancel requests instead of waiting for completion >> >> v1: https://patchwork.libcamera.org/cover/24088/ >> >> Barnabás Pőcze (2): >> libcamera: base: thread: Make `removeMessages()` public >> libcamera: pipeline: virtual: Move image generation to separate thread >> >> include/libcamera/base/thread.h | 2 +- >> src/libcamera/pipeline/virtual/virtual.cpp | 87 ++++++++++++++-------- >> src/libcamera/pipeline/virtual/virtual.h | 9 ++- >> 3 files changed, 67 insertions(+), 31 deletions(-) >> >> -- >> 2.50.1 >
CC'ing Harvey, On Mon, Aug 18, 2025 at 05:17:45PM +0200, Barnabás Pőcze wrote: > Hi > > 2025. 08. 18. 17:10 keltezéssel, Robert Mader írta: > > One big issue I currently see with the virtual pipeline is that it > > drops the configured/negotiated framerate / FrameDurationLimits on > > the ground in PipelineHandlerVirtual::start() (const ControlList > > *controls is unused), making it producing frames at full speed with > > both libcamerasrc and pipewiresrc. This series looks like it would > > make it much easier to implement throttling - did you happen to have > > looked into that / did you consider that here? > > Yes, it ignores the given frame rate. Originally I wanted to mention this in the > description, but after some thinking I came to conclusion that it is not actually > inherently simpler after this change. But indeed, that seems like a natural next > thing to improve. Harvey, is this something you could help with ? > > On 13.08.25 12:24, Barnabás Pőcze wrote: > >> changes in v2: > >> * make `Thread::removeMessages()` public > >> * cancel requests instead of waiting for completion > >> > >> v1: https://patchwork.libcamera.org/cover/24088/ > >> > >> Barnabás Pőcze (2): > >> libcamera: base: thread: Make `removeMessages()` public > >> libcamera: pipeline: virtual: Move image generation to separate thread > >> > >> include/libcamera/base/thread.h | 2 +- > >> src/libcamera/pipeline/virtual/virtual.cpp | 87 ++++++++++++++-------- > >> src/libcamera/pipeline/virtual/virtual.h | 9 ++- > >> 3 files changed, 67 insertions(+), 31 deletions(-)