Streaming on low resource

Streaming on low resource

[ayman bs]

Hello,

I have an http stream in MPEG1/2 Video (mpgv)
Frame rate: 50 4000kb/s

It's basically the output of a satellite receiver with various resolutions.

480/576
544/576
720/576
704/576

Anyway, I have a P4 1.6GHZ with 512M RAM and 1024kb UL speed... I have
been trying to transcode and stream the signal to LAN, but my
principal intention is to stream to Internet. I'm using these options
in VLC which I found giving the best results.

Code:
:sout=#transcode{vcodec=mp4v,vb=650,fps=24,scale=0.5,acodec=mp3,ab=90,channels=1,samplerate=22050}:duplicate{dst=http{mux=ts,dst=:6666/},dst=display}
:no-sout-rtp-sap :no-sout-standard-sap :ttl=1 :sout-keep



I would like to ask you for any suggestion about any improvements...
I'm using Http because that's the only protocol I got running on
Internet... I got RTSP on LAN running but with no luck on Internet...
I'm doing NAT, so do you have any good experience with a particular
protocol.

I didn't see any difference with encapsulation methods, but I would be
pleased to hear your word.

Codecs: as you can see I'm using mp4 + mp3, the scale 0.5 is
sufficient but could you propose other parameters?

If I ever wanted to update the hardware what would be the priority,
CPU or RAM... I know both are needed...

Finally, I'm streaming from ubuntu 10.10 and any specific lightweight
distribution is welcome... as well as any other program similar to
VLC.

Thank you!

SOC-Camera VIDIOC_ENUM_FRAMESIZES interface?

[Qing Xu]

Hi,

We are now trying to adapt to soc-camera framework, though we have one question when reviewing the source code about V4L2_VIDIOC_ENUM_FRAMESIZE:

We find that there is no vidioc_enum_framesizes implementation in soc-camera.c.

Do you feel it's reasonable to add it into soc-camera about vidioc_enum_framesizes, so that the application knows how many frame-size is supported by camera driver, and then show all the size options in UI, then allow user to choose one size from the list.

Any ideas will be appreciated!

Thanks!
Qing Xu


Email: qingx@marvell.com
Application Processor Systems Engineering
Marvell Technology Group Ltd.

Re: SOC-Camera VIDIOC_ENUM_FRAMESIZES interface?

[Guennadi Liakhovetski]

Hi

On Tue, 4 Jan 2011, Qing Xu wrote:

> Hi,
> 
> We are now trying to adapt to soc-camera framework, though we have one 
> question when reviewing the source code about 
> V4L2_VIDIOC_ENUM_FRAMESIZE:
> 
> We find that there is no vidioc_enum_framesizes implementation in 
> soc-camera.c.
> 
> Do you feel it's reasonable to add it into soc-camera about 
> vidioc_enum_framesizes, so that the application knows how many 
> frame-size is supported by camera driver, and then show all the size 
> options in UI, then allow user to choose one size from the list.

So far this has been an optional ioctl() and no soc-camera set up had a 
need to support it. However, if you do need it for some reason, we 
certainly can look into adding it.

Thanks
Guennadi

> Any ideas will be appreciated!
> 
> Thanks!
> Qing Xu
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

soc-camera s_fmt question?

[Qing Xu]

Hi,

We are now nearly complete porting our camera driver to align with soc-camera framework, however, we encounter a problem when it works with our application during switch format from preview to still capture, application's main calling sequence is as follow:
1) s_fmt /* preview @ YUV, VGA */
2) request buffer (buffer count = 6)
2) queue buffer
3) stream on
4) q-buf, dq-buf...
5) stream off

6) s_fmt /* still capture @ jpeg, 2592x1944*/
7) request buffer (buffer count = 3)
8) same as 3)->5)...

The point is in soc_camera_s_fmt_vid_cap() {
        if (icd->vb_vidq.bufs[0]) {
                dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
                ret = -EBUSY;
                goto unlock;
        }
}
We didn't find vb_vidq.bufs[0] be free, (it is freed in videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first and then allocated sequentially), so we always fail at calling s_fmt.
My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide application opportunity to free this buffer node, refer to v4l2 spec, http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
"A count value of zero frees all buffers, after aborting or finishing any DMA in progress, an implicit VIDIOC_STREAMOFF."

