From patchwork Sun Feb 26 11:36:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: u-9iep@aetey.se X-Patchwork-Id: 2684 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.65.149 with SMTP id x21csp577906vsf; Sun, 26 Feb 2017 03:37:28 -0800 (PST) X-Received: by 10.223.144.176 with SMTP id i45mr9912597wri.51.1488109048314; Sun, 26 Feb 2017 03:37:28 -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 g15si9674456wmc.25.2017.02.26.03.37.24; Sun, 26 Feb 2017 03:37:28 -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=@fripost.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 E2286688246; Sun, 26 Feb 2017 13:37:11 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from outgoing.fripost.org (giraff.fripost.org [178.16.208.44]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C0A4E680A73 for ; Sun, 26 Feb 2017 13:37:04 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by outgoing.fripost.org (Postfix) with ESMTP id C6875AB4C22 for ; Sun, 26 Feb 2017 12:37:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fripost.org; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=20140703; t=1488109033; x=1489923434; bh=ygwNU/pfm Z6FWidgsda04T9wo/kXT0/+EfXa+mZLnnw=; b=C2XKkfGo4BKGRLabjRbFswgeR GAip9TtXctX0zjK6+WNC49VZc2lOEB5N3KfsCwL2bxe74FSkGGCl+YDjdJ1WEVn1 gAOUDO7AJzukoaYcfDwcRa4MTFVBkSRwc3ua2IBo3UxQQGRSQF4OZhZQp7VvcZfI cyFtdUXYc7EGL7syUg= X-Virus-Scanned: Debian amavisd-new at fripost.org Received: from outgoing.fripost.org ([127.0.0.1]) by localhost (giraff.fripost.org [127.0.0.1]) (amavisd-new, port 10040) with LMTP id bpd1MbFWVfEU for ; Sun, 26 Feb 2017 12:37:13 +0100 (CET) Received: from smtp.fripost.org (unknown [172.16.0.6]) by outgoing.fripost.org (Postfix) with ESMTP id 8F523AB4C1B for ; Sun, 26 Feb 2017 12:37:12 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by smtp.fripost.org (Postfix) with ESMTPSA id C28F82A65F9A for ; Sun, 26 Feb 2017 12:37:11 +0100 (CET) Received: (qmail 21279 invoked from network); 26 Feb 2017 11:36:29 -0000 Received: from localhost (HELO aetey.se) (eh1ba719@127.0.0.1) by mail with ESMTPA; 26 Feb 2017 11:36:29 -0000 Date: Sun, 26 Feb 2017 12:36:51 +0100 From: u-9iep@aetey.se To: FFmpeg development discussions and patches Message-ID: <20170226113651.GJ32749@example.net> References: <20170215110155.GG32749@example.net> <20170225200449.GH32749@example.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170225200449.GH32749@example.net> Subject: [FFmpeg-devel] [PATCH 3/2] Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats. 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" This extra patch "beyond the series" is being posted for the benefit of a casual reader who needs extremely fast/lightweight video decoding of prearranged videos, with existing or/and mainstream applications (e.g. like mplayer). This patch is vital to make the cinepak decoding speedup (the matter of the series) usable in practice. (Otherwise you will have to modify the corresponding applications, separately each of them, or if applicable build and use a preload hack implementing an equivalent of this patch, as was suggested elsewhere on this list.) Such an out-of-band control was not welcome in ffmpeg even if disabled by default, the project decision makers did not see the need. That's why this patch is being posted separately, for those who do. Enjoy! Rune From 43aaba5a7fbf5f97fb7f50c4d1f48363d74332f8 Mon Sep 17 00:00:00 2001 From: Rl Date: Sat, 25 Feb 2017 15:35:44 +0100 Subject: [PATCH] Cinepak decoding: provide out-of-band control of output pixel format. Allow the output pixel format to be chosen at runtime by setting CINEPAK_DECODE_SET_PIXFMT envvar to the needed value. This works with any application and complements the functionality of get_format() API. The existing applications are not prepared and generally are not capable to choose the decoder output format correctly. They often lack the information needed to be able to pick the format. That's why get_format() is not sufficient. Note that the proper choice of the most efficient output format is not decoder- nor application-specific but usage-case-specific. The only alternative to implementing this out-of-band format control in the decoder library would be to modify every application to include - either additional logic, reflecting a specific usage case - or an out-of-band control channel neither of which is efficient or possibly not even feasible. --- libavcodec/cinepak.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c index e32b07ce8a..d18b455589 100644 --- a/libavcodec/cinepak.c +++ b/libavcodec/cinepak.c @@ -916,6 +916,9 @@ static const enum AVPixelFormat pixfmt_list_2[] = { static av_cold int cinepak_decode_init(AVCodecContext *avctx) { CinepakContext *s = avctx->priv_data; +#ifndef DISABLE_CINEPAK_DECODE_SET_PIXFMT + char *out_fmt_override = getenv("CINEPAK_DECODE_SET_PIXFMT"); +#endif /* we take advantage of VQ to efficiently support * multiple output formats */ @@ -929,6 +932,38 @@ static av_cold int cinepak_decode_init(AVCodecContext *avctx) /* check for paletted data */ s->palette_video = (avctx->bits_per_coded_sample == 8); +#ifndef DISABLE_CINEPAK_DECODE_SET_PIXFMT +/* + * Checking an environment variable for out-of-band control + * of the output pixel format: + * + * get_format() does _not_ help when you can not modify the applications + * to use it, let alone to use it appropriately under varying practical + * curcumstances, there is no general criteria capable to choose + * the most suitable pixel format for each case; + * that's why the availability of an out-of-band control channel + * is important, sometimes there is no alternative at all -- rl + */ + + if (out_fmt_override && *out_fmt_override) { + if ( !strcmp(out_fmt_override, "rgb32")) { + avctx->pix_fmt = AV_PIX_FMT_RGB32; + } else if (!strcmp(out_fmt_override, "rgb24")) { + avctx->pix_fmt = AV_PIX_FMT_RGB24; + } else if (!strcmp(out_fmt_override, "rgb565")) { + avctx->pix_fmt = AV_PIX_FMT_RGB565; + } else if (!strcmp(out_fmt_override, "yuv420p")) { + avctx->pix_fmt = AV_PIX_FMT_YUV420P; + } else if (!strcmp(out_fmt_override, "pal8")) { + avctx->pix_fmt = AV_PIX_FMT_PAL8; + } else { + av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format override '%s'\n", + out_fmt_override); + return AVERROR(EINVAL); + } + } else +#endif + if (s->out_pixfmt != AV_PIX_FMT_NONE) /* the option is set to something */ avctx->pix_fmt = s->out_pixfmt; else