From patchwork Thu Dec 22 14:34:18 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Javier Martin X-Patchwork-Id: 8965 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1Rdjiz-0005Ya-I4; Thu, 22 Dec 2011 15:34:29 +0100 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-3) with esmtp id 1Rdjiy-0004vs-Fu; Thu, 22 Dec 2011 15:34:25 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751832Ab1LVOeT (ORCPT + 3 others); Thu, 22 Dec 2011 09:34:19 -0500 Received: from mail-wi0-f174.google.com ([209.85.212.174]:63468 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750958Ab1LVOeT (ORCPT ); Thu, 22 Dec 2011 09:34:19 -0500 Received: by wibhm6 with SMTP id hm6so2566645wib.19 for ; Thu, 22 Dec 2011 06:34:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.85.4 with SMTP id d4mr23919335wiz.0.1324564458193; Thu, 22 Dec 2011 06:34:18 -0800 (PST) Received: by 10.223.98.208 with HTTP; Thu, 22 Dec 2011 06:34:18 -0800 (PST) Date: Thu, 22 Dec 2011 15:34:18 +0100 Message-ID: Subject: MEM2MEM devices: how to handle sequence number? From: javier Martin To: linux-media@vger.kernel.org, m.szyprowski@samsung.com, laurent.pinchart@ideasonboard.com, s.nawrocki@samsung.com, hverkuil@xs4all.nl, kyungmin.park@samsung.com, shawn.guo@linaro.org, richard.zhao@linaro.org, fabio.estevam@freescale.com, kernel@pengutronix.de, s.hauer@pengutronix.de, r.schwebel@pengutronix.de Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.22.142414 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1800_1899 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, WEBMAIL_SOURCE 0, __ANY_URI 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_TO_X5 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NS ' X-LSpam-Score: -1.9 (-) X-LSpam-Report: No, score=-1.9 required=5.0 tests=BAYES_00=-1.9 autolearn=ham Hi, we have a processing chain composed of three v4l2 devices: --------------------- ----------------------- ---------------------- | v4l2 source | | v4l2 fixer | | v4l2 encoder | | (capture) |---------->| (mem2mem)| ------------>| (mem2mem) | ------------> |___________| |____________| |____________| "v4l2 source" generates consecutive sequence numbers so that we can detect whether a frame has been lost or not. "v4l2 fixer" and "v4l2 encoder" cannot lose frames because they don't interact with an external sensor. How should "v4l2 fixer" and "v4l2 encoder" behave regarding frame sequence number? Should they just copy the sequence number from the input buffer to the output buffer or should they maintain their own count for the CAPTURE queue? If the former option is chosen we should apply a patch like the following so that the sequence number of the input buffer is passed to the videobuf2 layer: Regards. diff --git a/drivers/media/video/videobuf2-core.c b/drivers/media/video/videobuf2-core.c index 1250662..7d8a88b 100644 --- a/drivers/media/video/videobuf2-core.c +++ b/drivers/media/video/videobuf2-core.c @@ -1127,6 +1127,7 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b) */ list_add_tail(&vb->queued_entry, &q->queued_list); vb->state = VB2_BUF_STATE_QUEUED; + vb->v4l2_buf.sequence = b->sequence; /* * If already streaming, give the buffer to driver for processing.