What do you think?

Any ideas will be appreciated!
Thanks!
Qing Xu

Email: qingx@marvell.com
Application Processor Systems Engineering,
Marvell Technology Group Ltd.

Re: soc-camera s_fmt question?

[Guennadi Liakhovetski]

On Mon, 17 Jan 2011, Qing Xu wrote:

> Hi,
> 
> We are now nearly complete porting our camera driver to align with 
> soc-camera framework, however, we encounter a problem when it works with 
> our application during switch format from preview to still capture, 
> application's main calling sequence is as follow:
> 1) s_fmt /* preview @ YUV, VGA */
> 2) request buffer (buffer count = 6)
> 2) queue buffer
> 3) stream on
> 4) q-buf, dq-buf...
> 5) stream off
> 
> 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> 7) request buffer (buffer count = 3)
> 8) same as 3)->5)...
> 
> The point is in soc_camera_s_fmt_vid_cap() {
>         if (icd->vb_vidq.bufs[0]) {
>                 dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
>                 ret = -EBUSY;
>                 goto unlock;
>         }
> }
> We didn't find vb_vidq.bufs[0] be free, (it is freed in 
> videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls 
> videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first 
> and then allocated sequentially), so we always fail at calling s_fmt.
> My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide 
> application opportunity to free this buffer node, refer to v4l2 spec, 
> http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> "A count value of zero frees all buffers, after aborting or finishing 
> any DMA in progress, an implicit VIDIOC_STREAMOFF."

Currently buffers are freed in soc-camera upon close(). Yes, I know about 
that clause in the API spec, and I know, that it is unimplemented in 
soc-camera. Do you have a reason to prefer that over close()ing and 
re-open()ing the device?

Thanks
Guennadi

> 
> What do you think?
> 
> Any ideas will be appreciated!
> Thanks!
> Qing Xu
> 
> Email: qingx@marvell.com
> Application Processor Systems Engineering,
> Marvell Technology Group Ltd.
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: soc-camera s_fmt question?

[Hans Verkuil]

On Monday, January 17, 2011 18:43:06 Guennadi Liakhovetski wrote:
> On Mon, 17 Jan 2011, Qing Xu wrote:
> 
> > Hi,
> > 
> > We are now nearly complete porting our camera driver to align with 
> > soc-camera framework, however, we encounter a problem when it works with 
> > our application during switch format from preview to still capture, 
> > application's main calling sequence is as follow:
> > 1) s_fmt /* preview @ YUV, VGA */
> > 2) request buffer (buffer count = 6)
> > 2) queue buffer
> > 3) stream on
> > 4) q-buf, dq-buf...
> > 5) stream off
> > 
> > 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> > 7) request buffer (buffer count = 3)
> > 8) same as 3)->5)...
> > 
> > The point is in soc_camera_s_fmt_vid_cap() {
> >         if (icd->vb_vidq.bufs[0]) {
> >                 dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
> >                 ret = -EBUSY;
> >                 goto unlock;
> >         }
> > }
> > We didn't find vb_vidq.bufs[0] be free, (it is freed in 
> > videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls 
> > videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first 
> > and then allocated sequentially), so we always fail at calling s_fmt.
> > My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide 
> > application opportunity to free this buffer node, refer to v4l2 spec, 
> > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> > "A count value of zero frees all buffers, after aborting or finishing 
> > any DMA in progress, an implicit VIDIOC_STREAMOFF."
> 
> Currently buffers are freed in soc-camera upon close(). Yes, I know about 
> that clause in the API spec, and I know, that it is unimplemented in 
> soc-camera. Do you have a reason to prefer that over close()ing and 
> re-open()ing the device?

I think it would be a good idea to look into converting soc_camera to the
new videobuf2 framework that was just merged. It has much better semantics
when it comes to allocating and freeing queues. You can actually understand
it, something that you can't say for the old videobuf. And videobuf2 does
the right thing with REQBUFS(0) as well.

Regards,

	Hans

