[FFmpeg-devel] [PATCH] libavdevice/v4l2: fix of crash caused by assert

[Giorgio Vazzana]

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 <xeioexception at gmail.com>:
>>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)
>
> I think it somehow relate to usb hub bandwidth and laptop performance
> issue (and maybe length of usb cable?)
>
> I use my own app (24/7 surveillance home recording) which depends on
> libavdevice and prefer to ignore AVERROR_INVALIDDATA in this case
> (just skip the broken frame and continue) because reconnect to devices
> required more than a half of second. With my patch everything goes
> fine (more than 2 week of continuous recording)
>
> logs:
>   [video4linux2,v4l2 @ 0x2efec00]The v4l2 frame is 614396 bytes, but
> 614400 bytes are expected
>   [video4linux2,v4l2 @ 0x2efec00]The v4l2 frame is 614396 bytes, but
> 614400 bytes are expected
>
>
>
> On Sat, Aug 30, 2014 at 9:17 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> 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 is not critical error so capturing would
>>> continue). It is obvious that eventually buffers_queued would become <
>>> 1.
>>
>> why is this condition true, what are these mismatching buffers ?
>>
>>
>>>
>>> static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
>>> {
>>>   ...
>>>     if (buf.index >= s->buffers) {
>>>         av_log(ctx, AV_LOG_ERROR, "Invalid buffer index received.\n");
>>>
>>>         return AVERROR(EINVAL);
>>>     }
>>>
>>>     avpriv_atomic_int_add_and_fetch(&s->buffers_queued, -1);
>>>     // always keep at least one buffer queued
>>>     av_assert0(avpriv_atomic_int_get(&s->buffers_queued) >= 1);
>>>
>>>     if (s->frame_size > 0 && buf.bytesused != s->frame_size) {
>>>                av_log(ctx, AV_LOG_ERROR,
>>>                "The v4l2 frame is %d bytes, but %d bytes are expected\n",
>>>                buf.bytesused, s->frame_size);
>>>         return AVERROR_INVALIDDATA;
>>>
>>>     }
>>>
>>> So my solution:  we should make all checks here before decrementing
>>> buffers_queued
>>>
>>> On Wed, Aug 27, 2014 at 1:20 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>> > On Wed, Aug 13, 2014 at 07:04:01PM +0400, Dmitry Volyntsev wrote:
>>> >> From: Dmitry Volyntsev <xeioexception at gmail.com>
>>> >>
>>> >> 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 why this happens ? where do this misatching
>>> > bufs come from ?
>>> > why is droping them correct ?
>>> >
>>> >
>>> > [...]
>>> > --
>>> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>> >
>>> > Dictatorship naturally arises out of democracy, and the most aggravated
>>> > form of tyranny and slavery out of the most extreme liberty. -- Plato
>>>
>>>
>>>
>>> --
>>> Be happy,
>>> Best regards,
>>> Dmitry Volyntsev
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> --
>> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> In a rich man's house there is no place to spit but his face.
>> -- Diogenes of Sinope
>
>
>
> --
> Be happy,
> Best regards,
> Dmitry Volyntsev
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lavd-v4l2-introduce-enqueue_buffer.patch
Type: text/x-patch
Size: 3905 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140901/0b6ae9a3/attachment.bin>