From patchwork Mon Oct 29 12:34:59 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Javier Martin X-Patchwork-Id: 15284 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1TSoYj-00078l-Up for patchwork@linuxtv.org; Mon, 29 Oct 2012 13:35:13 +0100 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-3) with esmtp for id 1TSoYj-0004rX-DU; Mon, 29 Oct 2012 13:35:13 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758812Ab2J2MfK (ORCPT ); Mon, 29 Oct 2012 08:35:10 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:65121 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758759Ab2J2MfJ (ORCPT ); Mon, 29 Oct 2012 08:35:09 -0400 Received: by mail-wi0-f178.google.com with SMTP id hr7so2137524wib.1 for ; Mon, 29 Oct 2012 05:35:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references :x-gm-message-state; bh=r0e2KT8uDX02Anp6NgavFKR/wEmHOJUUty4Qt0Qotfk=; b=jCdQI4ru95nC7TD5qvVBhe1jtQ86f2DVXobwYi2G4vFKEmpJF79UWZkeGDyiPS2Alx sCKqnSzbHIswMBkj2bSjhQDw4GEXFZ7MjX1lw97IBt8FBVEfEn4WNk+fHMfaU1nkLLUd XnlkQ2CsetGiGWnUpXjYnfebMr8EZGx+1f3pYwqzAfS5valTCTL77CnKpFddOLeiSGoP UIjT/myZ1qH8i9xtXH4028Pu8VN+IvbALz5Wq26gVU3j6PMhwliP5tLGNtyRa4giX+oK 95RIsPUaLuiPth3rCuMXz/JZIXZL6WyvOwWm04FDfrAEM4sITzg3Y3MBuYK/eHzgjmJy Mdpw== Received: by 10.180.93.136 with SMTP id cu8mr14956332wib.7.1351514107758; Mon, 29 Oct 2012 05:35:07 -0700 (PDT) Received: from piscis.vsilicon.net (149.93.18.95.dynamic.jazztel.es. [95.18.93.149]) by mx.google.com with ESMTPS id di7sm11108154wib.11.2012.10.29.05.35.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 05:35:06 -0700 (PDT) From: javier.martin@vista-silicon.com To: linux-media@vger.kernel.org Cc: p.zabel@pengutronix.de, mchehab@infradead.org, Javier Martin Subject: [PATCH v2] media: coda: Fix H.264 header alignment. Date: Mon, 29 Oct 2012 13:34:59 +0100 Message-Id: <508e77fa.475fb40a.435a.01b7@mx.google.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: References: X-Gm-Message-State: ALoCoQnFNZGg+eqmFzgPK2vx5WKMrvdhwKNR3ZAAIInRbI09oOK0w61Yk6YioTNChokPmz0HK+Co Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.29.122717 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, NO_REAL_NAME 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS ' From: Javier Martin Length of H.264 headers is variable and thus it might not be aligned for the coda to append the encoded frame. This causes the first frame to overwrite part of the H.264 PPS. In order to solve that, a filler NAL must be added between the headers and the first frame to preserve alignment. Signed-off-by: Javier Martin --- Changes since v1: - Align to 64bits as requested by Philipp. --- drivers/media/platform/coda.c | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c index a8c7a94..7febcd9 100644 --- a/drivers/media/platform/coda.c +++ b/drivers/media/platform/coda.c @@ -177,6 +177,10 @@ struct coda_ctx { int idx; }; +static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x80 }; +static const u8 coda_filler_size[8] = { 0, 7, 14, 13, 12, 11, 10, 9 }; + static inline void coda_write(struct coda_dev *dev, u32 data, u32 reg) { v4l2_dbg(1, coda_debug, &dev->v4l2_dev, @@ -938,6 +942,24 @@ static int coda_alloc_framebuffers(struct coda_ctx *ctx, struct coda_q_data *q_d return 0; } +static int coda_h264_padding(int size, char *p) +{ + int nal_size; + int diff; + + diff = size - (size & ~0x7); + if (diff == 0) + return 0; + + nal_size = coda_filler_size[diff]; + memcpy(p, coda_filler_nal, nal_size); + + /* Add rbsp stop bit and trailing at the end */ + *(p + nal_size - 1) = 0x80; + + return nal_size; +} + static int coda_start_streaming(struct vb2_queue *q, unsigned int count) { struct coda_ctx *ctx = vb2_get_drv_priv(q); @@ -1165,7 +1187,13 @@ static int coda_start_streaming(struct vb2_queue *q, unsigned int count) coda_read(dev, CODA_CMD_ENC_HEADER_BB_START); memcpy(&ctx->vpu_header[1][0], vb2_plane_vaddr(buf, 0), ctx->vpu_header_size[1]); - ctx->vpu_header_size[2] = 0; + /* + * Length of H.264 headers is variable and thus it might not be + * aligned for the coda to append the encoded frame. In that is + * the case a filler NAL must be added to header 2. + */ + ctx->vpu_header_size[2] = coda_h264_padding((ctx->vpu_header_size[0] + + ctx->vpu_header_size[1]), ctx->vpu_header[2]); break; case V4L2_PIX_FMT_MPEG4: /*