> 
> Thanks
> Guennadi
> 
> > 
> > What do you think?
> > 
> > Any ideas will be appreciated!
> > Thanks!
> > Qing Xu
> > 
> > Email: qingx@marvell.com
> > Application Processor Systems Engineering,
> > Marvell Technology Group Ltd.
> > 
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

RE: soc-camera s_fmt question?

[Qing Xu]

Hi Guennadi,

In close(), the sensor/camera controller will be totally powered-off/clock-off, then in open(), we will set hundreds of default values into sensor's registers by I2C, to enable/configure sensor to a default status, it takes too much time(several seconds) to switch from preview to still capture that our customers can not bear.
So, instead, when switch format, our application just calls stream-off/stream-on, as in stream-off(), we put the sensor/camera controller to a pause state, once switch format, we only need to set several sensor registers, it takes a little time to switch from preview to still capture.

And, further more, during preview, customers would like to set some special effect to image, such as turning color to blue, changing the brightness, etc, when they capture the picture, they would hope the picture looks the same as the what they change during preview, so, our application does not totally close() camera, just stream-off(), in this way, the registers values are kept in sensor, those special effect status is also kept.

The 2 reasons above make our application will not close/open, but just stream-off/stream-on during switching format from preview to still capture.

Thanks!
-Qing

-----Original Message-----
From: Guennadi Liakhovetski [mailto:g.liakhovetski@gmx.de]
Sent: 2011年1月18日 1:43
To: Qing Xu
Cc: Laurent Pinchart; linux-media@vger.kernel.org
Subject: Re: soc-camera s_fmt question?

On Mon, 17 Jan 2011, Qing Xu wrote:

> Hi,
>
> We are now nearly complete porting our camera driver to align with
> soc-camera framework, however, we encounter a problem when it works with
> our application during switch format from preview to still capture,
> application's main calling sequence is as follow:
> 1) s_fmt /* preview @ YUV, VGA */
> 2) request buffer (buffer count = 6)
> 2) queue buffer
> 3) stream on
> 4) q-buf, dq-buf...
> 5) stream off
>
> 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> 7) request buffer (buffer count = 3)
> 8) same as 3)->5)...
>
> The point is in soc_camera_s_fmt_vid_cap() {
>         if (icd->vb_vidq.bufs[0]) {
>                 dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
>                 ret = -EBUSY;
>                 goto unlock;
>         }
> }
> We didn't find vb_vidq.bufs[0] be free, (it is freed in
> videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls
> videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first
> and then allocated sequentially), so we always fail at calling s_fmt.
> My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide
> application opportunity to free this buffer node, refer to v4l2 spec,
> http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> "A count value of zero frees all buffers, after aborting or finishing
> any DMA in progress, an implicit VIDIOC_STREAMOFF."

Currently buffers are freed in soc-camera upon close(). Yes, I know about
that clause in the API spec, and I know, that it is unimplemented in
soc-camera. Do you have a reason to prefer that over close()ing and
re-open()ing the device?

Thanks
Guennadi

>
> What do you think?
>
> Any ideas will be appreciated!
> Thanks!
> Qing Xu
>
> Email: qingx@marvell.com
> Application Processor Systems Engineering,
> Marvell Technology Group Ltd.
>

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

RE: soc-camera s_fmt question?

[Qing Xu]

Hi,

Thanks for your answer! So, we will be waiting and keeping sync with latest soc-camera + videobuf2 framework.

-Qing

-----Original Message-----
From: Hans Verkuil [mailto:hverkuil@xs4all.nl]
Sent: 2011年1月18日 1:54
To: Guennadi Liakhovetski
Cc: Qing Xu; Laurent Pinchart; linux-media@vger.kernel.org
Subject: Re: soc-camera s_fmt question?

