On 01/13/2014 11:15 AM, Andrzej Hajda wrote: > 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: >>> >>> <snip> >>> >>>>> 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 > I believe it is the best solution if you are interesting in fixing only MFC encoding. If your goal is wider I suggest to try linux-next kernel. There is basic(!) DT support for this board applied about month ago: https://lkml.org/lkml/2013/12/18/285 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----- >> > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
