using MFC memory to memery encoder, start stream and queue order problem

using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello

I have follow the README of the v4l2-mfc-encoder from the
http://git.infradead.org/users/kmpark/public-apps
it seems that I can use the mfc encoder in exynos4412(using 3.5 kernel
from manufacturer).
But I have a problem with the contain of the README and I can't get the
key frame(the I-frame in H.264). It said that
"6. Enqueue CAPTURE buffers.
7. Enqueue OUTPUT buffer with first frame.
8. Start streaming (VIDIOC_STREAMON) on both ends."
so I shall enqueue buffer before start stream, to enqueue a buffer, I
need to dequeue first, but without start stream, it will failed in both
side.
In this way I start OUTPUT(input raw video) stream first then dequeue
and enqueue the first frame, then I start the CAPTURE(output encoded
video) frame, dequeue CAPTURE to get a buffer, get the data from
buffer then enqueue the buffer. The first frame of CAPTURE is always a
22 bytes
frame(I don't know whether they are the same data all the time, but
size is the same from m.planes[0].bytesused), but it seems not a key
frame.

What is the problem, and how to solve it.

P.S I don't test the Linux 3.13-rc4, as the driver is not ready for
encoder before.

						Thank you
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJSxU74AAoJEPb4VsMIzTzi2oEH/1JJqfeZhMwogvWSVz+M3J4Y
2Bnej0RBBKF0Gu508IWrHy9t+DPg3c3wJt1M0j+GtUsv2Q+Jl2vlmDTLV/Gafzo6
xywye4raHpqHreFv4Q55SIseDbfV79eO84uv4RuV/fXEuPpo1MlZf9SOGCiAfoQI
ozxqoOPD2l2VaSA/351gtT93lkOREF2EnmVf2Wa31WWHw0LV3aoY9/OosxOiY9Fy
mVHHpYheDwHXdPfrxHXWKEA5GOJ7h0ozc66MPe7JInKSGdUcDrdrFxdSVwyZ/21B
Oc2Aw9RMd85NwjXBc9hYH++3f73tcVhzMCF7Swyb+bsn4Mzyr64Bn4VsYaDqiCc=
=HCKX
-----END PGP SIGNATURE-----

RE: using MFC memory to memery encoder, start stream and queue order problem

[Kamil Debski]

Hi Randy,

> From: randy [mailto:lxr1234@hotmail.com]
> Sent: Thursday, January 02, 2014 12:35 PM
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello
> 
> I have follow the README of the v4l2-mfc-encoder from the
> http://git.infradead.org/users/kmpark/public-apps
> it seems that I can use the mfc encoder in exynos4412(using 3.5 kernel
> from manufacturer).

So it is not the mainline kernel. Could you give a link to this kernel?
I have doubts that this kernel is using the open source driver. The
driver present in that kernel could be a significantly modified driver.

> But I have a problem with the contain of the README and I can't get the
> key frame(the I-frame in H.264). It said that "6. Enqueue CAPTURE
> buffers.
> 7. Enqueue OUTPUT buffer with first frame.
> 8. Start streaming (VIDIOC_STREAMON) on both ends."
> so I shall enqueue buffer before start stream, to enqueue a buffer, I
> need to dequeue first, but without start stream, it will failed in both
> side.

I think I don't understand this. You should enqueue the buffers and then
start streaming. I think dequeueing is not mentioned here. First enqueue
then dequeue.

> In this way I start OUTPUT(input raw video) stream first then dequeue
> and enqueue the first frame, then I start the CAPTURE(output encoded
> video) frame, dequeue CAPTURE to get a buffer, get the data from buffer
> then enqueue the buffer. The first frame of CAPTURE is always a
> 22 bytes
> frame(I don't know whether they are the same data all the time, but
> size is the same from m.planes[0].bytesused), but it seems not a key
> frame.
> 
> What is the problem, and how to solve it.
> 
> P.S I don't test the Linux 3.13-rc4, as the driver is not ready for
> encoder before.
> 
> 						Thank you
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJSxU74AAoJEPb4VsMIzTzi2oEH/1JJqfeZhMwogvWSVz+M3J4Y
> 2Bnej0RBBKF0Gu508IWrHy9t+DPg3c3wJt1M0j+GtUsv2Q+Jl2vlmDTLV/Gafzo6
> xywye4raHpqHreFv4Q55SIseDbfV79eO84uv4RuV/fXEuPpo1MlZf9SOGCiAfoQI
> ozxqoOPD2l2VaSA/351gtT93lkOREF2EnmVf2Wa31WWHw0LV3aoY9/OosxOiY9Fy
> mVHHpYheDwHXdPfrxHXWKEA5GOJ7h0ozc66MPe7JInKSGdUcDrdrFxdSVwyZ/21B
> Oc2Aw9RMd85NwjXBc9hYH++3f73tcVhzMCF7Swyb+bsn4Mzyr64Bn4VsYaDqiCc=
> =HCKX
> -----END PGP SIGNATURE-----

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

于 2014年01月02日 20:59, Kamil Debski 写道:
> Hi,
> 
>> From: lxr1234 [mailto:lxr1234@hotmail.com] Sent: Thursday,
>> January 02, 2014 1:57 PM To: Kamil Debski Subject: RE: using MFC
>> memory to memery encoder, start stream and queue order problem
>> 
>> 
>> 
>> Kamil Debski <k.debski@samsung.com>写到：
>>> Hi Randy,
>>> 
>>>> From: randy [mailto:lxr1234@hotmail.com] Sent: Thursday,
>>>> January 02, 2014 12:35 PM Hello
>>>> 
>>>> I have follow the README of the v4l2-mfc-encoder from the 
>>>> http://git.infradead.org/users/kmpark/public-apps it seems
>>>> that I can use the mfc encoder in exynos4412(using 3.5
>>> kernel
>>>> from manufacturer).
>>> 
>>> So it is not the mainline kernel. Could you give a link to
>>> this
>> kernel?
>>> I have doubts that this kernel is using the open source driver.
>>> The driver present in that kernel could be a significantly
>>> modified
>> driver.
>>> 
The kernel souce code can be found here
https://github.com/hizukiayaka/linux-tiny4412-origin
I am pushing.
>> Sorry, It doesn't in a git repo I will update,it later, the
>> kernel is from friendlyarm, I see driver source in kernel.
>>>> But I have a problem with the contain of the README and I
>>>> can't get
>>> the
>>>> key frame(the I-frame in H.264). It said that "6. Enqueue
>>>> CAPTURE buffers. 7. Enqueue OUTPUT buffer with first frame. 
>>>> 8. Start streaming (VIDIOC_STREAMON) on both ends." so I
>>>> shall enqueue buffer before start stream, to enqueue a
>>>> buffer,
>> I
>>>> need to dequeue first, but without start stream, it will
>>>> failed in
>>> both
>>>> side.
>>> 
>>> I think I don't understand this. You should enqueue the buffers
>>> and then start streaming. I think dequeueing is not mentioned
>>> here. First enqueue then dequeue.
>> Without dequeue, hwo to get a buffer to fill data(first raw
>> video)? And what shall enqueue in CAPTURE. Is there a guide fo
>> usibg memory to memory driver?
> 
> After doing a VIDIOC_REQBUFS you should do a VIDIOC_QUERYBUF call 
> to get the buffers. After that you can enqueue them.
> 
> I suggest that you first run decoding. v4l2-mfc-example from
> public-apps. This way you could see how the V4L2 framework works.
> 
I see thank you
the v4l2-mfc-encoder is so difficult that I failed to understand.
My code is modified from gst's mfc decoder, I ignored that ioctl in
source ;)
>>>> In this way I start OUTPUT(input raw video) stream first
>>>> then
>> dequeue
>>>> and enqueue the first frame, then I start the CAPTURE(output
>>>> encoded video) frame, dequeue CAPTURE to get a buffer, get
>>>> the data from
>>> buffer
>>>> then enqueue the buffer. The first frame of CAPTURE is always
>>>> a 22 bytes frame(I don't know whether they are the same data
>>>> all the time, but size is the same from
>>>> m.planes[0].bytesused), but it seems not a key frame.
>>>> 
>>>> What is the problem, and how to solve it.
>>>> 
>>>> P.S I don't test the Linux 3.13-rc4, as the driver is not
>>>> ready for encoder before.
>>>> 
>>>> Thank you
>>> 
>>> Best wishes,
>> Thank you -- lxr1234
> 
> Best wishes, Kamil
> 
> 