On Monday, January 17, 2011 18:43:06 Guennadi Liakhovetski wrote:
> On Mon, 17 Jan 2011, Qing Xu wrote:
>
> > Hi,
> >
> > We are now nearly complete porting our camera driver to align with
> > soc-camera framework, however, we encounter a problem when it works with
> > our application during switch format from preview to still capture,
> > application's main calling sequence is as follow:
> > 1) s_fmt /* preview @ YUV, VGA */
> > 2) request buffer (buffer count = 6)
> > 2) queue buffer
> > 3) stream on
> > 4) q-buf, dq-buf...
> > 5) stream off
> >
> > 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> > 7) request buffer (buffer count = 3)
> > 8) same as 3)->5)...
> >
> > The point is in soc_camera_s_fmt_vid_cap() {
> >         if (icd->vb_vidq.bufs[0]) {
> >                 dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
> >                 ret = -EBUSY;
> >                 goto unlock;
> >         }
> > }
> > We didn't find vb_vidq.bufs[0] be free, (it is freed in
> > videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls
> > videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first
> > and then allocated sequentially), so we always fail at calling s_fmt.
> > My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide
> > application opportunity to free this buffer node, refer to v4l2 spec,
> > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> > "A count value of zero frees all buffers, after aborting or finishing
> > any DMA in progress, an implicit VIDIOC_STREAMOFF."
>
> Currently buffers are freed in soc-camera upon close(). Yes, I know about
> that clause in the API spec, and I know, that it is unimplemented in
> soc-camera. Do you have a reason to prefer that over close()ing and
> re-open()ing the device?

I think it would be a good idea to look into converting soc_camera to the
new videobuf2 framework that was just merged. It has much better semantics
when it comes to allocating and freeing queues. You can actually understand
it, something that you can't say for the old videobuf. And videobuf2 does
the right thing with REQBUFS(0) as well.

Regards,

        Hans

>
> Thanks
> Guennadi
>
> >
> > What do you think?
> >
> > Any ideas will be appreciated!
> > Thanks!
> > Qing Xu
> >
> > Email: qingx@marvell.com
> > Application Processor Systems Engineering,
> > Marvell Technology Group Ltd.
> >
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: soc-camera s_fmt question?

[Hans Verkuil]

On Tuesday, January 18, 2011 03:30:09 Qing Xu wrote:
> Hi,
> 
> Thanks for your answer! So, we will be waiting and keeping sync with latest soc-camera + videobuf2 framework.

Erm, just to avoid any confusion: I am *not* going to convert soc-camera
to videobuf2. I just mentioned it because if someone does, then that should
fix your problems with REQBUFS(0) (and probably STREAMON/OFF problems as well).

I think soc-camera will benefit a lot from such a move so I hope someone
(Guennadi? You?) will take on this job.

Regards,

	Hans

> 
> -Qing
> 
> -----Original Message-----
> From: Hans Verkuil [mailto:hverkuil@xs4all.nl]
> Sent: 2011年1月18日 1:54
> To: Guennadi Liakhovetski
> Cc: Qing Xu; Laurent Pinchart; linux-media@vger.kernel.org
> Subject: Re: soc-camera s_fmt question?
> 
> On Monday, January 17, 2011 18:43:06 Guennadi Liakhovetski wrote:
> > On Mon, 17 Jan 2011, Qing Xu wrote:
> >
> > > Hi,
> > >
> > > We are now nearly complete porting our camera driver to align with
> > > soc-camera framework, however, we encounter a problem when it works with
> > > our application during switch format from preview to still capture,
> > > application's main calling sequence is as follow:
> > > 1) s_fmt /* preview @ YUV, VGA */
> > > 2) request buffer (buffer count = 6)
> > > 2) queue buffer
> > > 3) stream on
> > > 4) q-buf, dq-buf...
> > > 5) stream off
> > >
> > > 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> > > 7) request buffer (buffer count = 3)
> > > 8) same as 3)->5)...
> > >
> > > The point is in soc_camera_s_fmt_vid_cap() {
> > >         if (icd->vb_vidq.bufs[0]) {
> > >                 dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
> > >                 ret = -EBUSY;
> > >                 goto unlock;
> > >         }
> > > }
> > > We didn't find vb_vidq.bufs[0] be free, (it is freed in
> > > videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls
> > > videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first
> > > and then allocated sequentially), so we always fail at calling s_fmt.
> > > My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide
> > > application opportunity to free this buffer node, refer to v4l2 spec,
> > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> > > "A count value of zero frees all buffers, after aborting or finishing
> > > any DMA in progress, an implicit VIDIOC_STREAMOFF."
> >
> > Currently buffers are freed in soc-camera upon close(). Yes, I know about
> > that clause in the API spec, and I know, that it is unimplemented in
> > soc-camera. Do you have a reason to prefer that over close()ing and
> > re-open()ing the device?
> 
> I think it would be a good idea to look into converting soc_camera to the
> new videobuf2 framework that was just merged. It has much better semantics
> when it comes to allocating and freeing queues. You can actually understand
> it, something that you can't say for the old videobuf. And videobuf2 does
> the right thing with REQBUFS(0) as well.
> 
> Regards,
> 
>         Hans
> 
> >
> > Thanks
> > Guennadi
> >
> > >
> > > What do you think?
> > >
> > > Any ideas will be appreciated!
> > > Thanks!
> > > Qing Xu
> > >
> > > Email: qingx@marvell.com
> > > Application Processor Systems Engineering,
> > > Marvell Technology Group Ltd.
> > >
> >
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> --
> Hans Verkuil - video4linux developer - sponsored by Cisco
> �翳�.n�����+%��遍荻\x17�w��.n��伐�{炳g����n�r■�����ㄨ&｛�夸z罐����zf＂������������赙z_璁\x0f�:+v�)撸�
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: soc-camera s_fmt question?

