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 7491C40089 for ; Sun, 19 Dec 2021 21:11:45 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 73ECD68AEE9; Sun, 19 Dec 2021 23:11:43 +0200 (EET) Received: from w4.tutanota.de (w4.tutanota.de [81.3.6.165]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A9AF368AD3D for ; Sun, 19 Dec 2021 23:11:36 +0200 (EET) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w4.tutanota.de (Postfix) with ESMTP id 56B461060235 for ; Sun, 19 Dec 2021 21:11:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1639948294; s=s1; d=lynne.ee; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=1Zt/8UvfFsDhip/7yqPM/SMRqvMlsmJ27ColYKde/Fc=; b=MsmPzvOuHomQ1cA7s8Vzp0CMhqnFn4Zsq27EAGfon9AK1paU2jYzbv2c35HBVZj1 5Wv7fOhZ1WhtU9IfrDtm8h+/01SMiJBOVjAqIY4ar89x7iVvIMWjtz+qi37dp/HljMX hzUTzKPDGzEQKfvpkvmmWrvSQbeuUleYm5HyGtbIqo2jCCFlwHgvdcEp44pOw4HCBpI hGJyUZakaLl+kYIamBuj20UWTb0Ubuc6F3TfS8CfLhospGaUoed7MvzwWdP2nmo8ECf 7Jv0ms0s4C+8G5Uvrl4HTQ1yDHc6ALsOCy3om3jzE4WMXG3Sk7AGtIofSJCaUrh074C z3t+AryUcA== Date: Sun, 19 Dec 2021 22:11:34 +0100 (CET) From: Lynne To: FFmpeg development discussions and patches Message-ID: In-Reply-To: <20211219205318.9362-1-mvanb1@gmail.com> References: <20211219205318.9362-1-mvanb1@gmail.com> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/flacenc: add backward-compatible 32 bit-per-sample capability 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: 19 Dec 2021, 21:53 by mvanb1@gmail.com: > Enables creation of FLAC files with up to 32 bits-per-sample, up from the > previous limit of 24 bit. This is a feature requested for RAWcooked, the > archiving community has a need for storing files with 32-bit integer audio > samples. See https://github.com/MediaArea/RAWcooked/issues/356 > > Restrictions to the encoder are added so created files are compatible with > existing decoders. Stereo decorrelation is disabled on 32 bit-per-sample, > because a side channel would need 33 bit-per-sample, causing problems in > existing 32 bit datapaths. Also only LPC encoding is enabled, because > decoders capable of processing 24-bit files already use 64-bit processing > for LPC, but not for fixed subframes. > > Furthermore, predictions and residuals are checked for causing integer > overflow, reverting to a verbatim (store) subframe in case no LPC coeffs > can be found that do not cause overflow. > > ffmpeg's FLAC decoder has been forward-compatible with this change since > commit c720b9ce98 (May 2015). libFLAC is forward-compatible since release > 1.2.1 (September 2007), the flac command line tool however blocks 32-bit > files out of caution, it having been untested until now. > --- > libavcodec/flacdsp.c | 47 ++++++++++++++++++++++ > libavcodec/flacdsp.h | 3 ++ > libavcodec/flacenc.c | 95 +++++++++++++++++++++++++++++++++++++------- > 3 files changed, 130 insertions(+), 15 deletions(-) > > diff --git a/libavcodec/flacdsp.c b/libavcodec/flacdsp.c > index bc9a5dbed9..422f6578ba 100644 > --- a/libavcodec/flacdsp.c > +++ b/libavcodec/flacdsp.c > @@ -43,6 +43,53 @@ > #define PLANAR 1 > #include "flacdsp_template.c" > > +#define ZIGZAG_32BIT_MAX 0x3FFFFFFF > +#define ZIGZAG_32BIT_MIN -0x3FFFFFFF > + > +int ff_flacdsp_lpc_encode_c_32_overflow_detect(int32_t *res, const int32_t *smp, int len, > + int order, int32_t *coefs, int shift) > +{ > + /* This function checks for every prediction and every residual > + * whether they cause integer overflow in existing decoders. In > + * case the prediction exceeds int32_t limits, prediction > + * coefficients are lowered accordingly. If the residual exceeds > + * ZIGZAG_32BIT_MAX and _MIN or coefficients have been lowered > + * twice but the prediction still overflows, give up */ > What happens if there's an overflow and the prediction coefficients are lowered? Is there a loss of bits? What about if it gives up? I'm really concerned about arbitrary data not being lossless in a codec that's meant to be always lossless. If that can happen, I think 32-bit encoding should be disabled unless -strict -1 is used. _______________________________________________ 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".