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: 3484941 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 38D679F169 for ; Tue, 14 Jan 2014 10:29:23 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3B6B1201F5 for ; Tue, 14 Jan 2014 10:29:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 38EDA201F4 for ; Tue, 14 Jan 2014 10:29:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751315AbaANK3T (ORCPT ); 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-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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