[Guennadi Liakhovetski]

On Tue, 18 Jan 2011, Hans Verkuil wrote:

> On Tuesday, January 18, 2011 03:30:09 Qing Xu wrote:
> > Hi,
> > 
> > Thanks for your answer! So, we will be waiting and keeping sync with latest soc-camera + videobuf2 framework.
> 
> Erm, just to avoid any confusion: I am *not* going to convert soc-camera
> to videobuf2. I just mentioned it because if someone does, then that should
> fix your problems with REQBUFS(0) (and probably STREAMON/OFF problems as well).
> 
> I think soc-camera will benefit a lot from such a move so I hope someone
> (Guennadi? You?) will take on this job.

Yeah. I'll try to find some time to look at it... Just no idea when. 
What's the status of videobuf2, actually? Is it something, that all 
drivers better be converted to, just because it's better? It is also 
orthogonal to the forthcoming mc, so, that when converting to it some time 
soon, the time, spent to convert to videobuf2 won't be wasted?

Thanks
Guennadi

> Regards,
> 
> 	Hans
> 
> > 
> > -Qing
> > 
> > -----Original Message-----
> > From: Hans Verkuil [mailto:hverkuil@xs4all.nl]
> > Sent: 2011年1月18日 1:54
> > To: Guennadi Liakhovetski
> > Cc: Qing Xu; Laurent Pinchart; linux-media@vger.kernel.org
> > Subject: Re: soc-camera s_fmt question?
> > 
> > On Monday, January 17, 2011 18:43:06 Guennadi Liakhovetski wrote:
> > > On Mon, 17 Jan 2011, Qing Xu wrote:
> > >
> > > > Hi,
> > > >
> > > > We are now nearly complete porting our camera driver to align with
> > > > soc-camera framework, however, we encounter a problem when it works with
> > > > our application during switch format from preview to still capture,
> > > > application's main calling sequence is as follow:
> > > > 1) s_fmt /* preview @ YUV, VGA */
> > > > 2) request buffer (buffer count = 6)
> > > > 2) queue buffer
> > > > 3) stream on
> > > > 4) q-buf, dq-buf...
> > > > 5) stream off
> > > >
> > > > 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> > > > 7) request buffer (buffer count = 3)
> > > > 8) same as 3)->5)...
> > > >
> > > > The point is in soc_camera_s_fmt_vid_cap() {
> > > >         if (icd->vb_vidq.bufs[0]) {
> > > >                 dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
> > > >                 ret = -EBUSY;
> > > >                 goto unlock;
> > > >         }
> > > > }
> > > > We didn't find vb_vidq.bufs[0] be free, (it is freed in
> > > > videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls
> > > > videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first
> > > > and then allocated sequentially), so we always fail at calling s_fmt.
> > > > My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide
> > > > application opportunity to free this buffer node, refer to v4l2 spec,
> > > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> > > > "A count value of zero frees all buffers, after aborting or finishing
> > > > any DMA in progress, an implicit VIDIOC_STREAMOFF."
> > >
> > > Currently buffers are freed in soc-camera upon close(). Yes, I know about
> > > that clause in the API spec, and I know, that it is unimplemented in
> > > soc-camera. Do you have a reason to prefer that over close()ing and
> > > re-open()ing the device?
> > 
> > I think it would be a good idea to look into converting soc_camera to the
> > new videobuf2 framework that was just merged. It has much better semantics
> > when it comes to allocating and freeing queues. You can actually understand
> > it, something that you can't say for the old videobuf. And videobuf2 does
> > the right thing with REQBUFS(0) as well.
> > 
> > Regards,
> > 
> >         Hans
> > 
> > >
> > > Thanks
> > > Guennadi
> > >
> > > >
> > > > What do you think?
> > > >
> > > > Any ideas will be appreciated!
> > > > Thanks!
> > > > Qing Xu
> > > >
> > > > Email: qingx@marvell.com
> > > > Application Processor Systems Engineering,
> > > > Marvell Technology Group Ltd.
> > > >
> > >
> > > ---
> > > Guennadi Liakhovetski, Ph.D.
> > > Freelance Open-Source Software Developer
> > > http://www.open-technology.de/
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > 
> > --
> > Hans Verkuil - video4linux developer - sponsored by Cisco
> > �翳�.n�����+%��遍荻\x17�w��.n��伐�{炳g����n�r■�����ㄨ&｛�夸z罐����zf＂������������赙z_璁\x0f�:+v�)撸�
> > 
> > 
> 
> -- 
> Hans Verkuil - video4linux developer - sponsored by Cisco
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: soc-camera s_fmt question?

