From patchwork Mon Apr 24 18:57:07 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: wm4 X-Patchwork-Id: 3483 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.3.129 with SMTP id 123csp1575139vsd; Mon, 24 Apr 2017 11:57:02 -0700 (PDT) X-Received: by 10.223.139.150 with SMTP id o22mr6694641wra.90.1493060221971; Mon, 24 Apr 2017 11:57:01 -0700 (PDT) Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id w198si1241465wmf.107.2017.04.24.11.57.01; Mon, 24 Apr 2017 11:57:01 -0700 (PDT) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@googlemail.com; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9B15F689891; Mon, 24 Apr 2017 21:56:57 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B2AEF688317 for ; Mon, 24 Apr 2017 21:56:51 +0300 (EEST) Received: by mail-wm0-f67.google.com with SMTP id y10so8630487wmh.0 for ; Mon, 24 Apr 2017 11:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=yfGGe3LiPMUBwqAd+mpY3wrJlkRurxMwkgjLfjZtjts=; b=cBCgjjQCJSnFinxaL0kpgXtLV6NLe0avBKbZC1IJ+ggVsdw+Aw2S1DhteJ6nNVirKV 7uqMjjxmm4JmwhyNXFDA6x8rFNkVvnlU8LYc2f1JenT9EX0cxxNHIIYAQzuTo3La0Qsq FH1MkHi7+3Lo+SJTFW3HfzudaSLaaGHDDrMBh2nc3vDEeDTMZRfX54OIb6Rp9abJ2LsH PZIK+gHLgO6iIJQL7s8IVIhHwxUsrGXrN5CP9QKXrUlfYTGw9K7GtgAr52bpmU2fs59C 09qysrozsGgSp+VtAgzPbYS7bfh5+uNqKJL+enjlI0dCuMxq9XAXJLYxDTIggybO6+yv cvrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=yfGGe3LiPMUBwqAd+mpY3wrJlkRurxMwkgjLfjZtjts=; b=QPDl2K9Vi6BkoNkJpnBhmHZHlrZpxtnC7b9Pd520XUujjI2H3VWldDCOMqm73whc59 qPTHM2SYnTCpARtw0bwx5GNVqpRH23LCOQzEQgNu0V7d95gNaZfYp7BJR2S4M5sUZ19y 8tckk/3Zod9CfaFEgAYHrDsz6gi7tQo/bmFDH/85Xn5UGIvXGizDcNsa2M5BlBCE/Ww9 kd7pAIf/bwGtjyNKKSSVVHNaxf5bkKIHgcEk6mXy+zw+fzzHCrF3dsRZSmDhQf2Q89yk AbGsMTKffS1MME1flFlKD2M0J8m+MCJQ9Mzjpshh7Xy9MfE8dfG7yeBK4kyccC0d8Cbo a/aw== X-Gm-Message-State: AN3rC/6pDEDkLv79hJyNWSjb6TuaalNVv/XjqklRB6FwpK2r+G4PJXVg ZdywoQQ0bLWWug== X-Received: by 10.28.1.88 with SMTP id 85mr3489523wmb.97.1493060212214; Mon, 24 Apr 2017 11:56:52 -0700 (PDT) Received: from localhost.localdomain (p4FF0023E.dip0.t-ipconnect.de. [79.240.2.62]) by smtp.googlemail.com with ESMTPSA id q131sm1655321wmd.0.2017.04.24.11.56.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 11:56:51 -0700 (PDT) From: wm4 To: ffmpeg-devel@ffmpeg.org Date: Mon, 24 Apr 2017 20:57:07 +0200 Message-Id: <20170424185707.18647-1-nfxjfg@googlemail.com> X-Mailer: git-send-email 2.11.0 Subject: [FFmpeg-devel] [PATCH] pthread_frame: ignore errors during draining 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 Cc: wm4 MIME-Version: 1.0 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" This is needed to get compatibility with the behavior before the recent decode.c restructuring merge, and fixes fate failures with this: make fate-h264-attachment-631 THREADS=32 For every 4 threads, a frame is dropped at the point at which draining is initialized. The problem starts at THREADS=4. This patch "fixes" it by ignoring errors during draining (if there is a frame to be returned), but there is probably a deeper cause and/or a better fix for this. I haven't looked closer at this, but was asked to send this patch for discussion. --- libavcodec/pthread_frame.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c index 13d682842d..e7fa503adf 100644 --- a/libavcodec/pthread_frame.c +++ b/libavcodec/pthread_frame.c @@ -548,7 +548,7 @@ int ff_thread_decode_frame(AVCodecContext *avctx, fctx->next_finished = finished; /* return the size of the consumed packet if no error occurred */ - if (err >= 0) + if (err >= 0 || (!avpkt->size && *got_picture_ptr)) err = avpkt->size; finish: async_lock(fctx);