I forget to mail to the list, I just repeated to you directly as I
shall CC you.

				Thank you very much

				ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJSxXGxAAoJEPb4VsMIzTziHVQH+wXTpbhxjGme1sn8f1gbPNzZ
a3FDBjiVC/WiK0TW0kp1IIlV5X93vMhE/VagXIxgxv7FuNcTRYe3EKxXg96Thk4T
1svg7Cnny0FbZoCbm+2pzg5itvqowZfnQhBI71vnVWVlxHm2ub2tVha/JCtCLoW2
sXDoqg72tcdmxoAl8HqPmokGMkn5aLdVfPnOpLHfPJvNoIWCyOvpc5REutlF4uzT
NjgAZMqBwjARjd0nJiLaxsuQQ3EK8d8MCZkkZTCTQLiH+SKfu/Js3nTK1CCkWhSv
z82WDw5qmE3573+2+xxgACal0jPJaDynXBMd/wvBWzpLvSF/Jcg49RDS8exVQfs=
=q5zX
-----END PGP SIGNATURE-----

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

于 2014年01月02日 20:59, Kamil Debski 写道:
> Hi,
> 
>> From: lxr1234 [mailto:lxr1234@hotmail.com]
>> Sent: Thursday, January 02, 2014 1:57 PM
>> To: Kamil Debski
>> Subject: RE: using MFC memory to memery encoder, start stream and queue
>> order problem
>>
>>
>>
>> Kamil Debski <k.debski@samsung.com>写到：
>>> Hi Randy,
>>>
>>>> From: randy [mailto:lxr1234@hotmail.com]
>>>> Sent: Thursday, January 02, 2014 12:35 PM
>>>> Hello
>>>>
>>>> I have follow the README of the v4l2-mfc-encoder from the
>>>> http://git.infradead.org/users/kmpark/public-apps
>>>> it seems that I can use the mfc encoder in exynos4412(using 3.5
>>> kernel
>>>> from manufacturer).
>>>
>>> So it is not the mainline kernel. Could you give a link to this
>> kernel?
>>> I have doubts that this kernel is using the open source driver. The
>>> driver present in that kernel could be a significantly modified
>> driver.
>>>
>> Sorry, It doesn't in a git repo I will update,it later, the kernel is
>> from friendlyarm, I see driver source in kernel.
>>>> But I have a problem with the contain of the README and I can't get
>>> the
>>>> key frame(the I-frame in H.264). It said that "6. Enqueue CAPTURE
>>>> buffers.
>>>> 7. Enqueue OUTPUT buffer with first frame.
>>>> 8. Start streaming (VIDIOC_STREAMON) on both ends."
>>>> so I shall enqueue buffer before start stream, to enqueue a buffer,
>> I
>>>> need to dequeue first, but without start stream, it will failed in
>>> both
>>>> side.
>>>
>>> I think I don't understand this. You should enqueue the buffers and
>>> then
>>> start streaming. I think dequeueing is not mentioned here. First
>>> enqueue
>>> then dequeue.
>> Without dequeue, hwo to get a buffer to fill data(first raw video)?
>> And what shall enqueue in CAPTURE.
>> Is there a guide fo usibg memory to memory driver?
> 
> After doing a VIDIOC_REQBUFS you should do a VIDIOC_QUERYBUF call
> to get the buffers. After that you can enqueue them.
> 
> I suggest that you first run decoding. v4l2-mfc-example from public-apps.
> This way you could see how the V4L2 framework works.
> 
I have another problem with this, if I only request one buffer from
driver(index=0 in v4l2_buffer and only call VIDIOC_QUERYBUF) in both
side(OUTPUT and CAPTURE).
then
"5. Request CAPTURE and OUTPUT buffers. Due to hardware limitations of
MFC on
   some platforms it is recommended to use V4L2_MEMORY_MMAP buffers.
6. Enqueue CAPTURE buffers.
7. Enqueue OUTPUT buffer with first frame.
8. Start streaming (VIDIOC_STREAMON) on both ends.
9. Simultaneously:
   - enqueue buffers with next frames,"

I only have one buffer in OUTPUT, shall I do the next step first?
"
   - dequeue used OUTPUT buffers (blocking operation),
   - dequeue buffers with encoded stream (blocking operation),
   - enqueue free CAPTURE buffers.
"
I have used do the thing below after VIDIOC_QUERYBUF in both sides,
input_buffer.plane[0].data = mmap(NULL, buffer.m.planes[0].length,
PROT_READ | PROT_WRITE,MAP_SHARED, ctx->fd,
buffer.m.planes[0].m.mem_offset);
input_buffer.plane[1].data = mmap(NULL, buffer.m.planes[1].length,
PROT_READ | PROT_WRITE,MAP_SHARED, ctx->fd,
buffer.m.planes[1].m.mem_offset);
so for the the OUTPUT, I shall copy the raw video into the the
input_buffer.plane[0].data and input_buffer.plane[1].data
for different planes and then enqueue it?

>>>> In this way I start OUTPUT(input raw video) stream first then
>> dequeue
>>>> and enqueue the first frame, then I start the CAPTURE(output encoded
>>>> video) frame, dequeue CAPTURE to get a buffer, get the data from
>>> buffer
>>>> then enqueue the buffer. The first frame of CAPTURE is always a
>>>> 22 bytes
>>>> frame(I don't know whether they are the same data all the time, but
>>>> size is the same from m.planes[0].bytesused), but it seems not a key
>>>> frame.
>>>>
>>>> What is the problem, and how to solve it.
>>>>
>>>> P.S I don't test the Linux 3.13-rc4, as the driver is not ready for
>>>> encoder before.
>>>>
>>>> 						Thank you
>>>
>>> Best wishes,
>> Thank you
>> --
>> lxr1234
> 
> Best wishes,
> Kamil
> 
> 
> 

Thank you
						ayaka

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

