From patchwork Thu Mar 16 10:00:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Niedermayer X-Patchwork-Id: 2951 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.50.79 with SMTP id y76csp678480vsy; Thu, 16 Mar 2017 03:01:41 -0700 (PDT) X-Received: by 10.28.0.136 with SMTP id 130mr22840295wma.126.1489658501734; Thu, 16 Mar 2017 03:01:41 -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 q16si6006334wra.35.2017.03.16.03.01.41; Thu, 16 Mar 2017 03:01:41 -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; 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 Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 52DF9688313; Thu, 16 Mar 2017 12:01:22 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id BD161680284 for ; Thu, 16 Mar 2017 12:01:15 +0200 (EET) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id CB7E9C5AD6 for ; Thu, 16 Mar 2017 11:01:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id y8PT8FiLUjOS for ; Thu, 16 Mar 2017 11:01:30 +0100 (CET) X-Originating-IP: 213.47.41.20 Received: from localhost (213-47-41-20.cable.dynamic.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 47BBCC5ADF for ; Thu, 16 Mar 2017 11:01:28 +0100 (CET) Date: Thu, 16 Mar 2017 11:00:37 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20170316100037.GI5776@nb4> References: <20170315031251.22570-1-michael@niedermayer.cc> <20170315185147.GA5776@nb4> <20170315221256.GF5776@nb4> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used 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" On Wed, Mar 15, 2017 at 08:44:25PM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 15, 2017 at 6:12 PM, Michael Niedermayer > wrote: > > > On Wed, Mar 15, 2017 at 07:18:30PM +0000, Kieran Kunhya wrote: > > > > > > > > > > I have tons of testcases for h264 that are 1KB and can make error > > > > > > concealment run for ages. > > > > > > > > and how is this related to a fix for th vp* decoder ? > > > > > > > > > > My point is you can spend a lifetime fixing obscure conditions that cause > > > error concealment to take a long time. > > > > the vp56 EC code > > just sets every block to the reference frames content > > > I don't see how this helps the user experience. Like i said previously if there is damage, its better with error concealment than without. Thats true in general not specific to vp56. also without EC we will need to change fate this way: as the last frame in the sample is damaged, probably truncated we cannot output a partly uninitialzed frame nor can we use it as reference frame afterwards. If there where frames afterwards they would use a wrong/different reference frame or be discarded as well until the next keyframe. > > I once again think you should consider removing the vp56 EC code until we > have a better idea of requirements of and need for such a feature. As the one having implemented it i see both requirement and need. So theres no sense or way i could consider removing it on the basis that these are missing or until they are found. I can remove it becouse people want it removed. also for this specific patch here there is possibly another solution which ill test and if it works submit a patch [...] --- ./tests/ref/fate/vp5 2017-03-13 15:59:01.833910756 +0100 +++ tests/data/fate/vp5 2017-03-16 09:32:21.934865428 +0100 @@ -249,4 +249,3 @@ 0, 243, 243, 1, 233472, 0x6f530ac6 0, 244, 244, 1, 233472, 0x94f7466c 0, 245, 245, 1, 233472, 0xa8c1d365 -0, 246, 246, 1, 233472, 0xbf73f1b7