From patchwork Tue Jan 14 10:29:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrzej Hajda X-Patchwork-Id: 21589 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1W31FL-0004Zm-Gt; Tue, 14 Jan 2014 11:29:23 +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.72/mailfrontend-8) with esmtp id 1W31FJ-0006aJ-k6; Tue, 14 Jan 2014 11:29:23 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751315AbaANK3T (ORCPT + 1 other); Tue, 14 Jan 2014 05:29:19 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:25094 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751287AbaANK3R (ORCPT ); Tue, 14 Jan 2014 05:29:17 -0500 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MZD00MEWZSRRL40@mailout3.w1.samsung.com> for linux-media@vger.kernel.org; Tue, 14 Jan 2014 10:29:15 +0000 (GMT) X-AuditID: cbfec7f4-b7f796d000005a13-27-52d5117b4294 Received: from eusync4.samsung.com ( [203.254.199.214]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id 4C.6A.23059.B7115D25; Tue, 14 Jan 2014 10:29:15 +0000 (GMT) Received: from [106.116.147.88] by eusync4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0MZD00GXYZSQ4120@eusync4.samsung.com>; Tue, 14 Jan 2014 10:29:15 +0000 (GMT) Message-id: <52D51179.8030102@samsung.com> Date: Tue, 14 Jan 2014 11:29:13 +0100 From: Andrzej Hajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-version: 1.0 Newsgroups: gmane.linux.drivers.video-input-infrastructure To: randy , Kamil Debski , linux-media@vger.kernel.org Cc: kyungmin.park@samsung.com Subject: Re: using MFC memory to memery encoder, start stream and queue order problem References: <02c701cf07b6$565cd340$031679c0$%debski@samsung.com> <02c801cf07ba$8518f2f0$8f4ad8d0$%debski@samsung.com> <04b601cf0c7f$d9e531d0$8daf9570$%debski@samsung.com> <52CD725E.5060903@hotmail.com> <52CFD5DF.6050801@samsung.com> <52D3BCB7.1060309@samsung.com> <52D3CB84.6090406@samsung.com> <001701cf107b$0927aa50$1b76fef0$%debski@samsung.com> In-reply-to: Content-type: multipart/mixed; boundary=------------000602010600090002030800 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsVy+t/xa7rVgleDDM7cFbP48foCm8XZpjfs Fj0btrJabH19hMWBxeNxzxk2j74tqxg9Pm+SC2CO4rJJSc3JLEst0rdL4Mo433ydpeASf8WN PVvYGxgn8nYxcnJICJhI7D35hhnCFpO4cG89WxcjF4eQwFJGibv3bkA5nxglFi7fxAZSxSug JfF6wllGEJtFQFXizuFFYDabgKbE3803wWpEBSIkXp2dyAJRLyjxY/I9IJuDg0/ASmLKGnOQ sIhAskRj21OwcmYBWYnzt1ezgpQIC4RLTF4XBxIWEtjPKrHkogOIzSlgI3H/zwZ2iHIfiY9H bjFNYBSYhWTBLCSpWUCTmAXUJdbPE4IIy0tsfzuHGSIcIdHVKY8qDGInShz89Y5xASP7KkbR 1NLkguKk9FxDveLE3OLSvHS95PzcTYyQaPiyg3HxMatDjAIcjEo8vCcZrwQJsSaWFVfmHmJU AZrzaMPqC4xSLHn5ealKIrziPFeDhHhTEiurUovy44tKc1KLDzEycXBKNTB6vJzF/oV5tqJj ecTbkDCRY4oKftqnn5culf6mOunLqtdPLvjvXchoZNWmwvd9/vPrbxhfsj3Ycfvjigu+iXyx M8rmc/rePnVT5eKhsu9nFzksirtUFFTXEfZM+tuOSqmApoqSsPAozUNOu2dtzGGLX6h9W2W/ 0cq/xeEMIQIzrcwZf+XouF1QYinOSDTUYi4qTgQAQEfwDHACAAA= Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.14.102115 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, CTYPE_MULTIPART_NO_QUOTE 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILING_LIST 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' On 01/14/2014 06:17 AM, randy wrote: > Yes, it make encoder work. But sadness ./mfc-encode -m /dev/video1 -c > h264,header_mode=1 -d 1 will still output a zero demo.out without > header-mode or set it to zero will works. > What is the problem? It seems infradead repo is not synchronized with our internal repo. Please apply attached patch. Regards Andrzej From bccf89a62a2e45cd45f4bf5d4adff9ec8a16b3bd Mon Sep 17 00:00:00 2001 From: Andrzej Hajda Date: Mon, 20 May 2013 09:24:23 +0200 Subject: [PATCH] Do not stop encoding after empty buffers Signed-off-by: Andrzej Hajda --- v4l2-mfc-encoder/func_dev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/v4l2-mfc-encoder/func_dev.c b/v4l2-mfc-encoder/func_dev.c index c3fff54..3cddef1 100644 --- a/v4l2-mfc-encoder/func_dev.c +++ b/v4l2-mfc-encoder/func_dev.c @@ -76,13 +76,13 @@ int func_deq_buf(struct io_dev *dev, enum io_dir dir) for (i = 0; i < bufs->nplanes; ++i) bufs->bytesused[bufs->nplanes * idx + i] = lens[i]; - dbg("Dequeued buffer %d/%d from %d:%d", idx, bufs->count, dev->fd, dir); + dbg("Dequeued buffer %d/%d from %d:%d ret=%d", idx, bufs->count, dev->fd, dir, ret); --dev->io[dir].nbufs; ++dev->io[dir].counter; - if (ret <= 0 || (dev->io[dir].limit && + if (ret < 0 || (dev->io[dir].limit && dev->io[dir].limit <= dev->io[dir].counter)) { dev->io[dir].state = FS_END; dbg("End on %d:%d", dev->fd, dir); -- 1.8.3.2