From patchwork Mon Mar 25 19:32:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephan Hilb X-Patchwork-Id: 12442 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 27A514495CE for ; Mon, 25 Mar 2019 21:32:36 +0200 (EET) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 145D1689F31; Mon, 25 Mar 2019 21:32:36 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail.bs0x539.de (mail.bs0x539.de [138.201.57.224]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 38F8A689DBF for ; Mon, 25 Mar 2019 21:32:29 +0200 (EET) Date: Mon, 25 Mar 2019 20:32:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bs0x539.de; s=bs0x539.de; t=1553542348; bh=UHLTpCWPzpPMFfXep9ZcpsV9v1bcGALMfyfuy13QFsw=; h=Date:From:To:Subject:In-Reply-To:References; b=VWxgbFQdAHLCKA+1BD4pNIL/dSAAmx2xvsHVp6UKoYaJT+2A/n2Q8gJkTDsAYmGho XK0oJzI/jLlRfc3y5Vbl/Yu5VKtpOjZfUSaqTVwNY/kN1b+/8kbOw1wqXZVSwhHdde qTDB4RV+Rlm5HxY0stSogbTh3ZxQUhwPjHJLLEP7UObtyucUHqF3h/lhxohQqeOZe+ HX7hDh0Zuk5vF8A5GlDa4NJDEcFGuTLfu3i8OaVXtWA1cFcUoRpx5mQqlvwYXKFEF3 6aN+BeMTlb9g7F+T29UylvI4AleFO6VhPAWQGCgGf/B20ohm9M4TbNGsLcU20V51// IoxCCWpz9PUyw== From: Stephan Hilb To: ffmpeg-devel@ffmpeg.org Message-ID: <20190325203222.1ba653c6@st-dt> In-Reply-To: <20190321223432.GA3790@akuma.local> References: <20190320185333.GA5021@akuma.local> <20190320212626.GA6139@akuma.local> <20190321090700.kdmtpgoyuszrk64s@phare.normalesup.org> <20190321223432.GA3790@akuma.local> MIME-Version: 1.0 Subject: Re: [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" Alexander Strasser wrote on 21.03.2019 at 23:34: > 3. Return zero-sized packets => This works and is consistent with how > we handle frames flagged to be corrupted (V4L2_BUF_FLAG_ERROR). > See commit 28f20d2ff487aa589643d8f70eaf614b78839685 . I posted a patch for this on Sat, 25 Aug 2018. It seems to have been forgotten, attached again. From 0af8515acca4d598570d03450656adc0ed7ac2d7 Mon Sep 17 00:00:00 2001 From: Stephan Hilb Date: Sun, 10 Jun 2018 21:07:52 +0200 Subject: [PATCH] lavd/v4l2: skip buffers not matching frame_size By adopting the same behaviour as if there was corrupted data in the buffer (see the check for V4L2_BUF_FLAG_ERROR) the resulting rawvideo now at least contains valid data (the previous frame being duplicated). Fixes video capturing for some stk1160 devices. --- libavdevice/v4l2.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c index 10a0ff0dd6..ab903bbcee 100644 --- a/libavdevice/v4l2.c +++ b/libavdevice/v4l2.c @@ -534,11 +534,10 @@ 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); - enqueue_buffer(s, &buf); - return AVERROR_INVALIDDATA; + buf.bytesused = 0; } } -- 2.18.0