From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 80E0742756 for ; Wed, 30 Mar 2022 10:42:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2A4F168B1A5; Wed, 30 Mar 2022 13:42:48 +0300 (EEST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-oln040092073068.outbound.protection.outlook.com [40.92.73.68]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3E7D968B12C for ; Wed, 30 Mar 2022 13:42:41 +0300 (EEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M8VWYMtTjZVqBxYdPnwTNqmbSK6fM+3NuHw60gEj4mNqa9WT1imsJXVoBvla0tICiH/zWnW9l8Wu066oDDT1H9lUA3Nmjuosp4M+hAlvlEzpi5QQ3BQRlLOvAWXbfjw8+hgfW+yPnGRzvNQUF4/TwNqZ9rgTA7usPjQXIT9p5eX7nOn/Bs+Dg4Dith8TSJRt/aFP8tNbBkLK1UJjicEyEqdkcgyG4u4aFq+cGr9sFBb6Znvpobm/lLaFxvFXyGcDRz1N9DLWKnQJNHaDkMyi/B4emn73+Jic3z2WhwB1oQQVU4fdovJuNCAhCZ9gtFAcU2pm2ZKzecFHZPpQSixKVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BkGJmdJuiONR2nbbM/QAFOZ34fi5neQKlh65dEY/mdY=; b=UyzW9xXt1PGLxNBYUaA1LoBoRaU4dnzoBLzFRGumemQrH5ikvVIQTuvtIgo82y5fMNnj8dyTupzDKLHGvnBpYG94BnWIqHCbCH9x6VlNquy9mID5u/6a/+RsrHfs4fbOBeozTmVhgwLYl1LliPaT6R5OALiKVp1maOyF0JmDWNZWRHyW6dlSMFva8zDyW+rUDWCS8v61kC065S+8eEBTVGJqq7PI4KWW6THmvhTBaTtfjsfvY/WKWZtk0lv5ryOpR4AKRLJUUeTS9Egl3tJt88nLL2nCz+WXi9b3kow2jSwWI1dqkncpqYbZlw4WZdEY8Cw8wgyrIgt3fyjIyRbTDg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BkGJmdJuiONR2nbbM/QAFOZ34fi5neQKlh65dEY/mdY=; b=sqth2/lC1fjrpPHe3qYDOmUcbC3uzAkcxHZjzD9IfnfKQ9o9YLLkXCEDD8u1czCPecwt54HmGwqnXpjbtaY9/wl+rm4I2iPRZF9xTWdq1W5sJPQ7Y87VidAr+ial6swiHdoagNeigO2llPJ3ylInr+r4o9hf50VlQbwEjGUFp3RkpdFL6pF4hrtVto2PN91Wn1Muy2VTKrZvsb2jCl6pKZiHGNYGSXEMTRd1PGiGyBVXN3L4WAaEGVVJJl50Xds40fdxQfYNYVgOhdTwC9UMAqg8QXYmYvmvAl/u6fqztil9FN8V3IDEajb9GkuJHIVcunydO3KmaqPEf7apXtDYzQ== Received: from AS1PR01MB9564.eurprd01.prod.exchangelabs.com (2603:10a6:20b:4d1::16) by AM6PR01MB4102.eurprd01.prod.exchangelabs.com (2603:10a6:20b:19::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.19; Wed, 30 Mar 2022 10:42:39 +0000 Received: from AS1PR01MB9564.eurprd01.prod.exchangelabs.com ([fe80::9070:a5fd:e532:bdf8]) by AS1PR01MB9564.eurprd01.prod.exchangelabs.com ([fe80::9070:a5fd:e532:bdf8%3]) with mapi id 15.20.5102.022; Wed, 30 Mar 2022 10:42:39 +0000 Message-ID: Date: Wed, 30 Mar 2022 12:42:37 +0200 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220327133933.43039-1-mvanb1@gmail.com> From: Andreas Rheinhardt In-Reply-To: <20220327133933.43039-1-mvanb1@gmail.com> X-TMN: [4fJhOJbyAajP4HypcctQbn80r1K6+tmM] X-ClientProxiedBy: ZR0P278CA0042.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1d::11) To AS1PR01MB9564.eurprd01.prod.exchangelabs.com (2603:10a6:20b:4d1::16) X-Microsoft-Original-Message-ID: <96ec1934-f1b3-1d62-2e0c-eab539dd826c@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fece33d9-894f-4c01-df99-08da123a02a0 X-MS-TrafficTypeDiagnostic: AM6PR01MB4102:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eypQGe3SnYeO5WvEK6uvr7LJQAY9YNOu+jY8KmyOA9OMEsbv8veI1GbrK8iKlpMkIGLxsA5LISEPJIzHDknQgjWXgMAaYB9etmFjQfKFOvhCnWCGv8m32B9dNNQ2pfjuuxw7wUbUPlSLSx3XSaYkPoslwlfCX+kFbxKLsVEkU8RtzfGw/qs63sODhzcO/wc8uBGjNzrP7qRQI4EmfW4Bn8Y8SQn4vN6aRqyezhMn9IDY7Fg1VEY81y8BVU6jFM1KWpsiXwvV9ZbzMWrV+s3Rn//RMSmCRdFPUdtn8s7FOjoK7xPOmcYhGIP8218BxLqvxcf2UI6TXl9CyJXvL4cCel4dyYoYPhW0zQMrPMhW4Yk/yyHfgjKVrptS2Y5PgNepE2lu/qOc84IpHxAj5M6FlSNJ0KQwVZq7iSRuOsjuhqlf/Aqp50LT3NzTSwEsTlDJpLaHLSUMN8sm6o6ajuri8QaUCpmdCOgpaABSiDB8YvMDzG0IGsc8RlMXZbYk9zN/aE7Poz8Adbfplwq8sdit71VfDwQl4vOjt2srSLWziR6yfDhbUcRxp4ilgX0frHx2QCIjlyiTKMkupA02etHUrRO/b7JgKZ5xCZPzoepa4ipn6tltCDImTY9uv5y8Wg8U X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TmhtWEdrZE8xMGZNN1RyWjZmQys5Z2dXWGMxNVgrQ0NKYjVHWmE2aFRqRW0w?= =?utf-8?B?cjIzdlFVSWJLYkpiT0V6SXRMK1ptNk44cktmTmFpMi8vK2EvQUlKazRDUHFV?= =?utf-8?B?cUhOS0s5QUtSTldjR28vUk1ZRTYyTG9NeEJFclFWc3FNK1lUYkc0SDBqK2Fz?= =?utf-8?B?TWVQaHp4bUJ5bmVIRVA3OWZsSWdDT0ErZGZmZWhmcmF4YmhLUUV5MEp3RlNp?= =?utf-8?B?dytNYXlTMGFDVTR3WlFFQWZOb2ZCcU9Xc1pHNlBmOHFyY2o0V2thSE1TYlJa?= =?utf-8?B?WlpNTHF6Z1k4Z0U4U0V3WmV6dSsvdXcvZlVCQnBhaFNSWmdZS3V2dk9GNklp?= =?utf-8?B?Vit2dEkxWjhSRXRFaXBzNHlXVVZvZlltaS8yNmw2YjRManh2anJvbnp5R2Zs?= =?utf-8?B?bkp4RFpZMXpVQUR3RVRTWEs1Z1JXY3JoTUVZL0xXeFFCTDlHTGN0c1oxeGN5?= =?utf-8?B?bUY5SzZsNjA2RHloT0hjdTh4Y1pFYVBWU3pEMmRNV1FBbmdjVWYzT1Y5OXli?= =?utf-8?B?TVJLb09iQkZEVlp5blBJMWVMRHFWaklCaTRPeUM5TUNiS2RaUzk4VjRvT2Fn?= =?utf-8?B?SzVGYjZ2WFpRbEc1eXBucytrV2tIcWNFVkx2RHU5Q1VzNXZ0a3dJbUlmTUZP?= =?utf-8?B?VkNyLzJRWG5BcG9kdmdIeDcxUHBCejIyRXY4ZGlzV0RmSEZlZUlPMXJ2WGpJ?= =?utf-8?B?U0JEM2dmNk5QMndCb2l5SVpXYUpuTnhPY25haTkrcm9sQjRYRDhMeUJmblo2?= =?utf-8?B?MExiWDUyVFQ1OHVvSERmVFVwT201VkFGVzZFQzBPRGZWaGMzRGFOd1NUU1du?= =?utf-8?B?bGZHcm5CUlN6d2Rma1pmcXVFYTlic2s2YWVVU3BzVld6QlNYQkkzQVRTVUMr?= =?utf-8?B?NStWZHVnZ1ZIU210ZHBzSW8vcjZTUEVOT2psWEx5K0x0YU1KejVHTGhUYVln?= =?utf-8?B?MnpSakVuZjZjekd0dTVBN2ZOSG9pcEZBTS9PRUJjMW96bUFSUmxtakNRcTJn?= =?utf-8?B?TUdkMmFSRElnd3BhdGdaeDlDNUVzd3JnT1RBRVN3dlhVUEl6R3ByUzJyWjFR?= =?utf-8?B?RjFFMG5ySmZUQmtNNE9jSG4yZVJDZ0I0bVVsTUplTnFDNXUrbDZJb1dTb1ZC?= =?utf-8?B?Y3NNbEVibDNDaElDNEtZdjVJZnBsL0FoNjR2aElpRGt1ZmJkQk14ZmphV0R3?= =?utf-8?B?c1pLVFFvWVlhaVR1TWJMbDNTTythRVpCTldneFB6QWlmNzNrMzNlMVBHQVNq?= =?utf-8?B?R3BLd3JkN3NwWTdrL3BnSktuK0o1TGxlRDFSVm4zbVJtM0RjZ1pscS9PK3lN?= =?utf-8?B?OVF1bXM0dU8yUjNnbmo4YlVCSmZ4VDI4b2MrUmVpdHYvU1FFSjMyb055NmxV?= =?utf-8?B?eERvbElqbU1OakoxWmhZYTlOaUxEeWxFeWpMS0swaUFqMFRzekJKZUMwVEMw?= =?utf-8?B?MkhiR1pybThQYTF3b0psTjMyQ1NMaHppZnRrWWZ0V3o2aGFNMitvTmdYS1hn?= =?utf-8?B?WlNCSVorLzFQU3BZcnpBV0NVNkVjcFhlTzdrMURGS3cxRGkwMVNSa1pjMGNy?= =?utf-8?B?Wi9FMkg2YWsyMUdPK2pmY1hXdWRLejZDZ3ZNcjJmaGlaTTllRlp5Q0ZZRC9R?= =?utf-8?B?Ukpld21mb2c4elpTWC9Yc1d3T0s5MWk1MGhWZngyNWlGTXBoblJ5RDUvQWtG?= =?utf-8?B?ZWJkTk1BWFBlL0FqUTNhbzNzSExYWlVIVkFFRkxtaEQ5Qm5DU3IrRmhoTEZq?= =?utf-8?B?N21HYWQ1ek9SU2lGL3M3RzZHUkFqYjZGaGxXZy96WEJ6RDA4TmhiM3Y0N05W?= =?utf-8?B?c05ja0JMVWl6MDQyUWF1SG80Q0VjUWVza3J0TjB5QmFENk90WjZPZDBiVTNr?= =?utf-8?B?UjVsU3dMSm9FVDlYZ3N5OTZPajBSVU1ocGlRaStmYUlkNG40dUk2MVl4OG8w?= =?utf-8?B?NThPNWwwdndCK1o4QzZsRWF1WGI0Sk5SWGdocEhCTnMvQmNQUmdlMXVNN0Jx?= =?utf-8?B?dEc3MjhPMmhRPT0=?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fece33d9-894f-4c01-df99-08da123a02a0 X-MS-Exchange-CrossTenant-AuthSource: AS1PR01MB9564.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2022 10:42:39.3002 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR01MB4102 Subject: Re: [FFmpeg-devel] [PATCH] Add decoding of > 32-bit residuals to FLAC X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Martijn van Beurden: > The size of residuals in a FLAC file coding for 24-bit PCM can > exceed the range of a 32-bit signed integer. One pathological > example with residuals exceeding [-2^33,2^33) can be found here: > http://www.audiograaf.nl/misc_stuff/Extreme%20residual%20LPC%20order%2014.flac Can this happen with real encoders or has this file been specifically crafted? What is the performance impact of this patch on ordinary files? > > The theorectical maximum bit depth for a residual in a FLAC file is ^ > 32 + 1 + 15 + 5 - 0 = 53 bit (max bit depth + extra bit for side > channel + max lpc coeff precision + log2(max_order) - min > lpc shift) > > This patch adds detection of the possibilty of such residuals ^ > occuring and an alternate data path wide enough to handle them ^ > --- > libavcodec/flacdec.c | 107 ++++++++++++++++++++++++++++++++++++++----- > libavcodec/golomb.h | 56 ++++++++++++++++++++++ > 2 files changed, 152 insertions(+), 11 deletions(-) > > diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c > index dd6026f9de..3be1b63411 100644 > --- a/libavcodec/flacdec.c > +++ b/libavcodec/flacdec.c > @@ -64,6 +64,8 @@ typedef struct FLACContext { > uint8_t *decoded_buffer; > unsigned int decoded_buffer_size; > int buggy_lpc; ///< use workaround for old lavc encoded files > + int64_t *residual64; ///< to keep residuals exceeding int32_t > + unsigned int residual64_size; > > FLACDSPContext dsp; > } FLACContext; > @@ -149,6 +151,10 @@ static int allocate_buffers(FLACContext *s) > if (!s->decoded_buffer) > return AVERROR(ENOMEM); > > + av_fast_malloc(&s->residual64, &s->residual64_size, 8*s->flac_stream_info.max_blocksize); > + if (!s->residual64) > + return AVERROR(ENOMEM); Why not move this allocation to decode_residuals64() so that it is not performed for ordinary files? > + > ret = av_samples_fill_arrays((uint8_t **)s->decoded, NULL, > s->decoded_buffer, > s->flac_stream_info.channels, > @@ -279,6 +285,66 @@ static int decode_residuals(FLACContext *s, int32_t *decoded, int pred_order) > return 0; > } > > +static int decode_residuals64(FLACContext *s, int64_t *decoded, int pred_order) > +{ > + GetBitContext gb = s->gb; > + int i, tmp, partition, method_type, rice_order; > + int rice_bits, rice_esc; > + int samples; > + > + method_type = get_bits(&gb, 2); > + rice_order = get_bits(&gb, 4); > + > + samples = s->blocksize >> rice_order; > + rice_bits = 4 + method_type; > + rice_esc = (1 << rice_bits) - 1; > + > + decoded += pred_order; > + i = pred_order; > + > + if (method_type > 1) { > + av_log(s->avctx, AV_LOG_ERROR, "illegal residual coding method %d\n", > + method_type); > + return AVERROR_INVALIDDATA; > + } > + > + if (samples << rice_order != s->blocksize) { > + av_log(s->avctx, AV_LOG_ERROR, "invalid rice order: %i blocksize %i\n", > + rice_order, s->blocksize); > + return AVERROR_INVALIDDATA; > + } > + > + if (pred_order > samples) { > + av_log(s->avctx, AV_LOG_ERROR, "invalid predictor order: %i > %i\n", > + pred_order, samples); > + return AVERROR_INVALIDDATA; > + } Everything in this function up until this point coincides with decode_residuals(). So shouldn't the check for whether the 64bit codepath is used by put here? (Would it help for this check to know rice_bits?) > + > + for (partition = 0; partition < (1 << rice_order); partition++) { > + tmp = get_bits(&gb, rice_bits); > + if (tmp == rice_esc) { > + tmp = get_bits(&gb, 5); > + for (; i < samples; i++) > + *decoded++ = get_sbits_long(&gb, tmp); > + } else { > + for (; i < samples; i++) { > + int64_t v = get_sr_golomb64_flac(&gb, tmp, 1); > + if (v == INT64_MAX) { > + av_log(s->avctx, AV_LOG_ERROR, "invalid residual\n"); > + return AVERROR_INVALIDDATA; > + } > + > + *decoded++ = v; > + } > + } > + i = 0; > + } > + > + s->gb = gb; > + > + return 0; > +} > + > static int decode_subframe_fixed(FLACContext *s, int32_t *decoded, > int pred_order, int bps) > { > @@ -358,6 +424,21 @@ static void lpc_analyze_remodulate(SUINT32 *decoded, const int coeffs[32], > } > } > > +static void lpc_residual64(int32_t *decoded, const int64_t *residual, > + const int coeffs[32], int pred_order, > + int qlevel, int len) > +{ > + int i, j; These lines could be avoided if you declared them in the for loop (i.e. "for (int i = pred_order;"). > + > + for (i = pred_order; i < len; i++, decoded++) { > + int64_t sum = 0; > + for (j = 0; j < pred_order; j++) > + sum += (int64_t)coeffs[j] * decoded[j]; > + decoded[j] = residual[i] + (sum >> qlevel); > + } > + > +} > + > static int decode_subframe_lpc(FLACContext *s, int32_t *decoded, int pred_order, > int bps) > { > @@ -386,19 +467,23 @@ static int decode_subframe_lpc(FLACContext *s, int32_t *decoded, int pred_order, > coeffs[pred_order - i - 1] = get_sbits(&s->gb, coeff_prec); > } > > - if ((ret = decode_residuals(s, decoded, pred_order)) < 0) decode_residuals() is also called in decode_subframe_fixed(). Could the issue also exist in decode_subframe_fixed() (at least rice_bits can attain the same values whether it is called from decode_subframe_fixed or decode_subframe_lpc)? > - return ret; > - > - if ( ( s->buggy_lpc && s->flac_stream_info.bps <= 16) > - || ( !s->buggy_lpc && bps <= 16 > - && bps + coeff_prec + av_log2(pred_order) <= 32)) { > - s->dsp.lpc16(decoded, coeffs, pred_order, qlevel, s->blocksize); > + if (bps + coeff_prec + av_log2(pred_order) - qlevel <= 32) { > + if ((ret = decode_residuals(s, decoded, pred_order)) < 0) > + return ret; > + if ( ( s->buggy_lpc && s->flac_stream_info.bps <= 16) > + || ( !s->buggy_lpc && bps <= 16 > + && bps + coeff_prec + av_log2(pred_order) <= 32)) { > + s->dsp.lpc16(decoded, coeffs, pred_order, qlevel, s->blocksize); > + } else { > + s->dsp.lpc32(decoded, coeffs, pred_order, qlevel, s->blocksize); > + if (s->flac_stream_info.bps <= 16) > + lpc_analyze_remodulate(decoded, coeffs, pred_order, qlevel, s->blocksize, bps); > + } > } else { > - s->dsp.lpc32(decoded, coeffs, pred_order, qlevel, s->blocksize); > - if (s->flac_stream_info.bps <= 16) > - lpc_analyze_remodulate(decoded, coeffs, pred_order, qlevel, s->blocksize, bps); > + if ((ret = decode_residuals64(s, s->residual64, pred_order)) < 0) > + return ret; > + lpc_residual64(decoded, s->residual64, coeffs, pred_order, qlevel, s->blocksize); If I am not mistaken, then it is possible for s->flac_stream_info.bps to be <= 16 here (e.g. coeff_prec == 15, qlevel == 0, pred_order >= 16 gives 19). So is it not necessary to call lpc_analyze_remodulate() here in case it is so? > } > - > return 0; > } > > diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h > index 164c2583b6..5ebcdda059 100644 > --- a/libavcodec/golomb.h > +++ b/libavcodec/golomb.h > @@ -543,6 +543,62 @@ static inline int get_sr_golomb_flac(GetBitContext *gb, int k, int limit, > return (v >> 1) ^ -(v & 1); > } > > +static inline int64_t get_sr_golomb64_flac(GetBitContext *gb, int k, > + int esc_len) > +{ > + uint64_t buf; > + int log; > + > + OPEN_READER(re, gb); > + UPDATE_CACHE(re, gb); > + buf = GET_CACHE(re, gb); > + > + log = av_log2(buf); > + > + av_assert2(k <= 31); > + > + if (log - k >= 64 - MIN_CACHE_BITS + (MIN_CACHE_BITS == 64)) { > + buf >>= log - k; > + buf += (62U - log) << k; > + LAST_SKIP_BITS(re, gb, 64 + k - log); > + CLOSE_READER(re, gb); > + } else { > + int64_t i; > + for (i = 0; SHOW_UBITS(re, gb, MIN_CACHE_BITS) == 0; i += MIN_CACHE_BITS) { > + if (gb->size_in_bits <= re_index) { > + CLOSE_READER(re, gb); > + return INT64_MAX; > + } > + LAST_SKIP_BITS(re, gb, MIN_CACHE_BITS); > + UPDATE_CACHE(re, gb); > + } > + for (; SHOW_UBITS(re, gb, 1) == 0; i++) { > + SKIP_BITS(re, gb, 1); > + } > + LAST_SKIP_BITS(re, gb, 1); > + UPDATE_CACHE(re, gb); > + > + if (k) { > + if (k > MIN_CACHE_BITS - 1) { > + buf = SHOW_UBITS(re, gb, 16) << (k-16); > + LAST_SKIP_BITS(re, gb, 16); > + UPDATE_CACHE(re, gb); > + buf |= SHOW_UBITS(re, gb, k-16); > + LAST_SKIP_BITS(re, gb, k-16); > + } else { > + buf = SHOW_UBITS(re, gb, k); > + LAST_SKIP_BITS(re, gb, k); > + } > + } else { > + buf = 0; > + } > + > + buf += (i << k); > + CLOSE_READER(re, gb); > + } > + return (buf >> 1) ^ -(buf & 1); > +} > + Don't put such a huge function that is only used by one file into a header used by many files. > /** > * read unsigned golomb rice code (shorten). > */ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".