From patchwork Fri Aug 16 03:05:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Rheinhardt X-Patchwork-Id: 14544 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id 20DFB448BFD for ; Fri, 16 Aug 2019 06:19:04 +0300 (EEST) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id F180A68AD2F; Fri, 16 Aug 2019 06:19:03 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id ED2FB68AD1C for ; Fri, 16 Aug 2019 06:18:57 +0300 (EEST) Received: by mail-wr1-f68.google.com with SMTP id c3so162702wrd.7 for ; Thu, 15 Aug 2019 20:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=LVUFV6esny9lPC8J3z5jsK/UzCP8ZAjEIZa5QvXu5Xw=; b=AR6F7aDvC7i8wziZ15CAKJcHq5cMzRUQ1wLDrMcrcZxI+rgGg/dk1UEl5tAvzkxq37 DHfF/GX8Sb8K1wFdnAgWpoScsS537KqzD6mnPjKonlou8Y+T13yFuo9umzsuEX5KOFVM Pi8hcCCmcJ7xKIqpVAcJGbO65EJsvOTNY1q0HGDUsP2k17/41Er4z4pha70eEe9Ilj/Z idBV+2bJ0j2mSX7EiIWXl/u0sE7WN5yYVHcsJ1NDiiDa2iW8recbAsZOyyHEgl71IJSU ERvLtt3txtHiKBAM4Tm+zza9DRuoqt40KFUa1XG2ftYqEQNHDlYdq7wnTYkdD0fltYOq DZOQ== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=LVUFV6esny9lPC8J3z5jsK/UzCP8ZAjEIZa5QvXu5Xw=; b=lqN2UqKeQ951Sy8VFBRFs71eP5FaPen8pjg2bGyFITjJP4UN+XWKac8PSqH8j52Yxi Hx7E+sChg9mDdqhxpgtrNQDRM0Cfctj0OxneN0m8QLvEWedCTHSukGBtkbZ7MpzMa2Fl voi9+y6ZkvEgbUlbOkm0BXEyQwcYOjXm6HKz4iCBpA4aT7dQNx4Ww9BqRQEmHbE1vII9 UiVWVDPn3Jwp7Ghf6xmtYGw2R6xFI/Yd5CR0hxEFlbr4r9m2bYc3tT2AaP2F9ggAtuIP cueKPJcMm79nmr1qzSwYwgR2f9NMrqXXHRCYrw0qsWTxbYgSTBgvl700X/LtbSGvOQU5 0jHQ== X-Gm-Message-State: APjAAAUQgNCmsrT76gZt613F6l1FZRyDh3DRg+o+dtslqtzaKiuQVw54 FdEGv4mqyjyYKXeZ2+ov1yb25UTw X-Google-Smtp-Source: APXvYqyC9TJVXKFaG1mYbw+v7SVUcHBaoQB7lZxtxRuYLLyz/ekjNxAjPuftVrvdhwlKuIBkvn4hew== X-Received: by 2002:adf:fc81:: with SMTP id g1mr7855157wrr.78.1565925229475; Thu, 15 Aug 2019 20:13:49 -0700 (PDT) Received: from localhost.localdomain (ipbcc08b69.dynamic.kabel-deutschland.de. [188.192.139.105]) by smtp.gmail.com with ESMTPSA id x20sm8501603wrg.10.2019.08.15.20.13.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Aug 2019 20:13:49 -0700 (PDT) From: Andreas Rheinhardt To: ffmpeg-devel@ffmpeg.org Date: Fri, 16 Aug 2019 05:05:26 +0200 Message-Id: <20190816030531.4775-6-andreas.rheinhardt@gmail.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190816030531.4775-1-andreas.rheinhardt@gmail.com> References: <20190816030531.4775-1-andreas.rheinhardt@gmail.com> MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 06/11] avcodec/h264_parser: Use smaller buffer 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: Andreas Rheinhardt Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" The H.264 parser currently allocates a buffer of the size of the input frame for every input frame to store the unescaped RBSP of a NAL unit (it is actually only used if a 0x03 escape is encountered at all). For performance reasons only a small part of slices is actually unescaped; and given that an unescaped NAL unit is only used once (if ever), the really needed size of the buffer is the maximum of the possible length of a NAL unit in front of the first slice and the length of the part of the first slice that is actually unescaped. For AVC (mp4/Matroska) content, the length of a NAL unit is known, so that if the NAL units in front of the slices are small (as they usually are), said maximum is small so that one can reduce memory usage by allocating less. For Annex B, this is unfortunately not so, because the code has to assume the worst wrt the NAL unit sizes (it even assumes that an access unit delimiter extends until the end of the input buffer). Signed-off-by: Andreas Rheinhardt --- libavcodec/h264_parser.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c index c200a2ab8e..5f7aea0c76 100644 --- a/libavcodec/h264_parser.c +++ b/libavcodec/h264_parser.c @@ -268,11 +268,6 @@ static inline int parse_nal_units(AVCodecParserContext *s, if (!buf_size) return 0; - av_fast_padded_malloc(&rbsp->rbsp_buffer, &rbsp->rbsp_buffer_alloc_size, buf_size); - if (!rbsp->rbsp_buffer) - return AVERROR(ENOMEM); - rbsp->rbsp_buffer_size = 0; - buf_index = 0; next_avc = p->is_avc ? 0 : buf_size; for (;;) { @@ -310,6 +305,12 @@ static inline int parse_nal_units(AVCodecParserContext *s, } break; } + + av_fast_padded_malloc(&rbsp->rbsp_buffer, &rbsp->rbsp_buffer_alloc_size, src_length); + if (!rbsp->rbsp_buffer) + return AVERROR(ENOMEM); + rbsp->rbsp_buffer_size = 0; + consumed = ff_h2645_extract_rbsp(buf + buf_index, src_length, rbsp, &nal, 1); if (consumed < 0) break;