[Hans Verkuil]

On Tuesday, January 18, 2011 08:44:28 Guennadi Liakhovetski wrote:
> On Tue, 18 Jan 2011, Hans Verkuil wrote:
> 
> > On Tuesday, January 18, 2011 03:30:09 Qing Xu wrote:
> > > Hi,
> > > 
> > > Thanks for your answer! So, we will be waiting and keeping sync with latest soc-camera + videobuf2 framework.
> > 
> > Erm, just to avoid any confusion: I am *not* going to convert soc-camera
> > to videobuf2. I just mentioned it because if someone does, then that should
> > fix your problems with REQBUFS(0) (and probably STREAMON/OFF problems as well).
> > 
> > I think soc-camera will benefit a lot from such a move so I hope someone
> > (Guennadi? You?) will take on this job.
> 
> Yeah. I'll try to find some time to look at it... Just no idea when. 
> What's the status of videobuf2, actually?

Merged last weekend, will go into 2.6.38.

> Is it something, that all 
> drivers better be converted to, just because it's better?

Yes, all existing videobuf drivers should (over time) be converted to vb2.
All new drivers should use vb2 as well.

> It is also 
> orthogonal to the forthcoming mc, so, that when converting to it some time 
> soon, the time, spent to convert to videobuf2 won't be wasted?

It is unrelated to the mc. They don't have any impact on each other.

Main features it adds: it actually conforms to the V4L2 spec, deterministic
and documented behavior, multi-planar support, separate memory handling ops.
In the long term it should also make it possible to move buffers from one
V4L2 device to another.

Regards,

	Hans

