From patchwork Fri Jan 24 21:57:53 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Milan Zamazal X-Patchwork-Id: 22641 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id C4FCCBD78E for ; Fri, 24 Jan 2025 21:58:37 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 44A8368564; Fri, 24 Jan 2025 22:58:37 +0100 (CET) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="AdqlTcgz"; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 6306068559 for ; Fri, 24 Jan 2025 22:58:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737755912; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WGX6GD2cAr9nlaG+lwkbVwl+BBa/f+38muiF3/p/ftI=; b=AdqlTcgzmxM+2WADrUxZMbNg5JjXGiUGTJ8HH+FWqLKirvOJGjhiU/kEIRPHyh3gvg5EmO x/BaStVX04KXuOirfwzi23w7SLNGwcITBQXchQqk5qaawIJ6HTqXGNdDkJu9Tg/RZRRx2N oTHr075/qgu9yaLBbayn4nNT53rFAVU= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-379-aKVJsm59M_ii3TYh1DTD2A-1; Fri, 24 Jan 2025 16:58:30 -0500 X-MC-Unique: aKVJsm59M_ii3TYh1DTD2A-1 X-Mimecast-MFC-AGG-ID: aKVJsm59M_ii3TYh1DTD2A Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D94DF180034F for ; Fri, 24 Jan 2025 21:58:29 +0000 (UTC) Received: from mzamazal-thinkpadp1gen3.tpbc.com (unknown [10.39.192.49]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id BF5E21800348; Fri, 24 Jan 2025 21:58:28 +0000 (UTC) From: Milan Zamazal To: libcamera-devel@lists.libcamera.org Cc: Milan Zamazal Subject: [RFC PATCH v2 02/13] libcamera: simple: Increase the default number of streams to 2 Date: Fri, 24 Jan 2025 22:57:53 +0100 Message-ID: <20250124215806.158024-3-mzamazal@redhat.com> In-Reply-To: <20250124215806.158024-1-mzamazal@redhat.com> References: <20250124215806.158024-1-mzamazal@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: NOBTBfJCurXe-oLoRA4vMteTAxMS5DfLw5gu42RR5_E_1737755910 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" In order to allow providing a raw stream together with a processed stream, we need two streams. If only one stream is eventually requested, it doesn't harm to allocate two. This is a hack for the lack of a better easy option. The number of streams is determined as a camera property in the pipeline matching. The actual number of streams needed (one or two) is determined only when examining roles in SimplePipelineHandler::generateConfiguration. It's not obvious what to do better about the number of the streams. It seems that hardware pipelines utilize separate hardware streams while with software ISP we have only a single input for multiple outputs. A fixed number of streams also doesn't scale but is good enough for our current use case, which is supporting a single processed + a single raw stream, not more. Signed-off-by: Milan Zamazal --- src/libcamera/pipeline/simple/simple.cpp | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/libcamera/pipeline/simple/simple.cpp b/src/libcamera/pipeline/simple/simple.cpp index 8ac24e6e..6e9bc630 100644 --- a/src/libcamera/pipeline/simple/simple.cpp +++ b/src/libcamera/pipeline/simple/simple.cpp @@ -1549,7 +1549,12 @@ int SimplePipelineHandler::resetRoutingTable(V4L2Subdevice *subdev) bool SimplePipelineHandler::match(DeviceEnumerator *enumerator) { const SimplePipelineInfo *info = nullptr; - unsigned int numStreams = 1; + /* + * Let's allocate two streams, for processed + raw streams. + * It's OK if there is only a single stream. + * TODO: This should be more flexible. + */ + unsigned int numStreams = 2; MediaDevice *media; for (const SimplePipelineInfo &inf : supportedDevices) {