于 2014年01月02日 20:59, Kamil Debski 写道:
> Hi,
> 
>> From: lxr1234 [mailto:lxr1234@hotmail.com] Sent: Thursday,
>> January 02, 2014 1:57 PM To: Kamil Debski Subject: RE: using MFC
>> memory to memery encoder, start stream and queue order problem
>> 
>> 
>> 
>> Kamil Debski <k.debski@samsung.com>写到：
>>> Hi Randy,
>>> 
>>>> From: randy [mailto:lxr1234@hotmail.com] Sent: Thursday,
>>>> January 02, 2014 12:35 PM Hello
>>>> 
>>>> I have follow the README of the v4l2-mfc-encoder from the 
>>>> http://git.infradead.org/users/kmpark/public-apps it seems
>>>> that I can use the mfc encoder in exynos4412(using 3.5
>>> kernel
>>>> from manufacturer).
>>> 
>>> So it is not the mainline kernel. Could you give a link to
>>> this
>> kernel?
>>> I have doubts that this kernel is using the open source driver.
>>> The driver present in that kernel could be a significantly
>>> modified
>> driver.
>>> 
>> Sorry, It doesn't in a git repo I will update,it later, the
>> kernel is from friendlyarm, I see driver source in kernel.
>>>> But I have a problem with the contain of the README and I
>>>> can't get
>>> the
>>>> key frame(the I-frame in H.264). It said that "6. Enqueue
>>>> CAPTURE buffers. 7. Enqueue OUTPUT buffer with first frame. 
>>>> 8. Start streaming (VIDIOC_STREAMON) on both ends." so I
>>>> shall enqueue buffer before start stream, to enqueue a
>>>> buffer,
>> I
>>>> need to dequeue first, but without start stream, it will
>>>> failed in
>>> both
>>>> side.
>>> 
>>> I think I don't understand this. You should enqueue the buffers
>>> and then start streaming. I think dequeueing is not mentioned
>>> here. First enqueue then dequeue.
>> Without dequeue, hwo to get a buffer to fill data(first raw
>> video)? And what shall enqueue in CAPTURE. Is there a guide fo
>> usibg memory to memory driver?
> 
> After doing a VIDIOC_REQBUFS you should do a VIDIOC_QUERYBUF call 
> to get the buffers. After that you can enqueue them.
> 
> I suggest that you first run decoding. v4l2-mfc-example from
> public-apps. This way you could see how the V4L2 framework works.
> 
I have another problem with this, if I only request one buffer from
driver(index=0 in v4l2_buffer and only call VIDIOC_QUERYBUF) in both
side(OUTPUT and CAPTURE).
then
"5. Request CAPTURE and OUTPUT buffers. Due to hardware limitations of
MFC on
   some platforms it is recommended to use V4L2_MEMORY_MMAP buffers.
6. Enqueue CAPTURE buffers.
7. Enqueue OUTPUT buffer with first frame.
8. Start streaming (VIDIOC_STREAMON) on both ends.
9. Simultaneously:
   - enqueue buffers with next frames,"

I only have one buffer in OUTPUT, shall I do the next step first?
"
   - dequeue used OUTPUT buffers (blocking operation),
   - dequeue buffers with encoded stream (blocking operation),
   - enqueue free CAPTURE buffers.
"
I have used do the thing below after VIDIOC_QUERYBUF in both sides,
input_buffer.plane[0].data = mmap(NULL, buffer.m.planes[0].length,
PROT_READ | PROT_WRITE,MAP_SHARED, ctx->fd,
buffer.m.planes[0].m.mem_offset);
input_buffer.plane[1].data = mmap(NULL, buffer.m.planes[1].length,
PROT_READ | PROT_WRITE,MAP_SHARED, ctx->fd,
buffer.m.planes[1].m.mem_offset);
so for the the OUTPUT, I shall copy the raw video into the the
input_buffer.plane[0].data and input_buffer.plane[1].data
for different planes and then enqueue it?

>>>> In this way I start OUTPUT(input raw video) stream first
>>>> then
>> dequeue
>>>> and enqueue the first frame, then I start the CAPTURE(output
>>>> encoded video) frame, dequeue CAPTURE to get a buffer, get
>>>> the data from
>>> buffer
>>>> then enqueue the buffer. The first frame of CAPTURE is always
>>>> a 22 bytes frame(I don't know whether they are the same data
>>>> all the time, but size is the same from
>>>> m.planes[0].bytesused), but it seems not a key frame.
>>>> 
>>>> What is the problem, and how to solve it.
>>>> 
>>>> P.S I don't test the Linux 3.13-rc4, as the driver is not
>>>> ready for encoder before.
>>>> 
>>>> Thank you
>>> 
>>> Best wishes,
>> Thank you -- lxr1234
> 
> Best wishes, Kamil
> 
> 
> 

Thank you
						ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJSxnG5AAoJEPb4VsMIzTzidYAIAIaB9iAKZKmpYPXtd5WPgbW6
wi+pOaj3I76me9ssPc2o2E+NOC6glByntsSdDDE0sq3kUMFFX8P+/82Qs1j/N5tt
+nWaOON8dg+TpzGBR2kyNl8juVNUpziw4HjdygI65g+Q6XomkX/Dgongplq8IL4a
hCFLcdIEPTpJJ+jhXd2qgUMEt6+Iz07qhZL8H7XvvP2cBCCrbg4tWNRenFasNm2m
1SsAS6T0lxwFwFwSzPIun9hOh1StbTNSvA0E/1Kt4jhTGCLynnror7FFxAVgrHyk
y8h8ptUSFnxQVCSWFxKwCw/CTDHpASZU0IuAP2Qw1mC5zCjiijgDa35OnUoj380=
=Xyj9
-----END PGP SIGNATURE-----

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

I rewrite my program, it takes the order as below
1.request buffer.
2.mmap input buffer with OUTPUT
3.output buffer with CAPTURE.
4.filled input buffer with the first frame.
5.enqueue the first frame in the input buffer in OUTPUT side
6.enqueue the output buffer in CAPTURE side
7.start stream
8.dequeue CAPTURE buffer and make output buffer pointer to data of it.
9.get output data from output buffer
/* the buffer get size is 22 below */
10.dequeue OUTPUT
/* timed out, it will never end */
Is there any problem with the order? I don't do any thing simultaneously
below, it seems to difficult to me to understand and not easy to debug.
I am not sure whether the mmap is correct, but I think it it as I don't
get segment fault.


And the thing in the next is like this I think
11.filled input buffer with the next frame
12.enqueue the next frame in the input buffer in OUTPUT side
13.dequeue CAPTURE buffer and make output buffer pointer to data of it.
14.dequeue OUTPUT
goto 11
Is it correct

I doubt the REAME
5. Request CAPTURE and OUTPUT buffers. Due to hardware limitations of MFC on
   some platforms it is recommended to use V4L2_MEMORY_MMAP buffers.
6. Enqueue CAPTURE buffers.
7. Enqueue OUTPUT buffer with first frame.
8. Start streaming (VIDIOC_STREAMON) on both ends.
9. Simultaneously:
I don't need to dequeue the OUTPUT buffer which is with first frame?
   - enqueue buffers with next frames,
   - dequeue used OUTPUT buffers (blocking operation),
   - dequeue buffers with encoded stream (blocking operation),
   - enqueue free CAPTURE buffers.


							Thank you.

RE: using MFC memory to memery encoder, start stream and queue order problem

[Kamil Debski]

Hi Randy,

> From: randy [mailto:lxr1234@hotmail.com]
> Sent: Friday, January 03, 2014 4:17 PM
> 
> I rewrite my program, it takes the order as below 1.request buffer.
> 2.mmap input buffer with OUTPUT
> 3.output buffer with CAPTURE.
> 4.filled input buffer with the first frame.
> 5.enqueue the first frame in the input buffer in OUTPUT side 6.enqueue
> the output buffer in CAPTURE side 7.start stream 8.dequeue CAPTURE
> buffer and make output buffer pointer to data of it.
> 9.get output data from output buffer
> /* the buffer get size is 22 below */
> 10.dequeue OUTPUT
> /* timed out, it will never end */
> Is there any problem with the order? I don't do any thing
> simultaneously below, it seems to difficult to me to understand and not
> easy to debug.
> I am not sure whether the mmap is correct, but I think it it as I don't
> get segment fault.

