From patchwork Sat Sep 10 10:21:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Oliver Collyer X-Patchwork-Id: 9324933 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EA42160231 for ; Sat, 10 Sep 2016 10:21:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E6AAE29976 for ; Sat, 10 Sep 2016 10:21:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DA40C29AFD; Sat, 10 Sep 2016 10:21:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 656AC29976 for ; Sat, 10 Sep 2016 10:21:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755425AbcIJKVg (ORCPT ); Sat, 10 Sep 2016 06:21:36 -0400 Received: from pv33p04im-asmtp001.me.com ([17.143.181.10]:47607 "EHLO pv33p04im-asmtp001.me.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755311AbcIJKVf (ORCPT ); Sat, 10 Sep 2016 06:21:35 -0400 Received: from process-dkim-sign-daemon.pv33p04im-asmtp001.me.com by pv33p04im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ODA00L009VPNO00@pv33p04im-asmtp001.me.com> for linux-media@vger.kernel.org; Sat, 10 Sep 2016 10:21:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=4d515a; t=1473502876; bh=0cHkeGtdxIWaheIez03rQB0yCeUFHmUhPjh6BEQrnt0=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=AcowdW716LOpfpNY9DPiAsc4ihEKfNHoGNBpfenkZx+ZdVrUqc0Msnb3cy7O+6/Ta UdHHMonuruR2MDkM/Q24OIs1eFvVeCEFn+MGuwezwM2i9HOc0KWyp9poSO9o7bJTrh X5jleyCktaX0PTZnUP+fQL7Za/rdrPy1rtKaNCnJkRQWLTGjXtUXZZzG535WGCoTKd NP6CCGluixp8WvsID5Z1MABcViI6KyxXQjoTnjv3I3/6iQo0vO2GHTy8h9OaK3PObp z5h78vR3zyFlF5hvbUgjk/C7DNKDColFCOgCBL3u1dwsuTQ5PwPJsKiUu1UeDWm8Qc X6o4W2czSpENQ== Received: from ovs-laptop.ov (88.233.73.222.dynamic.ttnet.com.tr [88.233.73.222]) by pv33p04im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ODA00ECQA3BHY30@pv33p04im-asmtp001.me.com>; Sat, 10 Sep 2016 10:21:15 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-09_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1609100147 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: uvcvideo error on second capture from USB device, leading to V4L2_BUF_FLAG_ERROR From: Oliver Collyer In-reply-to: <20160910101440.nlb4sp43u36yj4ql@zver> Date: Sat, 10 Sep 2016 13:21:10 +0300 Cc: linux-media@vger.kernel.org, Support INOGENI , james.liu@magewell.net Content-transfer-encoding: quoted-printable Message-id: References: <20160904192538.75czuv7c2imru6ds@zver> <20160905201935.wpgtrtt7e4bjjylo@zver> <20160906122823.toxscjyxomrh2col@zver> <71006CF0-B710-435A-B5A5-C0D0D20DE34F@mac.com> <20160910101440.nlb4sp43u36yj4ql@zver> To: Andrey Utkin X-Mailer: Apple Mail (2.3124) Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP >> I have written a patch for FFmpeg that deals with the problem for both >> devices so it’s not really an issue for me anymore, but I’m not sure >> if the patch will get accepted in their master git as it’s a little >> messy. > > Please post this patch here! Here you go, Andrey. This patch basically makes it throw away corrupted buffers and then also the first 8 buffers after the last corrupted buffer. It’s not sufficient just to throw away the corrupted buffers as I have noticed that the first few legitimate buffers appear at slightly irregular time intervals leading to FFmpeg spewing out a bunch of warnings for the duration of the capture. In my tests around 3 buffers have to be ignored but I’ve fixed it at 8 to be on the safe side. It’s a bit ugly though, to be honest, I don’t know how the number of buffers that need to be ignored would depend on the framerate, video size etc, but it works for my 1080i test. With this patch, you get some warnings at the start, for both devices, as it encounters (and recovers from) the corrupted buffers but after that the captures work just fine. --- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c old mode 100644 new mode 100755 index ddf331d..7b4a826 --- a/libavdevice/v4l2.c +++ b/libavdevice/v4l2.c @@ -79,6 +79,7 @@ struct video_data { int buffers; volatile int buffers_queued; + int buffers_ignore; void **buf_start; unsigned int *buf_len; char *standard; @@ -519,7 +520,9 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt) av_log(ctx, AV_LOG_WARNING, "Dequeued v4l2 buffer contains corrupted data (%d bytes).\n", buf.bytesused); - buf.bytesused = 0; + s->buffers_ignore = 8; + enqueue_buffer(s, &buf); + return FFERROR_REDO; } else #endif { @@ -529,14 +532,28 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt) s->frame_size = buf.bytesused; if (s->frame_size > 0 && buf.bytesused != s->frame_size) { - av_log(ctx, AV_LOG_ERROR, + av_log(ctx, AV_LOG_WARNING, "Dequeued v4l2 buffer contains %d bytes, but %d were expected. Flags: 0x%08X.\n", buf.bytesused, s->frame_size, buf.flags); + s->buffers_ignore = 8; enqueue_buffer(s, &buf); - return AVERROR_INVALIDDATA; + return FFERROR_REDO; } } + + /* if we just encounted some corrupted buffers then we ignore the next few + * legitimate buffers because they can arrive at irregular intervals, causing + * the timestamps of the input and output streams to be out-of-sync and FFmpeg + * to continually emit warnings. */ + if (s->buffers_ignore) { + av_log(ctx, AV_LOG_WARNING, + "Ignoring dequeued v4l2 buffer due to earlier corruption.\n"); + s->buffers_ignore --; + enqueue_buffer(s, &buf); + return FFERROR_REDO; + } + /* Image is at s->buff_start[buf.index] */ if (avpriv_atomic_int_get(&s->buffers_queued) == FFMAX(s->buffers / 8, 1)) { /* when we start getting low on queued buffers, fall back on copying data */ @@ -608,6 +625,7 @@ static int mmap_start(AVFormatContext *ctx) } } s->buffers_queued = s->buffers; + s->buffers_ignore = 0; type = V4L2_BUF_TYPE_VIDEO_CAPTURE; if (v4l2_ioctl(s->fd, VIDIOC_STREAMON, &type) < 0) {