On Fri, Sep 05, 2014 at 08:58:30PM +0200, Giorgio Vazzana wrote:
> 2014-09-04 11:29 GMT+02:00 Dmitry Volyntsev :
> > Yes, I could confirm that patch is LGTM. Successfully checked it on
> > one day long run.
>
> Thanks for taking the time to test it, Dmitry.
>
> Michael, I suppose it's safe to app
2014-09-04 11:29 GMT+02:00 Dmitry Volyntsev :
> Yes, I could confirm that patch is LGTM. Successfully checked it on
> one day long run.
Thanks for taking the time to test it, Dmitry.
Michael, I suppose it's safe to apply the patch now, so that this fix
will be included in FFmpeg 2.4.
Regards,
Gi
Yes, I could confirm that patch is LGTM. Successfully checked it on
one day long run.
On Tue, Sep 2, 2014 at 11:35 AM, Giorgio Vazzana wrote:
> 2014-09-02 2:07 GMT+02:00 Michael Niedermayer :
>> should i apply the previous patch or wait ?
>
> Let's wait some days so that Dmitry can test the patch
2014-09-02 2:07 GMT+02:00 Michael Niedermayer :
> should i apply the previous patch or wait ?
Let's wait some days so that Dmitry can test the patch if he wants to
and give us some feedback.
> also if you want, you can add yourself to the v4l2 maintainers in the
> MAINTAINERs file, as you seem to
On Mon, Sep 01, 2014 at 11:00:14PM +0200, Giorgio Vazzana wrote:
> 2014-09-01 22:46 GMT+02:00 Reimar Döffinger :
> > On Mon, Sep 01, 2014 at 10:33:15PM +0200, Giorgio Vazzana wrote:
> >> +static int enqueue_buffer(struct video_data *s, struct v4l2_buffer *buf)
> >> +{
> >> +int res = 0;
> >> +
On Mon, Sep 01, 2014 at 11:00:14PM +0200, Giorgio Vazzana wrote:
> 2014-09-01 22:46 GMT+02:00 Reimar Döffinger :
> > On Mon, Sep 01, 2014 at 10:33:15PM +0200, Giorgio Vazzana wrote:
> >> +static int enqueue_buffer(struct video_data *s, struct v4l2_buffer *buf)
> >> +{
> >> +int res = 0;
> >> +
2014-09-01 22:46 GMT+02:00 Reimar Döffinger :
> On Mon, Sep 01, 2014 at 10:33:15PM +0200, Giorgio Vazzana wrote:
>> +static int enqueue_buffer(struct video_data *s, struct v4l2_buffer *buf)
>> +{
>> +int res = 0;
>> +
>> +if (v4l2_ioctl(s->fd, VIDIOC_QBUF, buf) < 0) {
>> +res = AVER
On Mon, Sep 01, 2014 at 10:33:15PM +0200, Giorgio Vazzana wrote:
> +static int enqueue_buffer(struct video_data *s, struct v4l2_buffer *buf)
> +{
> +int res = 0;
> +
> +if (v4l2_ioctl(s->fd, VIDIOC_QBUF, buf) < 0) {
> +res = AVERROR(errno);
> +av_log(NULL, AV_LOG_ERROR, "ioc
Hello,
as Reimar pointed out the proposed patch is not the correct solution.
Please see/test attached patch.
Regards,
Giorgio Vazzana
2014-08-31 14:35 GMT+02:00 Dmitry Volyntsev :
>>why is this condition true ?
>
> I tried several configuration and problem occurred only under certain
> circumsta
>why is this condition true ?
I tried several configuration and problem occurred only under certain
circumstances:
1. webcam type: Logitech C310 (tried also: C350)
2. capturing settings: 640*480, 422p
3. simultaneous capturing from two webcams
4. relatively old laptop (Lenovo Z470, Z570, L420)
On Sat, Aug 30, 2014 at 08:19:37PM +0400, Dmitry Volyntsev wrote:
> To understand the problem one needs to see the original code around
> and to think what would happen if from time to time while capturing
> condition (s->frame_size > 0 && buf.bytesused != s->frame_size)
> happens to be true (this
To understand the problem one needs to see the original code around
and to think what would happen if from time to time while capturing
condition (s->frame_size > 0 && buf.bytesused != s->frame_size)
happens to be true (this is not critical error so capturing would
continue). It is obvious that eve
On Wed, Aug 13, 2014 at 07:04:01PM +0400, Dmitry Volyntsev wrote:
> From: Dmitry Volyntsev
>
> s->buffers_queued constantly decremented and not incremented
> in case of (s->frame_size > 0 && buf.bytesused != s->frame_size)
> condition (caught on long run capture of Logitech C310)
can you explain
From: Dmitry Volyntsev
s->buffers_queued constantly decremented and not incremented
in case of (s->frame_size > 0 && buf.bytesused != s->frame_size)
condition (caught on long run capture of Logitech C310)
---
libavdevice/v4l2.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
dif
14 matches
Mail list logo