> 
> Thanks
> Guennadi
> 
> > Regards,
> > 
> > 	Hans
> > 
> > > 
> > > -Qing
> > > 
> > > -----Original Message-----
> > > From: Hans Verkuil [mailto:hverkuil@xs4all.nl]
> > > Sent: 2011年1月18日 1:54
> > > To: Guennadi Liakhovetski
> > > Cc: Qing Xu; Laurent Pinchart; linux-media@vger.kernel.org
> > > Subject: Re: soc-camera s_fmt question?
> > > 
> > > On Monday, January 17, 2011 18:43:06 Guennadi Liakhovetski wrote:
> > > > On Mon, 17 Jan 2011, Qing Xu wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > We are now nearly complete porting our camera driver to align with
> > > > > soc-camera framework, however, we encounter a problem when it works with
> > > > > our application during switch format from preview to still capture,
> > > > > application's main calling sequence is as follow:
> > > > > 1) s_fmt /* preview @ YUV, VGA */
> > > > > 2) request buffer (buffer count = 6)
> > > > > 2) queue buffer
> > > > > 3) stream on
> > > > > 4) q-buf, dq-buf...
> > > > > 5) stream off
> > > > >
> > > > > 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> > > > > 7) request buffer (buffer count = 3)
> > > > > 8) same as 3)->5)...
> > > > >
> > > > > The point is in soc_camera_s_fmt_vid_cap() {
> > > > >         if (icd->vb_vidq.bufs[0]) {
> > > > >                 dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
> > > > >                 ret = -EBUSY;
> > > > >                 goto unlock;
> > > > >         }
> > > > > }
> > > > > We didn't find vb_vidq.bufs[0] be free, (it is freed in
> > > > > videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls
> > > > > videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first
> > > > > and then allocated sequentially), so we always fail at calling s_fmt.
> > > > > My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide
> > > > > application opportunity to free this buffer node, refer to v4l2 spec,
> > > > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> > > > > "A count value of zero frees all buffers, after aborting or finishing
> > > > > any DMA in progress, an implicit VIDIOC_STREAMOFF."
> > > >
> > > > Currently buffers are freed in soc-camera upon close(). Yes, I know about
> > > > that clause in the API spec, and I know, that it is unimplemented in
> > > > soc-camera. Do you have a reason to prefer that over close()ing and
> > > > re-open()ing the device?
> > > 
> > > I think it would be a good idea to look into converting soc_camera to the
> > > new videobuf2 framework that was just merged. It has much better semantics
> > > when it comes to allocating and freeing queues. You can actually understand
> > > it, something that you can't say for the old videobuf. And videobuf2 does
> > > the right thing with REQBUFS(0) as well.
> > > 
> > > Regards,
> > > 
> > >         Hans
> > > 
> > > >
> > > > Thanks
> > > > Guennadi
> > > >
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Any ideas will be appreciated!
> > > > > Thanks!
> > > > > Qing Xu
> > > > >
> > > > > Email: qingx@marvell.com
> > > > > Application Processor Systems Engineering,
> > > > > Marvell Technology Group Ltd.
> > > > >
> > > >
> > > > ---
> > > > Guennadi Liakhovetski, Ph.D.
> > > > Freelance Open-Source Software Developer
> > > > http://www.open-technology.de/
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > >
> > > 
> > > --
> > > Hans Verkuil - video4linux developer - sponsored by Cisco
> > > �翳�.n�����+%��遍荻\x17�w��.n��伐�{炳g����n�r■�����ㄨ&｛�夸z罐����zf＂������������赙z_璁\x0f�:+v�)撸�
> > > 
> > > 
> > 
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: soc-camera s_fmt question?

[Guennadi Liakhovetski]

On Mon, 17 Jan 2011, Hans Verkuil wrote:

> On Monday, January 17, 2011 18:43:06 Guennadi Liakhovetski wrote:
> > On Mon, 17 Jan 2011, Qing Xu wrote:
> > 
> > > Hi,
> > > 
> > > We are now nearly complete porting our camera driver to align with 
> > > soc-camera framework, however, we encounter a problem when it works with 
> > > our application during switch format from preview to still capture, 
> > > application's main calling sequence is as follow:
> > > 1) s_fmt /* preview @ YUV, VGA */
> > > 2) request buffer (buffer count = 6)
> > > 2) queue buffer
> > > 3) stream on
> > > 4) q-buf, dq-buf...
> > > 5) stream off
> > > 
> > > 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> > > 7) request buffer (buffer count = 3)
> > > 8) same as 3)->5)...
> > > 
> > > The point is in soc_camera_s_fmt_vid_cap() {
> > >         if (icd->vb_vidq.bufs[0]) {
> > >                 dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
> > >                 ret = -EBUSY;
> > >                 goto unlock;
> > >         }
> > > }
> > > We didn't find vb_vidq.bufs[0] be free, (it is freed in 
> > > videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls 
> > > videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first 
> > > and then allocated sequentially), so we always fail at calling s_fmt.
> > > My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide 
> > > application opportunity to free this buffer node, refer to v4l2 spec, 
> > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> > > "A count value of zero frees all buffers, after aborting or finishing 
> > > any DMA in progress, an implicit VIDIOC_STREAMOFF."
> > 
> > Currently buffers are freed in soc-camera upon close(). Yes, I know about 
> > that clause in the API spec, and I know, that it is unimplemented in 
> > soc-camera. Do you have a reason to prefer that over close()ing and 
> > re-open()ing the device?
> 
> I think it would be a good idea to look into converting soc_camera to the
> new videobuf2 framework that was just merged. It has much better semantics
> when it comes to allocating and freeing queues. You can actually understand
> it, something that you can't say for the old videobuf. And videobuf2 does
> the right thing with REQBUFS(0) as well.

