From patchwork Wed Oct 26 19:40:28 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Philip Langdale X-Patchwork-Id: 1189 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.140.133 with SMTP id o127csp220457vsd; Wed, 26 Oct 2016 12:53:02 -0700 (PDT) X-Received: by 10.194.246.3 with SMTP id xs3mr4321962wjc.87.1477511582455; Wed, 26 Oct 2016 12:53:02 -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 h206si5138977wme.84.2016.10.26.12.53.02; Wed, 26 Oct 2016 12:53:02 -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 73969689E93; Wed, 26 Oct 2016 22:51:48 +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 95545689E7D for ; Wed, 26 Oct 2016 22:51:43 +0300 (EEST) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=overt.org; q=dns/txt; s=k1; t=1477511505; h=References: In-Reply-To: Message-Id: Date: Subject: Cc: To: From: Sender; bh=wxzSDhclUISxzRKcA+aYgp3tfBzDAdsSZHEOuAJlhlY=; b=Avh3CIYi3JFxQH4uiV7KKfyBKBbn7PLbxcroAdtW4el767GZf0CdhEiD9aqFG8rQpESJaURz tEvJU+no7uclcJVjvthZ8TezxGrFkhWrvU567ZsmQlPTH4sSfmWy8m5edz1oErORbOSQYHZh Oyx9oC0PUgH/9eShjCwnJf2SvPc= 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=zZeDtYMppxjpIXkYAdNBARmjyIrKmmDYgpZ97wO2lULHE4L6CzBGgkPElwN2r/A7OR7cTQ 5H0ab+Q73lq9305aMK9etl+vqFcs//54fPw5v78fSbLAuKQCgObTR37Zkam9f+82qiUK/VaE 9WJ2u8XvT6f6bWAi1G4RxL2PyYsM4= 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 581106b6.7f06984701b8-in8; Wed, 26 Oct 2016 19:40:38 -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 D146E600AB; Wed, 26 Oct 2016 19:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=overt.org; s=mail; t=1477510838; bh=nU9/TbH6PC7stf2E071UFQSkDkb9jIWm7GnTF1LJv5g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S+d0jrKPtflErgQDN9WEMkNgKnD72P7Ttpjbgy6E1krv+MhWzGTG33lBCW8SHyYQ+ plF5SQQdRxMndCYoScCsFjp7tcIC0zOpBRYxx5IR/6943xEoNdqoliCug4QYfiLLTC YgBAtMKE0rfq0Ew7uAtXQCmsnkVSDKZxO5Ym6GgJ7gYizD3uXOXEMGh6e/MCbIWti7 hZ3alETBPQYSybPiAlit9MOOs+j4TfsfmSFcuaODyClKXS3g6mgGf8QHc12BwORPf5 fMG+zjCTIwMG4i2WIn2gPoN1ErhejQXLt4K8y28MLcsmYXPUGJ1E3yf6Djd1ZCvtTg E+mSYyd+ssgnw== From: Philip Langdale To: ffmpeg-devel@ffmpeg.org Date: Wed, 26 Oct 2016 12:40:28 -0700 Message-Id: <20161026194028.26438-11-philipl@overt.org> In-Reply-To: <20161026194028.26438-1-philipl@overt.org> References: <20161026194028.26438-1-philipl@overt.org> Subject: [FFmpeg-devel] [PATCH 10/10] crystalhd: Update high level description 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" We don't need to document the horrible hacks that we removed. Signed-off-by: Philip Langdale --- libavcodec/crystalhd.c | 38 +++++--------------------------------- 1 file changed, 5 insertions(+), 33 deletions(-) diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c index 7cf2c75..d85e351 100644 --- a/libavcodec/crystalhd.c +++ b/libavcodec/crystalhd.c @@ -34,39 +34,11 @@ * is not just a function of time, but also one of the dependency on additional * frames being fed into the decoder to satisfy the b-frame dependencies. * - * As such, a pipeline will build up that is roughly equivalent to the required - * DPB for the file being played. If that was all it took, things would still - * be simple - so, of course, it isn't. - * - * The hardware has a way of indicating that a picture is ready to be copied out, - * but this is unreliable - and sometimes the attempt will still fail so, based - * on testing, the code will wait until 3 pictures are ready before starting - * to copy out - and this has the effect of extending the pipeline. - * - * Finally, while it is tempting to say that once the decoder starts outputting - * frames, the software should never fail to return a frame from a decode(), - * this is a hard assertion to make, because the stream may switch between - * differently encoded content (number of b-frames, interlacing, etc) which - * might require a longer pipeline than before. If that happened, you could - * deadlock trying to retrieve a frame that can't be decoded without feeding - * in additional packets. - * - * As such, the code will return in the event that a picture cannot be copied - * out, leading to an increase in the length of the pipeline. This in turn, - * means we have to be sensitive to the time it takes to decode a picture; - * We do not want to give up just because the hardware needed a little more - * time to prepare the picture! For this reason, there are delays included - * in the decode() path that ensure that, under normal conditions, the hardware - * will only fail to return a frame if it really needs additional packets to - * complete the decoding. - * - * Finally, to be explicit, we do not want the pipeline to grow without bound - * for two reasons: 1) The hardware can only buffer a finite number of packets, - * and 2) The client application may not be able to cope with arbitrarily long - * delays in the video path relative to the audio path. For example. MPlayer - * can only handle a 20 picture delay (although this is arbitrary, and needs - * to be extended to fully support the CrystalHD where the delay could be up - * to 32 pictures - consider PAFF H.264 content with 16 b-frames). + * As such, the hardware can only be used effectively with a decode API that + * doesn't assume a 1:1 relationship between input packets and output frames. + * The new avcodec decode API is such an API (an m:n API) while the old one is + * 1:1. Consequently, we no longer support the old API, which allows us to avoid + * the vicious hacks that are required to approximate 1:1 operation. */ /*****************************************************************************