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.
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 <michae...@gmx.at> wrote:
> On Wed, Aug 13, 2014 at 07:04:01PM +0400, Dmitry Volyntsev wrote:
>> From: Dmitry Volyntsev <xeioexcept...@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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
