From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mailout4.w1.samsung.com ([210.118.77.14]:36290 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751484AbaAMKPX (ORCPT ); Mon, 13 Jan 2014 05:15:23 -0500 MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MZC00EY64HM0160@mailout4.w1.samsung.com> for linux-media@vger.kernel.org; Mon, 13 Jan 2014 10:15:22 +0000 (GMT) Content-transfer-encoding: 8BIT Message-id: <52D3BCB7.1060309@samsung.com> Date: Mon, 13 Jan 2014 11:15:19 +0100 From: Andrzej Hajda To: randy , linux-media@vger.kernel.org Cc: Kamil Debski , 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> In-reply-to: Sender: linux-media-owner@vger.kernel.org List-ID: On 01/10/2014 04:23 PM, randy wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 于 2014年01月10日 19:13, Andrzej Hajda 写道: >> Hi Randy, >> >> On 01/10/2014 10:15 AM, randy wrote: >> >> >> >>>> It won't work, if I do that, after step 7, neither OUPUT nor >>>> CAPTURE will poll return in my program. but ./mfc-encode -m >>>> /dev/video1 -c h264,header_mode=1 work normally, >>> I am sorry, I didn't well test it, if I use ./mfc-encode -m >>> /dev/video1 -c h264,header_mode=1 -d 1 then the size of demo.out >>> is zero, but ./mfc-encode -d 1 -m /dev/video1 -c h264 will out a >>> 158 bytes files. When duration is 2, with header_mode=1, the >>> output file size is 228 bytes.Without it, the size is 228 too. I >>> wonder whether it is the driver's problem, as I see this in >>> dmesg [ 0.210000] Failed to declare coherent memory for MFC >>> device (0 bytes at 0x43000000) As the driver is not ready to use >>> in 3.13-rc6 as I reported before, I still use the 3.5 from >>> manufacturer. >> >> I am the author of mfc-encode application, it was written for the >> mainline kernel 3.8 and later, it should be mentioned in the >> README.txt - I will update it. > Sadness, I have tested 3.10.26, in this version, neither decoder nor > encoder can be work(can't init according to clock problem). > In 3.8, it doesn't have dts support fully and lack many drivers. > I think I shall wait the the mfc done for 3.13. >> App will not work correctly with earlier kernels, mainly (but not >> only) due to lack of end of stream handling in MFC encoder driver. >> If you use vendor kernel I suggest to look at the vendor's capture >> apps/libs to check how it uses MFC driver. >> > Sadness, they doesn't offer any of them, even not any information > about it. > And I can't compile the openmax from samsung. I will report it later > in sourceforge. >> Regards Andrzej You can then try to backport EOS handling patch: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/52748 Regards Andrzej >> >> >> >> > > Thank you > ayaka > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJS0BCEAAoJEPb4VsMIzTziYJQH/RFX6oSL6JWb4ah/+SOlXT9m > V+qoPGy2h+KB82+vC7l4UNpYUrDO+U13y8G9IerZp3F3i83qBrpIBNb4jr6M1b/u > nm/g3U8RvJoTJkiL9iFFKNBuXZAtYYXFV1RgMtJJ/iXZavte3jOBIOeCpRZndh80 > b+ZmihGVPP9d66f/mMFJreFKUwP4UTOR/TuYgv1i106GRLmD2XAWFWTYBXygUeLE > GCRst2D+t4lpTH8Ttz+ZdzXEINZaCgO5Jf1UvK3+nLXfQbJREH9BWmODDhR6M269 > hn2lcU0D1HwGnVzdEN/Gx/8gneixg3oWP2nZVJ61w5WlABYpWKKyNbZqsfwzGXM= > =57or > -----END PGP SIGNATURE----- >