From patchwork Wed Mar 20 18:56:07 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Strasser X-Patchwork-Id: 12370 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id 09D44448983 for ; Wed, 20 Mar 2019 21:01:33 +0200 (EET) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E598368AAA6; Wed, 20 Mar 2019 21:01:32 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E40A768A884 for ; Wed, 20 Mar 2019 21:01:25 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1553108485; bh=48Jp1rc0csV7pgcR1MW7j7fYzTSurY4qblwFHaT5BbQ=; h=X-UI-Sender-Class:Date:From:To:Subject; b=hqDGUVWMxX4lyVg7cW/yMGdl9UQBB8rfPO4FrPd0UbzbFM9l68ZLxOaWOowtglNxw JYBh7MYm7O1FyW6tktA6pl9H0ItniBeTQukXBoAGxOWkKFxsmOZkgBFoRe+jaYKPhw vpLHOBEyDzmRfTCP43qdeG8ej2P9UpQLszxh1fao= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from akuma.local ([46.114.4.224]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LpwZn-1gTmvX1mWV-00fgt7 for ; Wed, 20 Mar 2019 19:56:16 +0100 Date: Wed, 20 Mar 2019 19:56:07 +0100 From: Alexander Strasser To: ffmpeg-devel@ffmpeg.org Message-ID: <20190320185333.GA5021@akuma.local> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Provags-ID: V03:K1:yOrhfn8239WMhKjGQ/OpeBflji5ycOusH4SX6IPDgPLMnXs2lNO 2qEajEapEZfJwoLzpYYu8fCFogu5FapahVeM1bGEhp21so5dPTQRIoMgYMDwkzlmuiSqtCC wPIr4YpKuRHmo/GSnVr207tyqwhLK/7ajr5Djylyj4qU9Rp2gXOmnlB4tUI5H6v09QPG05X VztmPeBZGLio1s9R8f9nw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1; V03:K0:Ea5xzd66D4g=:DuXzBg62fwJc25pgqPSIhP jU4pYBbEbU317qL+7hClv8dGzGGwvLp1KvYj1sXh3mn1iWcN0Nt/SfzpKL+aHGCInA9Ct1eQS flO/4MyLYMm/Ez4702Uenve10402r3apWMjB4Pmq+M2+81Xv2GMgO6DxKb+E0hHdtSeKkmjwk lqEJeqcdHdUY6CN8aMmevKcnhndgRHbxwAL/8PxdAotKNTBezaXQt6DHhQBSKR/M96mHvtyJA eI3RbCVnruSxWJFzdxrVu8wDIBhft52+pxbCGvgJucDJqW3H+TjGcT2SnsSTh+wIUh8IkWn3Q Z3UVdrgDT4LZu/raj3NyuQjYEqNIt6VlrBZ5jhuK3Qu1XkjJCGvbrEJbpsPl8gqDypioI1tgT IEUNfhQbEOLATtyUcJiHCKQqakGU+vrtR0lHj3nshTIvJKcnPIViSCoVLUzuTV0yDZuV8anIi B7UWQ9T+9BnOUWmulddKqajJ97oJUKkj0vjIikCGjxUd/tkGvjGm9vf7QbWrOCcyG/0QyVare 9yWv0kE9KObk5YsPD5Dt9qq7n1jzRoM4es9HAzQ8LZOG7FcNpmIjBZkm6RZXghzSi9kSTcnUf dQ59PHzyifkSTBWVasOLUU6dSzgu7ogapvau3or8oIS5N5H0p9e458MX0UWezOsKBsGunBgMq m94sutb5vGsNp5qLM+TbWeQtPFHJqBWqCNqdG4Bfn6+TG9zbGU3zSbaIshQJRamIjIRdKJILn 3oWwZuoes1hxHvlScnD3+TKYeft1FkuGH0T8638BKj9TlKUE8DAlpbp//HrFx4WF0wGo457ga o0w44I6qlGoS6pikk2VZMAgO6XYyjOnwSXrqNy2+SUPTLLc2g2eDFSbxpYvKO35O75TkTONlt ZSQPePHZujz/apsMWItLw9lyjbomvBdLStmi6LWh5uWaUzxOLjmgoRGDwJHHaL Subject: [FFmpeg-devel] [PATCH] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" I had found that when capturing video for some hours from USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.), sometimes when invoking the ioctl DQBUF, the returned buffer is not filled with the size we expect for the raw video frame. Here are two examples for such occurrences: [video4linux2,v4l2 @ 0x258b440] Dequeued v4l2 buffer contains 609596 bytes, but 614400 were expected. Flags: 0x00000001. /dev/video1: Invalid data found when processing input [video4linux2,v4l2 @ 0x225f440] Dequeued v4l2 buffer contains 609508 bytes, but 614400 were expected. Flags: 0x00000001. /dev/video1: Invalid data found when processing input The ffmpeg CLI tool will then stop capturing and exit. To avoid this, return FFERROR_REDO instead. I have not seen the issue appearing twice or more often in a row. It was more like one single error every two hours. While searching for the above quoted error message I found a ticket that mentions this type of problem on our tracker. Fixes #4795 --- libavdevice/v4l2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c index 1b9c6e7..5a1b324 100644 --- a/libavdevice/v4l2.c +++ b/libavdevice/v4l2.c @@ -542,7 +542,7 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt) "Dequeued v4l2 buffer contains %d bytes, but %d were expected. Flags: 0x%08X.\n", buf.bytesused, s->frame_size, buf.flags); enqueue_buffer(s, &buf); - return AVERROR_INVALIDDATA; + return FFERROR_REDO; } }