From patchwork Wed Oct 26 19:40:22 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Philip Langdale X-Patchwork-Id: 1188 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.140.133 with SMTP id o127csp219987vsd; Wed, 26 Oct 2016 12:51:41 -0700 (PDT) X-Received: by 10.28.209.75 with SMTP id i72mr4140588wmg.56.1477511501267; Wed, 26 Oct 2016 12:51: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 g82si12408990wmc.54.2016.10.26.12.51.40; Wed, 26 Oct 2016 12:51: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; dkim=neutral (body hash did not verify) header.i=@overt.org; dkim=neutral (body hash did not verify) header.i=@overt.org; 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 5FF2C689E58; Wed, 26 Oct 2016 22:51:19 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from rs224.mailgun.us (rs224.mailgun.us [209.61.151.224]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 94B84689E3A for ; Wed, 26 Oct 2016 22:51:11 +0300 (EEST) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=overt.org; q=dns/txt; s=k1; t=1477511473; h=References: In-Reply-To: Message-Id: Date: Subject: Cc: To: From: Sender; bh=HpL+RjMeUDhieXAIT0szRKr4LMiF9AkYjdjF29zOqh4=; b=GflRBqmNkNE2aJTpN+GAuAuTtjFSestynmWuL8EP5Ai91Tor5hKYMqq+C+s43OPD8FgnGKjQ CCTEM1cRbB1bNRBvyfP10vRZSDuLRzVDSKC3xdl8bXT0IUdRdn3n5MFgdVX08ow96g+79tmm AXSpl1/jhZK1ch6wQN/hhfpD1Po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=overt.org; s=k1; q=dns; h=Sender: From: To: Cc: Subject: Date: Message-Id: In-Reply-To: References; b=CCm8vQgnSMgRi/6ZNVvN2by5+rBxIx3yoqM6PFLS9JbwruUFUs0cE5ZwyMg4pUxXxLSFYY vJxIVYEjQe/kB9HfW47BKwpJpEWuDfLuFmNJcWEGK0Q/fjPb4W0BjU+DNS7M4PpFf+kfvnia o7ZXjO5UeJ2xGJPI2arvkatzPJ2p0= X-Mailgun-Sending-Ip: 209.61.151.224 X-Mailgun-Sid: WyIyM2Q3MCIsICJmZm1wZWctZGV2ZWxAZmZtcGVnLm9yZyIsICI0YTg5NjEiXQ== Received: from mail.overt.org (155.208.178.107.bc.googleusercontent.com [107.178.208.155]) by mxa.mailgun.org with ESMTP id 581106b4.7f89b056d650-in02; Wed, 26 Oct 2016 19:40:36 -0000 (UTC) Received: from authenticated-user (mail.overt.org [107.178.208.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.overt.org (Postfix) with ESMTPSA id 54EB1600AB; Wed, 26 Oct 2016 19:40:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=overt.org; s=mail; t=1477510835; bh=/nHBtgZsUZeMd8PhLwXH3dtX8EoIkhS0DAOfiROx+eE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fu5N67QmNYALNaLk+R1BFFUm1f93/NloU/HcEvzuzLoD1uxzWE+V2aSrZ2DxTCTrD 7h87hUWZaOTZ7wd9t7lHBdOA091tSMU02svr7K1uPQppPHlC1x8XllY/WcoUkJOrva 0HrByE0nz0cTPGWrTXJj5OEUYwKhuVWG9JI/SHMz6K9oSKH4fp3mGFAcJaVNWQ2BM1 5xR7r6o8nHx5A9Jy/Z0YPhi4WbFW+lxWTj+HBzHoYI5bbuDg+n4epcbc4XLxvSbSlS /Pm+L8KywavxKRX5U4x7M6sownRr5F2rXy2v45v+b9vYkmLuwjbmAd9GTjEfhA5Tan wrD2JFqkwP5yw== From: Philip Langdale To: ffmpeg-devel@ffmpeg.org Date: Wed, 26 Oct 2016 12:40:22 -0700 Message-Id: <20161026194028.26438-5-philipl@overt.org> In-Reply-To: <20161026194028.26438-1-philipl@overt.org> References: <20161026194028.26438-1-philipl@overt.org> Subject: [FFmpeg-devel] [PATCH 04/10] crystalhd: Remove trust_interlaced heuristic 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: Philip Langdale MIME-Version: 1.0 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" It seems that without all the other 1:1 heuristics, we don't have a fundamental problem trusting the interlaced flag on output pictures. That's a relief. Signed-off-by: Philip Langdale --- libavcodec/crystalhd.c | 37 ++++--------------------------------- 1 file changed, 4 insertions(+), 33 deletions(-) diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c index c1ca066..d738ddb 100644 --- a/libavcodec/crystalhd.c +++ b/libavcodec/crystalhd.c @@ -561,7 +561,6 @@ static inline CopyRet copy_frame(AVCodecContext *avctx, { BC_STATUS ret; BC_DTS_STATUS decoder_status = { 0, }; - uint8_t trust_interlaced; uint8_t interlaced; CHDContext *priv = avctx->priv_data; @@ -611,29 +610,7 @@ static inline CopyRet copy_frame(AVCodecContext *avctx, } /* - * For most content, we can trust the interlaced flag returned - * by the hardware, but sometimes we can't. These are the - * conditions under which we can trust the flag: - * - * 1) It's not h.264 content - * 2) The UNKNOWN_SRC flag is not set - * 3) We know we're expecting a second field - * 4) The hardware reports this picture and the next picture - * have the same picture number. - * - * Note that there can still be interlaced content that will - * fail this check, if the hardware hasn't decoded the next - * picture or if there is a corruption in the stream. (In either - * case a 0 will be returned for the next picture number) - */ - trust_interlaced = avctx->codec->id != AV_CODEC_ID_H264 || - !(output->PicInfo.flags & VDEC_FLAG_UNKNOWN_SRC) || - priv->need_second_field || - (decoder_status.picNumFlags & ~0x40000000) == - output->PicInfo.picture_number; - - /* - * If we got a false negative for trust_interlaced on the first field, + * If we got a false negative for interlaced on the first field, * we will realise our mistake here when we see that the picture number is that * of the previous picture. We cannot recover the frame and should discard the * second field to keep the correct number of output frames. @@ -645,16 +622,10 @@ static inline CopyRet copy_frame(AVCodecContext *avctx, return RET_OK; } - interlaced = (output->PicInfo.flags & VDEC_FLAG_INTERLACED_SRC) && - trust_interlaced; - - if (!trust_interlaced && (decoder_status.picNumFlags & ~0x40000000) == 0) { - av_log(avctx, AV_LOG_VERBOSE, - "Next picture number unknown. Assuming progressive frame.\n"); - } + interlaced = output->PicInfo.flags & VDEC_FLAG_INTERLACED_SRC; - av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d | trust_interlaced %d\n", - interlaced, trust_interlaced); + av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d\n", + interlaced); if (priv->pic->data[0] && !priv->need_second_field) av_frame_unref(priv->pic);