Please have a look at the V4L2_CID_MPEG_VIDEO_HEADER_MODE control.
>From your description it seems that it is in its default state - 
V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE. This means that the header for a
newly encoded stream is returned after init. Then in another buffer you will
find the encoded picture.

So after point 9 please enqueue the CAPTURE buffer again and see what
happens. I think that you should get the first frame encoded.

You can also try to set the V4L2_CID_MPEG_VIDEO_HEADER_MODE control to
V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME and see if it works.
(instead of enqueueing the CAPTURE buffer again after receiving the header).

In addition I would recommend you to use more than one buffer per queue.
 
> 
> And the thing in the next is like this I think 11.filled input buffer
> with the next frame 12.enqueue the next frame in the input buffer in
> OUTPUT side 13.dequeue CAPTURE buffer and make output buffer pointer to
> data of it.
> 14.dequeue OUTPUT
> goto 11
> Is it correct
> 
> I doubt the REAME
> 5. Request CAPTURE and OUTPUT buffers. Due to hardware limitations of
> MFC on
>    some platforms it is recommended to use V4L2_MEMORY_MMAP buffers.
> 6. Enqueue CAPTURE buffers.
> 7. Enqueue OUTPUT buffer with first frame.
> 8. Start streaming (VIDIOC_STREAMON) on both ends.
> 9. Simultaneously:
> I don't need to dequeue the OUTPUT buffer which is with first frame?
>    - enqueue buffers with next frames,
>    - dequeue used OUTPUT buffers (blocking operation),
>    - dequeue buffers with encoded stream (blocking operation),
>    - enqueue free CAPTURE buffers.
> 
> 
> 							Thank you.

Best wishes,
Kamil

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

于 2014年01月08日 22:42, Kamil Debski 写道:
> Hi Randy,
> 
>> From: randy [mailto:lxr1234@hotmail.com] Sent: Friday, January
>> 03, 2014 4:17 PM
>> 
>> I rewrite my program, it takes the order as below 1.request
>> buffer. 2.mmap input buffer with OUTPUT 3.output buffer with
>> CAPTURE. 4.filled input buffer with the first frame. 5.enqueue
>> the first frame in the input buffer in OUTPUT side 6.enqueue the
>> output buffer in CAPTURE side 7.start stream 8.dequeue CAPTURE 
>> buffer and make output buffer pointer to data of it. 9.get output
>> data from output buffer /* the buffer get size is 22 below */ 
>> 10.dequeue OUTPUT /* timed out, it will never end */ Is there any
>> problem with the order? I don't do any thing simultaneously
>> below, it seems to difficult to me to understand and not easy to
>> debug. I am not sure whether the mmap is correct, but I think it
>> it as I don't get segment fault.
> 
> Please have a look at the V4L2_CID_MPEG_VIDEO_HEADER_MODE control.
>> From your description it seems that it is in its default state -
>> 
> V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE. This means that the header
> for a newly encoded stream is returned after init. Then in another
> buffer you will find the encoded picture.
> 
> So after point 9 please enqueue the CAPTURE buffer again and see
> what happens. I think that you should get the first frame encoded.
> 
There is the lastest my step
1.request buffer.
2.mmap input buffer with OUTPUT
3.output buffer with CAPTURE.
4.filled input buffer with the first frame.
5.enqueue the first frame in the input buffer in OUTPUT side
6.enqueue the all output buffers in CAPTURE side
7.start stream
8.poll blocking to wait OUTPUT or CAPTURE can be dequeue
9-1.if dequeued a CAPTURE buffer and get index from index from buffer
which has been mapped with a output buffer.
9-2.get output data from output buffer and re-enqueue it.
9-3.got back to step 4 but filled the next frame.
10. if dequeued a OUTPUT buffer, then enqueue it and return to step 8
The first frame is 22 bytes but the second is the big size, the third
is the same to the first and the forth is the same size to the second,
but the others are all big sizes(about 140000 to 16000)
> You can also try to set the V4L2_CID_MPEG_VIDEO_HEADER_MODE control
> to V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME and see if it
> works. (instead of enqueueing the CAPTURE buffer again after
> receiving the header).
> 
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 think it is the progblem of my code. As I follow your code, the poll
doesn't have timeout.
int mfc_enc_output_available(struct mfc_enc_context *ctx)
{
        int pollret;
        struct pollfd fds[2];
        fds[0].fd = ctx->fd;
        fds[0].events = POLLOUT | POLLERR;
        fds[1].fd = ctx->fd;
        fds[1].events = POLLIN | POLLPRI;

        pollret = poll(&fds, 2, -1);
        if (pollret < 0) {
                PDEBUG("%s: Poll returned error: %d\n", __func__, errno);
                return -1;
        }
        if (pollret == 0) {
                PDEBUG("%s: timed out\n", __func__);
                return -2;
        }
        for (int i = 0; i < 2; i++) {
                if (fds[i].revents & POLLOUT){
                        /* the OUTPUT(input) is ready */
                        PDEBUG("input can be dequeue\n");
                        return 0;
                }
                if (fds[i].revents & POLLIN){
                        /* the CAPTURE(output) is ready */
                        PDEBUG("output can be dequeue\n");
                        return 1;
                }
        }

        PDEBUG("unknown event\n");
        return -1;
}
> In addition I would recommend you to use more than one buffer per
> queue.
> 
Yes, I have, I have read your slide show(Video4Linux2: Path to a
Standardized Video Codec API in pdf format) and your source code, I
create 16 in OUTPUT and 4 for CAPTURE.
For the step 6, I mistaked before, I have enqueued all the buffers in
CAPTURE this time. Here is my poll code.

>> 
>> And the thing in the next is like this I think 11.filled input
>> buffer with the next frame 12.enqueue the next frame in the input
>> buffer in OUTPUT side 13.dequeue CAPTURE buffer and make output
>> buffer pointer to data of it. 14.dequeue OUTPUT goto 11 Is it
>> correct
>> 
>> I doubt the REAME 5. Request CAPTURE and OUTPUT buffers. Due to
>> hardware limitations of MFC on some platforms it is recommended
>> to use V4L2_MEMORY_MMAP buffers. 6. Enqueue CAPTURE buffers. 7.
>> Enqueue OUTPUT buffer with first frame. 8. Start streaming
>> (VIDIOC_STREAMON) on both ends. 9. Simultaneously: I don't need
>> to dequeue the OUTPUT buffer which is with first frame? - enqueue
>> buffers with next frames, - dequeue used OUTPUT buffers (blocking
>> operation), - dequeue buffers with encoded stream (blocking
>> operation), - enqueue free CAPTURE buffers.
>> 
>> 
>> Thank you.
> 
> Best wishes, Kamil
> 
> 
> 

Thank you very much

ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJSzXJdAAoJEPb4VsMIzTzipRsIAKc/D42jZzhOXX+7DawAU4o2
9VW4fTPMFV0J2CYcfhRKUdk7s1SLlfoSjqU5FpqopLpL4wGnfDQ4CnMp1VTlLrWy
qItNHRvhQfyd9GZXOAMQ9m5GnEh/TYPNvWB9v9jtwb4kv5FY5fOdW0e2yyCLmZCU
re808QxLhds4y4AViebF/YtRpfOTbSVcW8w6Z5YGEXJSZtu1M6ScQ/owxNjVPMPV
Eb6yrMheGwboY0Jo/7uofl/K15SFHH7FcBS7I2g7kLv0d8Uw3ZSDG4Tke6tSWtLj
gcS6gwhpprpxu1vgtYiUwwdMOKRk0LQiAQC2aIq/IKMdzvP/MjGhbIenq4LKg0c=
=y+7G
-----END PGP SIGNATURE-----

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