Qing Xu, you could try videobuf2 now: 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/28658 
(please, use v2 of patches).

Thanks
Guennadi

> 
> Regards,
> 
> 	Hans
> 
> > 
> > Thanks
> > Guennadi
> > 
> > > 
> > > What do you think?
> > > 
> > > Any ideas will be appreciated!
> > > Thanks!
> > > Qing Xu
> > > 
> > > Email: qingx@marvell.com
> > > Application Processor Systems Engineering,
> > > Marvell Technology Group Ltd.
> > > 
> > 
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> -- 
> Hans Verkuil - video4linux developer - sponsored by Cisco
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

RE: soc-camera s_fmt question?

[Qing Xu]

Thanks for your information! I could try it on our driver.

-Qing

-----Original Message-----
From: Guennadi Liakhovetski [mailto:g.liakhovetski@gmx.de]
Sent: 2011年1月30日 2:10
To: Hans Verkuil
Cc: Qing Xu; Laurent Pinchart; linux-media@vger.kernel.org
Subject: Re: soc-camera s_fmt question?

On Mon, 17 Jan 2011, Hans Verkuil wrote:

> On Monday, January 17, 2011 18:43:06 Guennadi Liakhovetski wrote:
> > On Mon, 17 Jan 2011, Qing Xu wrote:
> >
> > > Hi,
> > >
> > > We are now nearly complete porting our camera driver to align with
> > > soc-camera framework, however, we encounter a problem when it works with
> > > our application during switch format from preview to still capture,
> > > application's main calling sequence is as follow:
> > > 1) s_fmt /* preview @ YUV, VGA */
> > > 2) request buffer (buffer count = 6)
> > > 2) queue buffer
> > > 3) stream on
> > > 4) q-buf, dq-buf...
> > > 5) stream off
> > >
> > > 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> > > 7) request buffer (buffer count = 3)
> > > 8) same as 3)->5)...
> > >
> > > The point is in soc_camera_s_fmt_vid_cap() {
> > >         if (icd->vb_vidq.bufs[0]) {
> > >                 dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
> > >                 ret = -EBUSY;
> > >                 goto unlock;
> > >         }
> > > }
> > > We didn't find vb_vidq.bufs[0] be free, (it is freed in
> > > videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls
> > > videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first
> > > and then allocated sequentially), so we always fail at calling s_fmt.
> > > My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide
> > > application opportunity to free this buffer node, refer to v4l2 spec,
> > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> > > "A count value of zero frees all buffers, after aborting or finishing
> > > any DMA in progress, an implicit VIDIOC_STREAMOFF."
> >
> > Currently buffers are freed in soc-camera upon close(). Yes, I know about
> > that clause in the API spec, and I know, that it is unimplemented in
> > soc-camera. Do you have a reason to prefer that over close()ing and
> > re-open()ing the device?
>
> I think it would be a good idea to look into converting soc_camera to the
> new videobuf2 framework that was just merged. It has much better semantics
> when it comes to allocating and freeing queues. You can actually understand
> it, something that you can't say for the old videobuf. And videobuf2 does
> the right thing with REQBUFS(0) as well.

Qing Xu, you could try videobuf2 now:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/28658
(please, use v2 of patches).

Thanks
Guennadi

>
> Regards,
>
>       Hans
>
> >
> > Thanks
> > Guennadi
> >
> > >
> > > What do you think?
> > >
> > > Any ideas will be appreciated!
> > > Thanks!
> > > Qing Xu
> > >
> > > Email: qingx@marvell.com
> > > Application Processor Systems Engineering,
> > > Marvell Technology Group Ltd.
> > >
> >
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
>
> --
> Hans Verkuil - video4linux developer - sponsored by Cisco
>

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/