From patchwork Sat Jan 28 12:59:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthieu Bouron X-Patchwork-Id: 2346 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.89.21 with SMTP id n21csp677625vsb; Sat, 28 Jan 2017 04:59:23 -0800 (PST) X-Received: by 10.28.210.139 with SMTP id j133mr6833056wmg.67.1485608363457; Sat, 28 Jan 2017 04:59:23 -0800 (PST) Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id e18si9526475wra.151.2017.01.28.04.59.23; Sat, 28 Jan 2017 04:59:23 -0800 (PST) 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=@gmail.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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6F49B68A763; Sat, 28 Jan 2017 14:59:19 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 456FC68A23E for ; Sat, 28 Jan 2017 14:59:12 +0200 (EET) Received: by mail-wm0-f46.google.com with SMTP id c206so180936521wme.0 for ; Sat, 28 Jan 2017 04:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KdnhW6xGFUKFqtJMGqj95b9UcSbSd20gIzWl+yVA86s=; b=huLqDXQ5rhdL8Fr2lKOYmvhJ1h2czzdkgfbZrL0qpy9wxgyhKx8y+JURgxdKr1PzEL mRV0L8fLcHP7BV7bmnZLa45gSt+goMBFbNY7LzL3ohpf2yP1H/nopHVyQjHftmPbFfY4 2gqPz6B4zK6t37TzL+SI/ccwAJnvMjqQk57cviOfvOpmew9rRLezWkTwuvAv7DLR6Evc TsCXGIpV+pkh3SWuEsxbWE1cRYpl/6aCVlj8tmXUNloO2pIekYMtJNcEikBHWnxJuUHm AGIRm8c17sQVAhYF2MSECQI4KGpX9FHFiC421PmVLBrqZLzgDO0Y9P1JNojgfKdDMmrv bVhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KdnhW6xGFUKFqtJMGqj95b9UcSbSd20gIzWl+yVA86s=; b=eGzQ21S+6WUUaPTRjvgWq1Bc7p1A2jnkCaLRi4+degO/FJT38DfhU3ogqKHBp3ca43 32aDfAsphzMQOv783jWYFDJsPE6Be5mXTlIYavTEChXdV4zItgZ9ECU0XFmqBUk0NODd 2H/irY60oDcYdWKLKfY0stkUjUm/4mpk0Wlt+xHtPkDLcO0bVmlBZ5j0mW/KVgVX+vJJ FAq2gT3lgnxoh/17raOl7NrwvmKfTmht0NngnfBYGKMMAbps8Pq1YSKPdcVX+PfEv7jl cKH72Cxj+qqeHTP/1irOus3PRSfIrzlujkiaWreozM0oAN1IX7+PtqrnRcUxdfYduB4I Er4Q== X-Gm-Message-State: AIkVDXIProZjZpV/PcGX3WWo2wsRqKoM8siMxAUchMU00sRmQ71z/TUELYPC5ErAeBXhjA== X-Received: by 10.223.172.210 with SMTP id o76mr11357710wrc.21.1485608352783; Sat, 28 Jan 2017 04:59:12 -0800 (PST) Received: from tsuri (AMontsouris-653-1-150-196.w92-140.abo.wanadoo.fr. [92.140.77.196]) by smtp.gmail.com with ESMTPSA id o70sm12800991wrc.20.2017.01.28.04.59.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 04:59:12 -0800 (PST) Date: Sat, 28 Jan 2017 13:59:10 +0100 From: Matthieu Bouron To: FFmpeg development discussions and patches Message-ID: <20170128125910.GE30664@tsuri> References: <20170126164751.27034-1-matthieu.bouron@gmail.com> <20170127013040.GV4698@nb4> <20170127084718.GC30664@tsuri> <20170128012534.GD4698@nb4> <20170128115939.GD30664@tsuri> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170128115939.GD30664@tsuri> User-Agent: Mutt/1.7.2 (2016-11-26) Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: hint next marker position in ff_mjpeg_find_marker 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 Sat, Jan 28, 2017 at 12:59:39PM +0100, Matthieu Bouron wrote: > On Sat, Jan 28, 2017 at 02:25:34AM +0100, Michael Niedermayer wrote: > > On Fri, Jan 27, 2017 at 09:47:18AM +0100, Matthieu Bouron wrote: > > > On Fri, Jan 27, 2017 at 02:30:40AM +0100, Michael Niedermayer wrote: > > > > On Thu, Jan 26, 2017 at 05:47:51PM +0100, Matthieu Bouron wrote: > > > > > Speeds up next marker search when a SOS marker is found. > > > > > > > > > > ff_mjpeg_find_marker goes from 54% to 30% under perf record ffmpeg -i > > > > > sample_2992x4000.jpg > > > > > --- > > > > > libavcodec/mjpegdec.c | 31 +++++++++++++++++++++++++------ > > > > > libavcodec/mjpegdec.h | 2 +- > > > > > libavcodec/mxpegdec.c | 5 +++-- > > > > > 3 files changed, 29 insertions(+), 9 deletions(-) > > > > > > > > this breaks decoding multiple jpeg files > > > > for example tickets//856/nint.jpg > > > > > > New patch attached fixing the issue. > > > > > > [...] > > > > > mjpegdec.c | 31 +++++++++++++++++++++++++------ > > > mjpegdec.h | 2 +- > > > mxpegdec.c | 5 +++-- > > > 3 files changed, 29 insertions(+), 9 deletions(-) > > > 6ba49d73c189b197bdc1a983e26ccd49713c617c 0001-lavc-mjpegdec-hint-next-marker-position-in-ff_mjpeg_.patch > > > From ebef63ebdc75872d52529d5b74b6d05254d4c0fd Mon Sep 17 00:00:00 2001 > > > From: Matthieu Bouron > > > Date: Thu, 26 Jan 2017 15:17:36 +0100 > > > Subject: [PATCH] lavc/mjpegdec: hint next marker position in > > > ff_mjpeg_find_marker > > > > > > Speeds up next marker search when a SOS marker is found. > > > > > > ff_mjpeg_find_marker goes from 54% to 30% under perf record ffmpeg -i > > > sample_2992x4000.jpg > > > > the patch seems to work but > > why is the "buf_ptr += (get_bits_count(&s->gb) + 7) / 8;" not > > already skiping all that what the buf_hint does ? > > is the difference the unescaping ? > > maybe the buf_hint stuff can be simplified by adjusting buf_ptr instead > > ? > > I've just realized that the SOS marker handling does not consume any byte > from the GetBitContext *only* when the frame is being discard (which > happens in avformat_find_stream_info). > > So I guess a better solution would be to consume all the bytes from the > GetBitContext while this marker is skipped and let the code already in > place handle that. > However, the buf_ptr won't directly be at the next marker position since > the sos data is unescaped. With the sample I use there is a difference of > 13774 bytes (thus iterations in find_marker) to find the next marker. It > reduces the function (according to perf) from 5,4% to 4.8% while the frame > is being decoded (ffmpeg -i sample_2999x4000.jpeg -f null -) but it seems > the performance gain is too little versus the code that the patch > introduces and the decoder will benefits more from having aarch64 simd > code for the various idct functions (something that i plan to do in the > upcoming days). > > I'll send a new patch soon. Alternative patch attached. Matthieu [...] From 1bbb34b3874393507cc49a4f9685d54850ca5057 Mon Sep 17 00:00:00 2001 From: Matthieu Bouron Date: Sat, 28 Jan 2017 13:49:52 +0100 Subject: [PATCH] lavc/mjpegdec: consume SOS data even if the frame is discarded Speeds up next marker search when a SOS marker is found but the frame is discarded (which happens in avformat_find_stream_info). --- libavcodec/mjpegdec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c index 7d17e3dfcb..07988b68b1 100644 --- a/libavcodec/mjpegdec.c +++ b/libavcodec/mjpegdec.c @@ -2247,8 +2247,10 @@ eoi_parser: goto the_end; case SOS: s->cur_scan++; - if (avctx->skip_frame == AVDISCARD_ALL) + if (avctx->skip_frame == AVDISCARD_ALL) { + skip_bits(&s->gb, get_bits_left(&s->gb)); break; + } if ((ret = ff_mjpeg_decode_sos(s, NULL, 0, NULL)) < 0 && (avctx->err_recognition & AV_EF_EXPLODE)) -- 2.11.0