于 2014年01月08日 23:44, randy 写道:
> 于 2014年01月08日 22:42, Kamil Debski 写道:
>> Hi Randy,
> 
>> Please have a look at the V4L2_CID_MPEG_VIDEO_HEADER_MODE
>> control.
>>> From your description it seems that it is in its default state
>>> -
>>> 
>> V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE. This means that the header 
>> for a newly encoded stream is returned after init. Then in
>> another buffer you will find the encoded picture.
> 
> There is the lastest my step 1.request buffer. 2.mmap input buffer
> with OUTPUT 3.output buffer with CAPTURE. 4.filled input buffer
> with the first frame. 5.enqueue the first frame in the input buffer
> in OUTPUT side 6.enqueue the all output buffers in CAPTURE side 
> 7.start stream 8.poll blocking to wait OUTPUT or CAPTURE can be
> dequeue 9-1.if dequeued a CAPTURE buffer and get index from index
> from buffer which has been mapped with a output buffer. 9-2.get
> output data from output buffer and re-enqueue it. 9-3.got back to
> step 4 but filled the next frame. 10. if dequeued a OUTPUT buffer,
> then enqueue it and return to step 8 The first frame is 22 bytes
> but the second is the big size, the third is the same to the first
> and the forth is the same size to the second, but the others are
> all big sizes(about 140000 to 16000)
>> You can also try to set the V4L2_CID_MPEG_VIDEO_HEADER_MODE
>> control to V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME and
>> see if it works. (instead of enqueueing the CAPTURE buffer again
>> after receiving the header).
> 
> 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 think it is the progblem of my code. As I follow your code, the
> poll doesn't have timeout. int mfc_enc_output_available(struct
> mfc_enc_context *ctx) { int pollret; struct pollfd fds[2]; 
> fds[0].fd = ctx->fd; fds[0].events = POLLOUT | POLLERR; fds[1].fd =
> ctx->fd; fds[1].events = POLLIN | POLLPRI;
> 
> pollret = poll(&fds, 2, -1); if (pollret < 0) { PDEBUG("%s: Poll
> returned error: %d\n", __func__, errno); return -1; } if (pollret
> == 0) { PDEBUG("%s: timed out\n", __func__); return -2; } for (int
> i = 0; i < 2; i++) { if (fds[i].revents & POLLOUT){ /* the
> OUTPUT(input) is ready */ PDEBUG("input can be dequeue\n"); return
> 0; } if (fds[i].revents & POLLIN){ /* the CAPTURE(output) is ready
> */ PDEBUG("output can be dequeue\n"); return 1; } }
> 
> PDEBUG("unknown event\n"); return -1; }
>> In addition I would recommend you to use more than one buffer
>> per queue.
> 
> Yes, I have, I have read your slide show(Video4Linux2: Path to a 
> Standardized Video Codec API in pdf format) and your source code,
> I create 16 in OUTPUT and 4 for CAPTURE. For the step 6, I mistaked
> before, I have enqueued all the buffers in CAPTURE this time. Here
> is my poll code.
> 
>>> 
>>> And the thing in the next is like this I think 11.filled input 
>>> buffer with the next frame 12.enqueue the next frame in the
>>> input buffer in OUTPUT side 13.dequeue CAPTURE buffer and make
>>> output buffer pointer to data of it. 14.dequeue OUTPUT goto 11
>>> Is it correct
>>> 
>>> I doubt the REAME 5. Request CAPTURE and OUTPUT buffers. Due
>>> to hardware limitations of MFC on some platforms it is
>>> recommended to use V4L2_MEMORY_MMAP buffers. 6. Enqueue CAPTURE
>>> buffers. 7. Enqueue OUTPUT buffer with first frame. 8. Start
>>> streaming (VIDIOC_STREAMON) on both ends. 9. Simultaneously: I
>>> don't need to dequeue the OUTPUT buffer which is with first
>>> frame? - enqueue buffers with next frames, - dequeue used
>>> OUTPUT buffers (blocking operation), - dequeue buffers with
>>> encoded stream (blocking operation), - enqueue free CAPTURE
>>> buffers.
>>> 
>>> 
>>> Thank you.
> 
>> Best wishes, Kamil
> 
> 
> 
> 
> Thank you very much
> 
> ayaka
Thank you
ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJSz7pDAAoJEPb4VsMIzTziS/QIAJL1sd+2XNy4d/wzCYOL5mLv
xny5/7zWTtiW1Ti7s6pnxyed2RvhzQlSAWHM2nsk9AzCTdUVNmXCq3b4CF3aKSP3
7OhpqlFWCEb+uxW98FuH9PPvlR8PAnhhWTkdxtW6Xe3CpSZ7rVYaxrs36LWX3K1S
ntW3nfMwoecmtd45NUTtfajvwR3+kmS5IFzM7zdbIykzhf7aOvxQ9JdSqNBT97O3
/xk8XCFGAg9kDGcR9g95mZCEEDVgVBHNAM2WLtihV7kEcpOxe0q4FccXxngCWvQd
vYDYjpFYLjAYJzXM9P5BPCg7drDndCLof6fGeIG783J+OruOfTSrwuxVa7hsEzw=
=Uq4w
-----END PGP SIGNATURE-----

Re: using MFC memory to memery encoder, start stream and queue order problem

[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.
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.

Regards
Andrzej

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----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
> 
> 
> 
> 

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-----

Re: using MFC memory to memery encoder, start stream and queue order problem

[Andrzej Hajda]

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

>>
>>
>>
>>
> 
> 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-----
> 

Re: using MFC memory to memery encoder, start stream and queue order problem

[Andrzej Hajda]

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-----
>>
> 

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----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.
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?

>> Regards Andrzej
> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
> 
> Thank you ayaka
>>> 
>> 
> 
> 
> 
Thank you
ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJS1AnoAAoJEPb4VsMIzTzi5aUH/j2MT0YlzhMYtBrzkCGL1niM
iMJ7CprSTFZq8WLxb2OKN4/+WTwsbfEy3CAFmFtCXdhB7JeGeHLpj48vs5L7dtJt
CTc1QPHuAVpWNaL6/mP1gXEWOWZDXjIr70f2rG0lGhiS+t0PVri8+mukyu81Oc+w
AFFoWsuCAJgTKTT3qpWJEhHdEszHrrzfkOJoUa2PdITKZezhQHw4OBbsr1mVdfeJ
UcdYiHHKF40bsglXVfj8BgQ5oM3/Dx3IWowR8kymGJDPB+E18+fk/wogxOdILOYY
WQIC54t5dCdWV8rUVsEaWlHECm/BgHozPdLY6j6n0ou+VqFhlyDMwidcTZXGvKI=
=/COC
-----END PGP SIGNATURE-----

RE: using MFC memory to memery encoder, start stream and queue order problem

[Kamil Debski]

Hi,

> From: randy [mailto:lxr1234@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

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

于 2014年01月14日 00:18, Kamil Debski 写道:
> Hi,
> 
>> From: randy [mailto:lxr1234@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.
> 
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?
>> 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,

Re: using MFC memory to memery encoder, start stream and queue order problem

[Andrzej Hajda]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

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


[-- Attachment #2: 0001-Do-not-stop-encoding-after-empty-buffers.patch --]
[-- Type: text/x-patch, Size: 1126 bytes --]

>From bccf89a62a2e45cd45f4bf5d4adff9ec8a16b3bd Mon Sep 17 00:00:00 2001
From: Andrzej Hajda <a.hajda@samsung.com>
Date: Mon, 20 May 2013 09:24:23 +0200
Subject: [PATCH] Do not stop encoding after empty buffers

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
 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

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

于 2014年01月14日 18:29, Andrzej Hajda 写道:
> 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.
> 
No, it has been applied in public repo.
And my code is in applied version, but it doesn't work.
Here is the log
============================
mfc codec encoding example application
Andrzej Hajda <a.hajda@samsung.com>
Copyright 2012 Samsung Electronics Co., Ltd.

70.259455868:args.c:parse_args:190: codec: H264
70.259635952:args.c:parse_args:187: opt header_mode=1
mfc.c:mfc_create:85: error: Cannot subscribe EOS event for MFC
70.286725493:mfc.c:mfc_create:87: MFC device /dev/video1 opened with fd=3
70.294186576:v4l_dev.c:v4l_req_bufs:116: Succesfully requested 16
buffers for device 3:0
70.294508201:func_dev.c:func_req_bufs:42: Succesfully requested 16
buffers for device -1:1
70.294936410:func_dev.c:func_enq_buf:113: Enqueued buffer 0/16 to -1:1
70.295440952:func_dev.c:func_enq_buf:113: Enqueued buffer 1/16 to -1:1
70.295692535:func_dev.c:func_enq_buf:113: Enqueued buffer 2/16 to -1:1
70.295912035:func_dev.c:func_enq_buf:113: Enqueued buffer 3/16 to -1:1
70.296122285:func_dev.c:func_enq_buf:113: Enqueued buffer 4/16 to -1:1
70.296310368:func_dev.c:func_enq_buf:113: Enqueued buffer 5/16 to -1:1
70.296477410:func_dev.c:func_enq_buf:113: Enqueued buffer 6/16 to -1:1
70.296626993:func_dev.c:func_enq_buf:113: Enqueued buffer 7/16 to -1:1
70.296788618:func_dev.c:func_enq_buf:113: Enqueued buffer 8/16 to -1:1
70.296949910:func_dev.c:func_enq_buf:113: Enqueued buffer 9/16 to -1:1
70.297115327:func_dev.c:func_enq_buf:113: Enqueued buffer 10/16 to -1:1
70.297277993:func_dev.c:func_enq_buf:113: Enqueued buffer 11/16 to -1:1
70.297435618:func_dev.c:func_enq_buf:113: Enqueued buffer 12/16 to -1:1
70.297591993:func_dev.c:func_enq_buf:113: Enqueued buffer 13/16 to -1:1
70.297760868:func_dev.c:func_enq_buf:113: Enqueued buffer 14/16 to -1:1
70.297917910:func_dev.c:func_enq_buf:113: Enqueued buffer 15/16 to -1:1
70.336368993:v4l_dev.c:v4l_req_bufs:116: Succesfully requested 4
buffers for device 3:1
70.336587368:func_dev.c:func_req_bufs:42: Succesfully requested 4
buffers for device 4:0
70.342405784:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 0/4 to 3:1
70.348009117:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 1/4 to 3:1
70.352857159:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 2/4 to 3:1
70.357489076:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 3/4 to 3:1
State [enq cnt/max]: [Off 0 0/0|Rdy 16 0/1] [Off 0 0/0|Off 4 0/0] [Off
0 0/0|Off 0 0/0]
State [enq cnt/max]: [Off 0 0/0|Rdy 16 0/1] [Off 0 0/0|Off 4 0/0] [Off
0 0/0|Off 0 0/0]
70.357812534:func_dev.c:func_deq_buf:79: Dequeued buffer 0/16 from
- -1:1 ret=25344
70.357841701:func_dev.c:func_deq_buf:88: End on -1:1
70.357882201:v4l_dev.c:v4l_enq_buf:211: Enqueued buffer 0/16 to 3:0
70.357961534:v4l_dev.c:v4l_stream_set:76: Stream started on fd=3:0
70.358038117:v4l_dev.c:v4l_stream_set:92: Stream started on fd=3:1
70.358070659:v4l_dev.c:v4l_enq_buf:226: EOS sent to 3:0, ret=-1
State [enq cnt/max]: [Off 0 0/0|End 15 1/1] [Bus 1 0/1|Bus 4 0/0] [Off
0 0/0|Off 0 0/0]
70.358163367:io_dev.c:wait_for_ready_devs:64: Will poll fd=3 events=7
root@kagami:~/v4l2-mfc-encoder# ls -l demo.out
- -rw-r--r-- 1 root root 0 Jan 14 16:48 demo.out
> Regards Andrzej
> 

Thank you


						ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJS1Wq7AAoJEPb4VsMIzTziM/UH/0LSC7xRC35nzPhAPue8yFw+
/OMpCcM1OArsqKIGqrGNaDTnkePSkQ22/W1CbtbrJatpDmI1zLZOfJIK4w4PCd0E
LV/NoVqdr8N5aLsmrC5Ao7zXViCiSDVMxqyAGPXObXA+2IJDxf34yWAxTGIVYlo6
Q2B5EMWyF4GHBvF1shk/So0YF6RBpI8s6on54QoSaNon95dupsk1QQ0ceXmPj/6c
X/fI5M6etToml0txKpXD4auafLxb8ebZAn4ZHx2F69WFIJFozLL9FkYl6MizORkN
ke34+xhQUZ6NF4ykBtbCUHVacDegsbiW/ISKtpjxDoWLRcIZPy0BvuUE8guY/Uk=
=0BWS
-----END PGP SIGNATURE-----

Re: using MFC memory to memery encoder, start stream and queue order problem

[Andrzej Hajda]

On 01/14/2014 05:50 PM, randy wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 于 2014年01月14日 18:29, Andrzej Hajda 写道:
>> 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.
>>
> No, it has been applied in public repo.
> And my code is in applied version, but it doesn't work.
> Here is the log
> ============================
> mfc codec encoding example application
> Andrzej Hajda <a.hajda@samsung.com>
> Copyright 2012 Samsung Electronics Co., Ltd.
>
> 70.259455868:args.c:parse_args:190: codec: H264
> 70.259635952:args.c:parse_args:187: opt header_mode=1
> mfc.c:mfc_create:85: error: Cannot subscribe EOS event for MFC
This error shows that end-of-stream support is not implemented in the
MFC driver.
> 70.358070659:v4l_dev.c:v4l_enq_buf:226: EOS sent to 3:0, ret=-1
>
Ditto

Are you sure you have used kernel 3.12? Have you compiled the program with
proper kernel-headers?

Regards
Andrzej

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

于 2014年01月15日 15:08, Andrzej Hajda 写道:
> On 01/14/2014 05:50 PM, randy wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> 于 2014年01月14日 18:29, Andrzej Hajda 写道:
>>> 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.
>>>
>> No, it has been applied in public repo.
>> And my code is in applied version, but it doesn't work.
>> Here is the log
>> ============================
>> mfc codec encoding example application
>> Andrzej Hajda <a.hajda@samsung.com>
>> Copyright 2012 Samsung Electronics Co., Ltd.
>>
>> 70.259455868:args.c:parse_args:190: codec: H264
>> 70.259635952:args.c:parse_args:187: opt header_mode=1
>> mfc.c:mfc_create:85: error: Cannot subscribe EOS event for MFC
> This error shows that end-of-stream support is not implemented in the
> MFC driver.
>> 70.358070659:v4l_dev.c:v4l_enq_buf:226: EOS sent to 3:0, ret=-1
>>
> Ditto
> 
> Are you sure you have used kernel 3.12? Have you compiled the program with
> proper kernel-headers?
> 
Sorry, I forget to switch to new kernel,
but in new kernel it doesn't work too.
root@kagami:~/v4l2-mfc-encoder# ./mfc-encode -m /dev/video1 -c
h264,header_mode=1 -d 1
mfc codec encoding example application
Andrzej Hajda <a.hajda@samsung.com>
Copyright 2012 Samsung Electronics Co., Ltd.

106.984340799:args.c:parse_args:190: codec: H264
106.984870424:args.c:parse_args:187: opt header_mode=1
106.999434841:mfc.c:mfc_create:87: MFC device /dev/video1 opened with fd=3
107.15356632:v4l_dev.c:v4l_req_bufs:116: Succesfully requested 16
buffers for device 3:0
107.15534549:func_dev.c:func_req_bufs:42: Succesfully requested 16
buffers for device -1:1
107.15708424:func_dev.c:func_enq_buf:113: Enqueued buffer 0/16 to -1:1
107.15862049:func_dev.c:func_enq_buf:113: Enqueued buffer 1/16 to -1:1
107.16004132:func_dev.c:func_enq_buf:113: Enqueued buffer 2/16 to -1:1
107.16146841:func_dev.c:func_enq_buf:113: Enqueued buffer 3/16 to -1:1
107.16284799:func_dev.c:func_enq_buf:113: Enqueued buffer 4/16 to -1:1
107.16429049:func_dev.c:func_enq_buf:113: Enqueued buffer 5/16 to -1:1
107.16569382:func_dev.c:func_enq_buf:113: Enqueued buffer 6/16 to -1:1
107.16715257:func_dev.c:func_enq_buf:113: Enqueued buffer 7/16 to -1:1
107.16859924:func_dev.c:func_enq_buf:113: Enqueued buffer 8/16 to -1:1
107.17006674:func_dev.c:func_enq_buf:113: Enqueued buffer 9/16 to -1:1
107.17158466:func_dev.c:func_enq_buf:113: Enqueued buffer 10/16 to -1:1
107.17307132:func_dev.c:func_enq_buf:113: Enqueued buffer 11/16 to -1:1
107.17455632:func_dev.c:func_enq_buf:113: Enqueued buffer 12/16 to -1:1
107.17599216:func_dev.c:func_enq_buf:113: Enqueued buffer 13/16 to -1:1
107.17748299:func_dev.c:func_enq_buf:113: Enqueued buffer 14/16 to -1:1
107.17897341:func_dev.c:func_enq_buf:113: Enqueued buffer 15/16 to -1:1
v4l_dev.c:v4l_req_bufs:111: error: Failed to request 4 buffers for
device 3:1)
root@kagami:~/v4l2-mfc-encoder# ls -l demo.out
-rw-r--r-- 1 root root 0 Jan 15 15:49 demo.out
root@kagami:~/v4l2-mfc-encoder# uname -a
Linux kagami 3.13.0-rc8-00018-g8f39393-dirty #17 SMP PREEMPT Wed Jan 15
18:40:53 CST 2014 armv7l GNU/Linux
root@kagami:~/v4l2-mfc-encoder# dmesg|grep mfc
[    1.295000] s5p-mfc 13400000.codec: decoder registered as /dev/video0
[    1.295000] s5p-mfc 13400000.codec: encoder registered as /dev/video1
[  100.645000] s5p_mfc_alloc_priv_buf:43: Allocating private buffer failed
[  100.645000] s5p_mfc_alloc_codec_buffers_v5:177: Failed to allocate
Bank1 temporary buffer
[  107.065000] s5p_mfc_alloc_priv_buf:43: Allocating private buffer failed
[  107.065000] s5p_mfc_alloc_codec_buffers_v5:177: Failed to allocate
Bank1 temporary buffer

> Regards
> Andrzej
> 
> 
> 

Re: using MFC memory to memery encoder, start stream and queue order problem

[Andrzej Hajda]

On 01/15/2014 04:50 PM, randy wrote:
>
> Sorry, I forget to switch to new kernel,
> but in new kernel it doesn't work too.
> root@kagami:~/v4l2-mfc-encoder# ./mfc-encode -m /dev/video1 -c
> h264,header_mode=1 -d 1
> mfc codec encoding example application
> Andrzej Hajda <a.hajda@samsung.com>
> Copyright 2012 Samsung Electronics Co., Ltd.
>
> 106.984340799:args.c:parse_args:190: codec: H264
> 106.984870424:args.c:parse_args:187: opt header_mode=1
> 106.999434841:mfc.c:mfc_create:87: MFC device /dev/video1 opened with fd=3
> 107.15356632:v4l_dev.c:v4l_req_bufs:116: Succesfully requested 16
> buffers for device 3:0
> 107.15534549:func_dev.c:func_req_bufs:42: Succesfully requested 16
> buffers for device -1:1
> 107.15708424:func_dev.c:func_enq_buf:113: Enqueued buffer 0/16 to -1:1
> 107.15862049:func_dev.c:func_enq_buf:113: Enqueued buffer 1/16 to -1:1
> 107.16004132:func_dev.c:func_enq_buf:113: Enqueued buffer 2/16 to -1:1
> 107.16146841:func_dev.c:func_enq_buf:113: Enqueued buffer 3/16 to -1:1
> 107.16284799:func_dev.c:func_enq_buf:113: Enqueued buffer 4/16 to -1:1
> 107.16429049:func_dev.c:func_enq_buf:113: Enqueued buffer 5/16 to -1:1
> 107.16569382:func_dev.c:func_enq_buf:113: Enqueued buffer 6/16 to -1:1
> 107.16715257:func_dev.c:func_enq_buf:113: Enqueued buffer 7/16 to -1:1
> 107.16859924:func_dev.c:func_enq_buf:113: Enqueued buffer 8/16 to -1:1
> 107.17006674:func_dev.c:func_enq_buf:113: Enqueued buffer 9/16 to -1:1
> 107.17158466:func_dev.c:func_enq_buf:113: Enqueued buffer 10/16 to -1:1
> 107.17307132:func_dev.c:func_enq_buf:113: Enqueued buffer 11/16 to -1:1
> 107.17455632:func_dev.c:func_enq_buf:113: Enqueued buffer 12/16 to -1:1
> 107.17599216:func_dev.c:func_enq_buf:113: Enqueued buffer 13/16 to -1:1
> 107.17748299:func_dev.c:func_enq_buf:113: Enqueued buffer 14/16 to -1:1
> 107.17897341:func_dev.c:func_enq_buf:113: Enqueued buffer 15/16 to -1:1
> v4l_dev.c:v4l_req_bufs:111: error: Failed to request 4 buffers for
> device 3:1)
> root@kagami:~/v4l2-mfc-encoder# ls -l demo.out
> -rw-r--r-- 1 root root 0 Jan 15 15:49 demo.out
> root@kagami:~/v4l2-mfc-encoder# uname -a
> Linux kagami 3.13.0-rc8-00018-g8f39393-dirty #17 SMP PREEMPT Wed Jan 15
> 18:40:53 CST 2014 armv7l GNU/Linux
> root@kagami:~/v4l2-mfc-encoder# dmesg|grep mfc
> [    1.295000] s5p-mfc 13400000.codec: decoder registered as /dev/video0
> [    1.295000] s5p-mfc 13400000.codec: encoder registered as /dev/video1
> [  100.645000] s5p_mfc_alloc_priv_buf:43: Allocating private buffer failed
> [  100.645000] s5p_mfc_alloc_codec_buffers_v5:177: Failed to allocate
> Bank1 temporary buffer
> [  107.065000] s5p_mfc_alloc_priv_buf:43: Allocating private buffer failed
> [  107.065000] s5p_mfc_alloc_codec_buffers_v5:177: Failed to allocate
> Bank1 temporary buffer
Try to increase CMA size in kernel config - CONFIG_CMA_SIZE_MBYTES,
by default it is set to 16MB, try for example 64MB.

Regards
Andrzej

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

于 2014年01月16日 20:37, Andrzej Hajda 写道:
> On 01/15/2014 04:50 PM, randy wrote:
>> 
Sorry, again, I forget to enable CMA, as exynos4_defconf and MFC doesn't
depend on it. But 16MB can't work with the same log as below.
>> root@kagami:~/v4l2-mfc-encoder# ./mfc-encode -m /dev/video1 -c 
>> h264,header_mode=1 -d 1 mfc codec encoding example application 
>> Andrzej Hajda <a.hajda@samsung.com> Copyright 2012 Samsung
>> Electronics Co., Ltd.
>> 
>> 106.984340799:args.c:parse_args:190: codec: H264 
>> 106.984870424:args.c:parse_args:187: opt header_mode=1 
>> 106.999434841:mfc.c:mfc_create:87: MFC device /dev/video1 opened
>> with fd=3 107.15356632:v4l_dev.c:v4l_req_bufs:116: Succesfully
>> requested 16 buffers for device 3:0 
>> 107.15534549:func_dev.c:func_req_bufs:42: Succesfully requested
>> 16 buffers for device -1:1 
>> 107.15708424:func_dev.c:func_enq_buf:113: Enqueued buffer 0/16 to
>> -1:1 107.15862049:func_dev.c:func_enq_buf:113: Enqueued buffer
>> 1/16 to -1:1 107.16004132:func_dev.c:func_enq_buf:113: Enqueued
>> buffer 2/16 to -1:1 107.16146841:func_dev.c:func_enq_buf:113:
>> Enqueued buffer 3/16 to -1:1 
>> 107.16284799:func_dev.c:func_enq_buf:113: Enqueued buffer 4/16 to
>> -1:1 107.16429049:func_dev.c:func_enq_buf:113: Enqueued buffer
>> 5/16 to -1:1 107.16569382:func_dev.c:func_enq_buf:113: Enqueued
>> buffer 6/16 to -1:1 107.16715257:func_dev.c:func_enq_buf:113:
>> Enqueued buffer 7/16 to -1:1 
>> 107.16859924:func_dev.c:func_enq_buf:113: Enqueued buffer 8/16 to
>> -1:1 107.17006674:func_dev.c:func_enq_buf:113: Enqueued buffer
>> 9/16 to -1:1 107.17158466:func_dev.c:func_enq_buf:113: Enqueued
>> buffer 10/16 to -1:1 107.17307132:func_dev.c:func_enq_buf:113:
>> Enqueued buffer 11/16 to -1:1 
>> 107.17455632:func_dev.c:func_enq_buf:113: Enqueued buffer 12/16
>> to -1:1 107.17599216:func_dev.c:func_enq_buf:113: Enqueued buffer
>> 13/16 to -1:1 107.17748299:func_dev.c:func_enq_buf:113: Enqueued
>> buffer 14/16 to -1:1 107.17897341:func_dev.c:func_enq_buf:113:
>> Enqueued buffer 15/16 to -1:1 v4l_dev.c:v4l_req_bufs:111: error:
>> Failed to request 4 buffers for device 3:1)

> Try to increase CMA size in kernel config -
> CONFIG_CMA_SIZE_MBYTES, by default it is set to 16MB, try for
> example 64MB.
> 
If I change it to 64MB, I will got v4l_dev.c:v4l_enq_buf:207: error:
Error 22 enq buffer 0/16 to 3:0
and the below in dmesg as CONFIG_CMA_SIZE_MBYTES=64
root@kagami:~/v4l2-mfc-encoder# dmesg|grep mfc
[    1.295000] s5p-mfc 13400000.codec: decoder registered as /dev/video0
[    1.295000] s5p-mfc 13400000.codec: encoder registered as /dev/video1
[  146.975000] s5p_mfc_alloc_priv_buf:43: Allocating private buffer failed
[  146.975000] s5p_mfc_alloc_codec_buffers_v5:177: Failed to allocate
Bank1 temporary buffer
[  196.255000] s5p_mfc_alloc_priv_buf:43: Allocating private buffer failed
[  196.255000] s5p_mfc_alloc_codec_buffers_v5:186: Failed to allocate
Bank2 temporary buffer

> Regards Andrzej
> 
> 
> 
Thank you
ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJS2DNJAAoJEPb4VsMIzTzi2NkH/iotPpDrRerh2E1fJTlzZP0a
awcb+qtOfM7MkGAtMtdOTBtiFT8+R4xXMWFhKOcm22zBki+XBe5e2AIk/ekJLqlg
Xm4lVjM1cGR1wVYVwxRi7prnPTWIZKCi+NgA+lmmu1ASt0/A3hvqqARF7Wa/pKiI
+GDwfzBYhdLIKmfSCgz4bP8VWm//6ERevzBDLtXahjQqc/mCmudAYUfB31EhHrSY
J3b9V+zZOjmlSxm3wZezlS0y0SbAR1FWJa4XKcCiKpH08bqkUhwQnVEay4wsz05P
tnd9Fc/uRkAZVHWkKwHk2+HqHRpfBqWYO61/fwISf5tX9Mr6EOBivtauRcJPrHw=
=Ag18
-----END PGP SIGNATURE-----

Re: using MFC memory to memery encoder, start stream and queue order problem

[randy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> [  100.645000] s5p_mfc_alloc_codec_buffers_v5:177: Failed to 
>> allocate Bank1 temporary buffer [  107.065000] 
>> s5p_mfc_alloc_priv_buf:43: Allocating private buffer failed [ 
>> 107.065000] s5p_mfc_alloc_codec_buffers_v5:177: Failed to 
>> allocate Bank1 temporary buffer
> Try to increase CMA size in kernel config - CONFIG_CMA_SIZE_MBYTES,
> by default it is set to 16MB, try for example 64MB.
I am very sorry, I don't test it carefully, the mfc-encode can't work
on 3.13-rc8, with or without header_mode=1 it will got
v4l_dev.c:v4l_req_bufs:111: error: Failed to request 4 buffers for
device 3:1)
and
[ 1706.540000] s5p_mfc_alloc_codec_buffers_v5:177: Failed to allocate
Bank1 temporary buffer

In the old 3.5 kernel, it has this kind of problem too,
[    0.210000] Failed to declare coherent memory for MFC device (0
bytes at 0x43000000)

I wonder is there some problem of the board or core board. But it
seems that result of 3.5 is better(but without the I-frame, the
encoded data is useless as I know)

Thank you
ayaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJS2Dy3AAoJEPb4VsMIzTziYooH/3GxuPn2bt74QQF0fy8yZH+T
kE4K9F9JUValDfdQc0GBnFDRBb4CIbL4ncWoRhj4mjH3Iu3OOxWjRgEl/aZ+TzZg
3BJSTI9Wnaxt4sFCVJKHtYY9Ei7nv2548/hC2UzkrzmtPYIiUBmEarbI4rcrX3/Y
II1Oe8GoCvyyD7/BJ37ENKX1Y3O1ZvwZJvKaTRamAJQmJKpR5/wFvrRBqp1kLG5l
1LHJOM2qfWAB7HWlALDXpgYS8UhovHWPqWZj7tLKzLEibvRKqqD6+ZRY29nJTkED
KcvNY6pGv5vdoQoP6cHAWARg8WwGCR3brOXiPaNCp3GtsFfATEDHLhOIIc12vOg=
=fa3t
-----END PGP SIGNATURE-----