Hi, > From: randy [mailto:lxr1...@hotmail.com] > Sent: Monday, January 13, 2014 4:45 PM > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 20140113 19:18, Andrzej Hajda 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. > So it seems that the design my program is correct, just the driver's > problem? > > >>>>> > > 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. > >>> > > > >> 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 > > > I will try it, I wish the driver in -next is done, as I can never open > the mfc encoder in 3.12.
Randy, Please apply these two patches: [PATCH] media: s5p_mfc: remove s5p_mfc_get_node_type() function [PATCH] media: v4l2-dev: fix video device index assignment And try again with kernel 3.12. There was a problem with opening MFC that was introduced by other patches. > I have another problem with the data transporting way in v4l2-mfc- > encoder, it use m.userptr, I think it is not need, as it has been mmap > to bufs->addr before, just fill the bufs->addr is enough, and for mfc, > the buffer type V4L2_MEMORY_MMAP, I think that it had better use > m.mem_offset from v4l2 document, why it use userptr? > Best wishes, -- Kamil Debski Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
