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

[Dmitry Volyntsev]

>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